[Date Prev][Date Next] [Chronological] [Thread] [Top]

[Fwd: LDAP/Samba 4 summary]

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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--- Begin Message --- 
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...

--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/



--- End Message ---