OpenLDAP and Samba4

[Gémes Géza]

2013-04-21 10:44 keltezéssel, Yoann Gini írta:
> Hello,
>
> As I said before on the list, I’m a french sys admin and also a developer, specialized on OS X and OS X Server. This conversation is interesting and please, allow me to give you the consumer point of view. (And forgive me for my english.)
>
> I’ve read all your comments about OpenLDAP or not OpenLDAP as backend for Samba4.
>
> The one saying « we should keep our own LDAP server because is only made with fee files » scares me, if OpenLDAP is heavy and have a lot of overlay it’s because we need it in the real world, seeing this kind of comments on the list remember me why a lot of people on the sys admin side would prefer to buy a Windows Server instead of playing with Samba4.
>
> I don’t know how AD work and how Samba4 work, but I’ve a deep knowledge of OS X directory service and UNIX systems, so what’s come next is purely a theoretical point of view about software architecture and what should be done if you want to give a good answer to the market needs.
>
> Network who aren’t based on Microsoft AD nowadays are mainly build with OpenLDAP, Kerberos (MIT or Heimdal) and SASL, but that’s not the only solution. We have other LDAP server, the most recognized after OpenLDAP is eDirectory from Novell. And after that we can also have some custom system that you don’t want to use (French university offer you a lot of surprises).
>
> What I’m trying to say is simple, assuming people gonna move on their whole directory service on your hands because you say it’s better won’t work, like saying to use OpenLDAP with your specific backend when people already have existing working setup. It’s a too heavy modification of a core service of a network to be accepted by 80% of IT guys and CTO.
>
> At this days, Samba4 answer to the needs « I want and Active Directory for free ». But in the real world, that not the question coming from IT, the real question is « I want an adapter to connect Windows clients to my Directory Service ». One of the answer to the real question is pGina for example, it simple but widely used in educational network even if it only do windows logon.
>
> Today you’ve a working code and a deep knowledge of how AD work, that greats, really greats, you’ve done a impressive work, but IMHO it’s only the R part of R&D. What you need to do now it develop your system to fit in many situation as possible.
>
> An other company was in the same situation some years ago: Apple. When they’ve build their directory services in 2000 the requirements was to be able to be connected to whatever IT guys have and with many level of personalization.
>
> On a OS X client, the whole identity management go through a specific process, DirectoryService[1] (or opendirectoryd depending of the version), this process is only here to translate the Apple API to any kind of backend, based on plug-in. Whit it we can connect our OS X to anything we want. By default Apple support local XML file, NIS, LDAP and AD. For other system, Apple have published the API to create plug-in, and for example, Novell used this possibility to create one for eDirectory.
>
> On a sys admin side, when we integrate OS X client to a custom LDAP schema who don’t fit with the Apple needs, we have many options to answer the problems without heavy modification of the system.
>
> The base is on the LDAP plug-in, we can create our own mapping config, saying the username isn’t uid but the mail field for example. We can also define some static and dynamic mapping on the client side. We can set the GID for all user to a specific value if the LDAP don’t have it. We can set the home folder to /Users/<uid> to compose it if we need.
>
> When we’ve done our custom mapping, again, we’ve got options to deploy it. We can get the XML config file and copy it to all clients, or we can save it in a specific cn of the LDAP tree, allowing new clients to just bind and download mapping without any user interactions.
>
> When come the time to manage our clients and put some MCX (the OS X world equivalent of GPO), again, we’ve multiple options. MCX are simple XML file stored in a specific LDAP field for users, groups and computers. If we want, we can extend the LDAP schema to add some apple- field to support our MCX and that’s done. But if we don’t want it, we have an other solution, use two LDAP server in the same time on OS X Client. The first with users identities on the existing LDAP server and the other one, on OS X Server if we want, contains augmented entries with extended field for management only (that what we call the golden triangle or magical triangle in OS X world).
>
> For me, this is the nicer solution to handle directory service, it’s complex, but as an OS X sys admin I’ve never have a case where I’ve said « I can’t connect OS X to your system ».
>
> IMHO, if you with Samba4 want to be THE option to _integrate_ Windows clients to existing directory service, you need to follow a path like that. You need to build an abstract system based on backend plugin with a full documentation, examples and possibilities. And you need to use it to your own needs.
>
> Don’t assume it will be OpenLDAP, don’t assume you will have password hash in the LDAP, it can be in an other custom datastore, don’t assume sys admin will move on your system just because you say it’s better.
>
> Sys admin aren’t stupid people. Try to build the more flexible solution who fit in many case, even if sometime you can’t provide some features. If in some case you can provide user and group but no GPO or not as good as you want, explain why, explain workaround but let your system work in a degraded setup. That will allow your clients to test it and see how it work without having to move all critical service on your hands.
>
> My 2 cents,
> Yoann.
>
> [1] http://www.opensource.apple.com/source/DirectoryService/DirectoryService-621.12/
Unfortunately Samba as an AD DC has to satisfy (also) Windows clients 
which are more than inflexible with their requirements about what they 
expect to find via LDAP calls. So if you want them integrated without 
deploying pGina based tricks you have to follow the AD schema byte by 
byte. I know that moving from OpenLDAP to Samba AD is a not so smooth, 
but rather painful experience (I've migrated from to Samba AD from Samba 
(classic) + OpenLDAP + Heimdal during last summer and still have to 
maintain the OpenLDAP directory because of some services (I'm glad none 
of them is doing user authentication to have to synchronize passwords 
between) which couldn't be migrated to AD schema (missing development 
resources (read time)) yet (ISC DHCPD is a notable example).
In the case OpenLDAP is going to replace (e.g. as an optional component 
like BIND9-DLZ now) the built in LDAP server you shouldn't expect 
compatibility with existing installations, as the schema will have to be 
the AD one.
Your example citing Apple and their implementation of user 
authentication/authorization/account setup should have been followed by 
M$ 13 years ago, and now we wouldn't need AD. Unfortunately that is not 
the case, and thus in order to satisfy Windows clients out of the box 
the AD schema must be used regardless if the LDAP would be served by the 
internal LDAP server or OpenLDAP.

Cheers

Geza Gemes