Samba4 LDAP Integration

[Dustin A. Dortch]

>>> Hi,
>>> 
>>> we use Samba 3 as domain controllers for a Citrix server farm and in

>the 
>>> near future we are planning to use these DCs also for the rest of
our 
>>> network. 
>>> 
>>> Although it works very well, in the forseeable future we will be 
>obliged 
>>> to offer some sort of AD emulation, unless we get rid of Windows
OSes 
>for 
>>> our desktops, which I don't see at the moment. Longhorn will
probably 
>not 
>>> support non-AD DCs any more.
>>
>>Personally, I would be surprised.  NT4 is still out there...
>>
>>But your point is valid, and that is why we are working so hard on
>>Samba4.

>I bet MS is working hard on introducing AD to all companies that 
>succesfully denied to upgrade until now. Usually dropping backward 
>compatibility is a good argument to increase the upgrade pressure... 

>>> The question that arises for us is, how difficult the migration from

>Samba 
>>> 3 to Samba 4 will be, especially regarding the LDAP backend. At the 
>moment 
>>> we have a perfect integration of all samba related attributes in our

>>> existing user entries. Simply add samba attributes and go. 
>>> Will it stay like this in Samba4, meaning that we can keep our
existing 

>>> structure in openldap, at least regarding users and groups, and
samba4 
>>> will present some kind of translated LDAP view to MS clients ? 
>>> Or are you planning to put AD entries directly into openldap, which 
>makes 
>>> the integration of our existing entries difficult or impossible.
>>> 
>>> Has there already been made a decision or is it too early to ask
this 
>>> question ?
>>
>>This is a very good time to start looking into this area.  Currently,
>>the Samba4 modal assumes either that OpenLDAP contains support for all
>>the AD attributes, or that you use Samba4's ldb local storage in a
TDB.
>>
>>Clearly, this just will not work for your site, and many others.  What
I
>>think we need to do is write another LDB backend, that understands
more
>>about the semantic mapping, and provides a proxy service.

>>From my point of view as an Openldap and Samba administrator it would
be 
>great if I could use our existing user, machine and group entries for 
>samba4, because we use those entries for a lot of different non-MS 
>services. And until now it was never necessary for us, to hold
redundant 
>data under a different LDAP branch. Most of the user information I see
in 
>AD I already have in our ldapserver, of course under a different 
>structural object class and as different attributes. 
>If I understood you correctly, with semantic mapping and proxy server
you 
>meant a proxy LDAP server which translates those attributes I already
have 
>to those needed by an AD client. Sounds great, but also sounds like a
lot 
>of work for you. Maybe use an extended samba 3 schema in a kerberised 
>openldap for users, groups and machines, and place all other AD only 
>entries in different branches in openldap using Microsoft schemas ?
Hmm... 
>I have no idea, if this could work and if it is not simply much to 
>complicated. 

>The XAD approach seems much simpler and why not simply use a dedicated 
>openldap and synchronize data using some scripts and use our existig 
>openldap as metadirectory ? While writing this, I start liking that
idea 
>because it keeps things simpler and clearer.

>I do not envy you about making that decision. 
>By the way, Samba 2 + 3 do a great job at our site.
 
>Regards,

>Pierre Filippone

This is real touchy.  Personally, the reason I was able to implement
Samba is because of the existing OpenLDAP setup.  We have everything
integrated into OpenLDAP, and have the POSIX and Samba accounts as well
as the password sync really helps.  We have Postfix setup with virtual
mailboxes, and Courier-IMAP setup to authenticate against the same
entries.  We have FreeRADIUS setup to authenticate against the Samba
attributes in our entries so VPN users can use this data.  It really
provides SSO, which is what many people are looking for.

I know there are many issues... smooth migration is imperative.  Having
true LDAP compatibility is paramount.  Being able to maintain this
integration is crucial.

Do you reinvent the wheel for the sake of a few things, or do you
contribute to an existing project.  I tend to think the latter.  There
is not any need to create a new LDAP server.  That is just more code to
maintain than is necessary.  OpenLDAP does need some work, but maybe
there needs to be some joint work in extending OpenLDAP, especially in
respects to replication and manageability.  Maybe a commercially
available distribution of OpenLDAP, Samba, and other easily integrated
programs is in order.  Paid support, and a portion can go to paying
people to work on these things full-time?

We shall see...
Dustin A. Dortch