(please forgive the cross-posting to subscriber-only lists)
Howard Chu helpfully wrote up this summary of the meeting we held at the CIFS Workshop on how Samba4 should work with an LDAP backend.
The background is that Samba4 increasingly needs some things that an LDAP server could provide for us. In the short term, we need to add subtree renames to ldb_tdb, but OpenLDAP's hdb already provides this for us.
Likewise, we have a desperate need for replication (because any site in need of Samba4's features will want multiple DCs) - and Fedora DS's replication seems like a very good, solid answer. (Sadly it doesn't give us subtree renames...).
Another feature we don't yet do schema validation in Samba4, beyond checking that the objectClass list is valid. We need to extend that, but perhaps the LDAP server could do that validation for us?
Finally, in the long term, we would like to have Samba4 play nice in a multi-use directory, and this presents a schema mapping problem. We agreed to get together and try and work out a schema that is compatible to Microsoft's extensions, without being too painful to see from a traditional client. I hope to put together a discussion on this in the near future.
I expect we will continue to use and support ldb_tdb as a backend on Samba4, but for some features (which they will want), users should be directed to use LDAP as an important backend.
Andrew Bartlett
-------- Forwarded Message -------- From: Howard Chu hyc@symas.com To: OpenLDAP-devel@openldap.org Subject: [Fwd: LDAP/Samba 4 summary] Date: Fri, 28 Sep 2007 10:42:22 -0700
Yesterday afternoon at the CIFS Workshop we had a meeting to discuss Samba 4's use of LDAP going forward, and what obstacles remained. Among the attendees that I can remember were Andrew Bartlett, Andrew Tridgell, Simo Sorce, Stefan Metzmacher, and (one more, I've forgotten the name) from the Samba team. Nicole Jacque and another (sorry, don't remember the name) from Apple/OpenDirectory, Pete Rowley from FedoraDS, and myself and Marty Heyman for OpenLDAP and Symas.
The upshot is that both the Samba and the LDAP sides have work to do, but there are no major roadblocks. LDAP will be Samba 4's default/recommended data store. As for OpenLDAP, most of what Samba 4 needs is either already implemented, or in progress.
Schema design tends to still be a stumbling block; in a separate conversation we discussed some design issues in MIT's new Kerberos schema as well as missing features in Heimdal's existing Kerberos schema. That's a bit outside this openldap-devel scope but I've committed to working with the Samba and Kerberos communities to draft some changes to unify these two Kerberos schemas.
-------- Forwarded Message -------- From: Howard Chu hyc@symas.com To: Andrew Bartlett abartlet@samba.org Subject: LDAP/Samba 4 summary Date: Thu, 27 Sep 2007 22:41:23 -0700 Missing features / wishlist bitwise ops. already in OpenLDAP, recently added to FedoraDS(?)
USNs partially implemented in OpenLDAP, need more complete spec
LDAP Transaction support draft-zelenga-ldap-txn - partially implemented in OpenLDAP some concerns because Samba's definition of transaction is not the canonical ACID definition. More like ACI, no Durability guarantee, doesn't play well with LDAP Multimaster Replication. We all agreed that if Samba doesn't care, neither do we. All that matters is that it provides tidy, painless rollback in event of intermediate failures.
Access Controls my suggestion re: OpenLDAP - we support modular ACL engines, we should just write a module for native NT ACLs in OpenLDAP
AD schema - we agreed that a new schema is necessary no matter how you slice it, we will all collaborate to define a superset of AD that everyone can support.
Authentication mechanisms - generally Samba will handle this itself
validation - Samba4 + LDAP must pass everything under Samba's "make test" suite.
Transactions again - we may need things like memberOf and other linked attributes to be managed internally in the server. No problem, both OpenLDAP and FDS have memberOf plugins already available.
Subtree renames - MS tools assume subtree renames work. Supported in OpenLDAP already (back-hdb, back-ldif, will be in back-tdb). Unfortunately not supported in FedoraDS, might be able to kludge it, but it will require additional mapping layers. And kludging will break base-scope searches, referential integrity, etc...