I had set up LDAP on linux side, I want to build a AD with Windows2008R2, and AD should sync the user information from LDAP, is there any suggestion on this?
2013/3/22 杨峰 hoking.yang@gmail.com:
I had set up LDAP on linux side, I want to build a AD with Windows2008R2, and AD should sync the user information from LDAP, is there any suggestion on this?
Look at LSC project: http://lsc-project.org
Here is a small tutorial: http://lsc-project.org/wiki/documentation/2.0/tutorials/openldaptoactivedire...
Clément.
On Fri, Mar 22, 2013 at 1:33 AM, 杨峰 hoking.yang@gmail.com wrote:
I had set up LDAP on linux side, I want to build a AD with Windows2008R2, and AD should sync the user information from LDAP, is there any suggestion on this?
Usually and quite commonly your DITs will differ so you will probably need a middle man to translate. I don't know of an existing toolset that does this elegantly, but one could very well exist.
Perl is my tool of choice here with Net::LDAP, but you can use any programming language that talks LDAP. You have to enable LDAP on the AD side because AFAICR it's not enabled by default.
Wether it's real-time (event-driven) or batch based depends on your particular needs, and there are different techniques for either one. In all the cases I have done this AD is a sub-set of the corporate DIT which is in OpenLDAP (or whatever) but YMMV.
Best,
Hello, if I add an entry like this:
dn: cn=jk,dc=test objectClass: inetOrgPerson cn: jk sn: jk
This works fine. Esp. the superclasses seem to be added "on the fly": Searching this entry with filter "objectClass=person" works fine.
However - when I read this entry I'd expect that all objectClasses are given back. So I expected:
dn: cn=jk,dc=test objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top cn: jk sn: jk
But I only got:
dn: cn=jk,dc=test objectClass: inetOrgPerson cn: jk sn: jk
I don't think that this is correct: Reading an entry should return ALL values of attribute objectClass - not only the value given when adding this entry.
Note: When I provide inetOrgPerson AND organizationalPerson while adding the entry also only these two values are given back when reading.
What do other think: Is the OpenLDAP behaviour correct?
I'm not sure (reading RFC4511 and RFC4512). But most products I know (e.g. OpenDJ, CP DS, Siemens DirX) return all object classes.
Regards, Jochen.
Am 22.03.2013 um 14:06 schrieb "Keutel, Jochen (mlists)" mlists@keutel.de:
Hello, if I add an entry like this:
dn: cn=jk,dc=test objectClass: inetOrgPerson cn: jk sn: jk
This works fine. Esp. the superclasses seem to be added "on the fly": Searching this entry with filter "objectClass=person" works fine.
However - when I read this entry I'd expect that all objectClasses are given back. So I expected:
dn: cn=jk,dc=test objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top cn: jk sn: jk
But I only got:
dn: cn=jk,dc=test objectClass: inetOrgPerson cn: jk sn: jk
I don't think that this is correct: Reading an entry should return ALL values of attribute objectClass - not only the value given when adding this entry.
Note: When I provide inetOrgPerson AND organizationalPerson while adding the entry also only these two values are given back when reading.
What do other think: Is the OpenLDAP behaviour correct?
I don't think so, because RFC 4512, section 3.3 says:
"When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. [...]"
If I'm interpreting this correctly, the OpenLDAP behaviour is a bug.
Best regards, Manuel
Manuel Gaupp wrote:
I don't think so, because RFC 4512, section 3.3 says:
"When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. [...]"
If I'm interpreting this correctly, the OpenLDAP behaviour is a bug.
Well, "implicitly added" is a bit vague to call it a bug since the entries are returned when searching for the superior object class.
Ciao, Michael.
Michael Ströder wrote:
Manuel Gaupp wrote:
I don't think so, because RFC 4512, section 3.3 says:
"When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. [...]"
If I'm interpreting this correctly, the OpenLDAP behaviour is a bug.
Well, "implicitly added" is a bit vague to call it a bug since the entries are returned when searching for the superior object class.
In the sense that "implicit" is the opposite of "explicit" the OpenLDAP behavior is exactly correct. Also as a general rule the X.500 data model requires that a server store and return exactly what the user provided.
Hello,
Also as a general rule the X.500 data model requires that a server
store and return exactly what the user provided.
please tell me where in X.500 you find this. I couldn't find it. Instead I found (X.501 (2008), chapter 13.3.2 (" The object class attribute") :
"Every entry shall contain an attribute of type objectClass to identify the object classes and superclasses to which the entry belongs. The definition of this attribute is given in 13.4.8. This attribute is multi-valued. There shall be one value of the objectClass attribute for the entry's structural object class and a value for each of its superclasses. top may be omitted."
This means - in my understanding - that the server has to set these values for the attribute object class - one per superclass.
Regards, Jochen.
Am 22.03.2013 21:02, schrieb Howard Chu:
Michael Ströder wrote:
Manuel Gaupp wrote:
I don't think so, because RFC 4512, section 3.3 says:
"When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. [...]"
If I'm interpreting this correctly, the OpenLDAP behaviour is a bug.
Well, "implicitly added" is a bit vague to call it a bug since the entries are returned when searching for the superior object class.
In the sense that "implicit" is the opposite of "explicit" the OpenLDAP behavior is exactly correct. Also as a general rule the X.500 data model requires that a server store and return exactly what the user provided.
Keutel, Jochen (mlists) wrote:
Hello,
Also as a general rule the X.500 data model requires that a server store
and return exactly what the user provided.
please tell me where in X.500 you find this. I couldn't find it. Instead I found (X.501 (2008), chapter 13.3.2 (" The object class attribute") :
"Every entry shall contain an attribute of type objectClass to identify the object classes and superclasses to which the entry belongs. The definition of this attribute is given in 13.4.8. This attribute is multi-valued. There shall be one value of the objectClass attribute for the entry's structural object class and a value for each of its superclasses. top may be omitted."
This means - in my understanding - that the server has to set these values for the attribute object class - one per superclass.
Please, this is an ancient question, answered long ago.
http://www.openldap.org/lists/openldap-software/200208/msg00721.html
Search the archives. There's no point carrying this one on again.
Am 22.03.2013 21:02, schrieb Howard Chu:
Michael Ströder wrote:
Manuel Gaupp wrote:
I don't think so, because RFC 4512, section 3.3 says:
"When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. [...]"
If I'm interpreting this correctly, the OpenLDAP behaviour is a bug.
Well, "implicitly added" is a bit vague to call it a bug since the entries are returned when searching for the superior object class.
In the sense that "implicit" is the opposite of "explicit" the OpenLDAP behavior is exactly correct. Also as a general rule the X.500 data model requires that a server store and return exactly what the user provided.
openldap-technical@openldap.org
-
Alejandro Imass -
Clément OUDOT -
Howard Chu -
Keutel, Jochen (mlists) -
Manuel Gaupp -
Michael Ströder -
杨峰