OpenLDAP and Samba4

[Matthieu Patou]

On 04/22/2013 02:55 PM, Yoann Gini wrote:
> Le 22 avr. 2013 à 19:27, Gémes Géza <geza at kzsdabas.hu> a écrit :
>
>> Lots of attributes are different (conflicting) in the AD schema from those used by OpenLDAP or any other implementation. So bringing over ldif export files form existing LDAP directories won't work without changes, and could even need some patches for the software which used them.
> Attribute composition or replacement to deal with that kind of situation are something that we are used to…
>
> For my understanding of the AD system, the mains differences are the GPO applied to OU (but I don’t know how it’s saved and I’m curious about that) and some custom unique ID like de SID who look like to have a algorithmic conception.
>
> Mapping userPrincipalName to uid and userAccountControl to static value or to a microsoft-userAccountControl field is not a big deal for a system administrator.
>
> Conflicting attributes are just a question of mapping and you have the control on that point, you can translate on with some config file conflicting attributes. For things who don’t exist or exit in a bad format, we can handle a schema extension and an integration into the existing admin tools (for example to translate a password expiration date to a pwdLastSet boolean).
>
> Providing the content is the role of the system administrator, not yours. What you have to do on your side is asking us what you need and allowing us to map some names to fit your needs in our schema.


A couple of problem that can arise:

* CN is mono valuated in AD, OpenLDAP hasn't this limitation so if your 
current setup has object with two CN you're done.
* source4/setup/schema-map-openldap-2.3 indicate there is quite common 
attributes that are in *conflict* ie.
     #MiddleName has a conflicting OID
2.16.840.1.113730.3.1.34:1.3.6.1.4.1.7165.4.255.1
     #defaultGroup has a conflicting OID
     1.2.840.113556.1.4.480:1.3.6.1.4.1.7165.4.255.2
So your existing schema and your data have attributes with this OID then 
it would mean something else in the "AD" view and in the "other view" 
and even worse this could lead to AD constraint failure (not in the 
schema) but one explained in one of the 20+ pdf documentation related to 
AD (ie. MS-ADTS).

If you have a custom schema it starts to be much worse, you don't have 
to search a very long time: ISC DHCP extension for LDAP:
https://github.com/dcantrell/ldap-for-dhcp/blob/master/dhcp.schema

It has an schema attribute dhcpSubnet with OID 
2.16.840.1.113719.1.203.6.3, but in default AD schema it's 
1.2.840.113556.1.4.705 so if you try to import AD schema it won't work. 
You can tweak it but then replication with other AD servers is unlikely 
to work.

Matthieu.