Anonymous_User Absent Member.
Absent Member.
503 views

Can you RFC 4533 (Ldap Sync) with Jldap?

Hi,

I am searching for a way to do a refreshAndPersist operation from Jldap as
defined in RFC 4533. After a day of investigation I believe this extension
is not supported even though I read a post that it was on the to do list in
2005 list, and that I saw that it is currently not.

- Is the refreshAndPersist extension supported by Jldap?

- What would it take to create such support? If given an estimate, I might
be able to get time to implement it myself.

- (OT) Is there another way to do refreshAndPersist from Java?

Regards,
Erik.

Labels (1)
0 Likes
5 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Can you RFC 4533 (Ldap Sync) with Jldap?

Hi Eric,

e.vanoosten@chello.nl wrote in news:Ffomi.1426$QE3.914@prv-
forum2.provo.novell.com:

here's a reply from Susan who kindfully digged up this:

Looking at this RFC, it looks like it requires some server side support in
addition to the client requests. So if he is using eDirectory, it's a
request to make of the eDirectory server team. While the jldap sdk
includes sources for classes that can be used to implement controls that
aren't already defined at a higher level by the jldap sdk, that wouldn't
give you anything if the server has not implemented it.

Assuming that reading the root DSE on the customer's eDirectory server:

ldapsearch -h nw65 -D cn=admin,o=novell -w novell -b "" -s base
supportedcontrol=*

does not show the oid for the RFC, then I'd recommend that they enter a
bug/enhancement request at
http://support.novell.com/eService/shortLogin.jsp interact/submit or share
information/report a bug.

If they are using a directory that does support this control, they can
download the jldap sources from http://www.openldap.org/jldap/ and take a
look at how another control, for example, the sort control, is implemented
by overloading LDAPControl.

I'll submitted enhancement request 292109 against the jldap sdk for future
consideration by product management, but I can't guarantee a timeframe for
implementation.

I don't know if it's implemented by JNDI but he might check java.sun.com
for an answer.

Thank you
Susan


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Can you RFC 4533 (Ldap Sync) with Jldap?

Hi Guenter, Susan,

I was planning on using this in a client application against an openldap
server. Openldap supports this rfc and offers it as a way to replicate
DITs. I need it to keep an ldap server synchronized with a quite different
type of directory.

As far as I could read from the JNDI documentation, JNDI does not support
RFC4533.

If I get the time here I will do as Susan suggested and try to implement it
by extending Jldap.

If I may, I suggest that Novell implements this RFC in eDirectory as well.
You could do so in 2 ways: 1. as a client (make eDirectory replicas of DITs
from any server that support RFC4533), 2. as server (allow replica's of
eDirectory DITs). I assume that especially the first is interesting from a
commercial point of view.

Thanks and regards,
Erik.


> Hi Eric,
>
> e.vanoosten@chello.nl wrote in news:Ffomi.1426$QE3.914@prv-
> forum2.provo.novell.com:
>
> here's a reply from Susan who kindfully digged up this:
>
> Looking at this RFC, it looks like it requires some server side support in
> addition to the client requests. So if he is using eDirectory, it's a
> request to make of the eDirectory server team. While the jldap sdk
> includes sources for classes that can be used to implement controls that
> aren't already defined at a higher level by the jldap sdk, that wouldn't
> give you anything if the server has not implemented it.
>
> Assuming that reading the root DSE on the customer's eDirectory server:
>
> ldapsearch -h nw65 -D cn=admin,o=novell -w novell -b "" -s base
> supportedcontrol=*
>
> does not show the oid for the RFC, then I'd recommend that they enter a
> bug/enhancement request at
> http://support.novell.com/eService/shortLogin.jsp interact/submit or share
> information/report a bug.
>
> If they are using a directory that does support this control, they can
> download the jldap sources from http://www.openldap.org/jldap/ and take a
> look at how another control, for example, the sort control, is implemented
> by overloading LDAPControl.
>
> I'll submitted enhancement request 292109 against the jldap sdk for future
> consideration by product management, but I can't guarantee a timeframe for
> implementation.
>
> I don't know if it's implemented by JNDI but he might check java.sun.com
> for an answer.
>
> Thank you
> Susan


--
Erik van Oosten
http://2008.rubyenrails.nl/
http://www.day-to-day-stuff.blogspot.com/

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Can you RFC 4533 (Ldap Sync) with Jldap?

Why not use the IDM LDAP driver?

The RFC 4533 appears to be:
Category: Experimental

-jim

e.vanoosten@chello.nl wrote:
> Hi Guenter, Susan,
>
> I was planning on using this in a client application against an openldap
> server. Openldap supports this rfc and offers it as a way to replicate
> DITs. I need it to keep an ldap server synchronized with a quite different
> type of directory.
>
> As far as I could read from the JNDI documentation, JNDI does not support
> RFC4533.
>
> If I get the time here I will do as Susan suggested and try to implement it
> by extending Jldap.
>
> If I may, I suggest that Novell implements this RFC in eDirectory as well.
> You could do so in 2 ways: 1. as a client (make eDirectory replicas of DITs
> from any server that support RFC4533), 2. as server (allow replica's of
> eDirectory DITs). I assume that especially the first is interesting from a
> commercial point of view.
>
> Thanks and regards,
> Erik.
>
>
>> Hi Eric,
>>
>> e.vanoosten@chello.nl wrote in news:Ffomi.1426$QE3.914@prv-
>> forum2.provo.novell.com:
>>
>> here's a reply from Susan who kindfully digged up this:
>>
>> Looking at this RFC, it looks like it requires some server side support in
>> addition to the client requests. So if he is using eDirectory, it's a
>> request to make of the eDirectory server team. While the jldap sdk
>> includes sources for classes that can be used to implement controls that
>> aren't already defined at a higher level by the jldap sdk, that wouldn't
>> give you anything if the server has not implemented it.
>>
>> Assuming that reading the root DSE on the customer's eDirectory server:
>>
>> ldapsearch -h nw65 -D cn=admin,o=novell -w novell -b "" -s base
>> supportedcontrol=*
>>
>> does not show the oid for the RFC, then I'd recommend that they enter a
>> bug/enhancement request at
>> http://support.novell.com/eService/shortLogin.jsp interact/submit or share
>> information/report a bug.
>>
>> If they are using a directory that does support this control, they can
>> download the jldap sources from http://www.openldap.org/jldap/ and take a
>> look at how another control, for example, the sort control, is implemented
>> by overloading LDAPControl.
>>
>> I'll submitted enhancement request 292109 against the jldap sdk for future
>> consideration by product management, but I can't guarantee a timeframe for
>> implementation.
>>
>> I don't know if it's implemented by JNDI but he might check java.sun.com
>> for an answer.
>>
>> Thank you
>> Susan

>
> --
> Erik van Oosten
> http://2008.rubyenrails.nl/
> http://www.day-to-day-stuff.blogspot.com/
>

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Can you RFC 4533 (Ldap Sync) with Jldap?

Great!

Where can I find it? (Google didn't help.)

Regards,
Erik.


0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Can you RFC 4533 (Ldap Sync) with Jldap?

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.