(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...
Andrew Bartlett wrote:
(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...).
Multimaster replication is also in OpenLDAP 2.4 (which is currently still in beta - we're still shaking it down, more testers would probably be helpful at some point).
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?
Right, since LDAP doesn't really depend on schema-aware clients this is the LDAP server's responsibility. (As opposed to X.500, where every agent in the system must be fully schema aware.)
On Tue, 2007-10-02 at 13:02 -0700, Howard Chu wrote:
Andrew Bartlett wrote:
(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...).
Multimaster replication is also in OpenLDAP 2.4 (which is currently still in beta - we're still shaking it down, more testers would probably be helpful at some point).
I'll have to keep an eye on that.
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?
Right, since LDAP doesn't really depend on schema-aware clients this is the LDAP server's responsibility. (As opposed to X.500, where every agent in the system must be fully schema aware.)
Yes, but we may not wish to have the backend server be as fully aware as Samba about the full monster that is the AD schema, or we may wish to pre-empt the backend server's response. For example, if Samba implements a 'no-user-modification' attribute in a module, we will have to remove that tag from the OpenLDAP/FedoraDS schema, and prevent that modification ourselves.
Andrew Bartlett
On Tue, 2007-10-02 at 11:32 -0700, Andrew Bartlett wrote:
(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.
Just as an update, I've implemented this, and linked attributes (another thing we discussed at the CIFS workshop) in Samba4, for ldb_tdb. This does however bring up the issue of linked attributes in LDAP backends.
Linked attributes include member/memberOf, master/masteredBy and many others. They are defined in the AD schema, and as far as I know, are strictly updated as a pair (they are not flattened memberOf listings, for example).
Linked attributes and subtree renames are closely linked - if you don't support subtree renames, then handling linked attributes on the Samba side is easy - the LDAP server remains 'dumb' about it. As I understand it (corrections welcome), Fedora DS is not likely to handle subtree renames soon, so this approach will work for Samba4 on Fedora DS.
However, for Samba4 on OpenLDAP, we will want to have the LDAP backend handle subtree renames. Has there been any work to handle memberOf in OpenLDAP? How does this interact with subtree renames?
Any other thoughts?
Andrew Bartlett
Andrew Bartlett wrote:
Has there been any work to handle memberOf in OpenLDAP? How does this interact with subtree renames?
There's a slapo-memberof(5) overlay in 2.4 that maintains cross links (a la memberOf) for usual update operations. It lacks some consistency check (like creating missing links if the overlay is switched on on an already existing database) and probably doesn't handle subtree renames (need to check).
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Hello,
Andrew Bartlett wrote: [...]
Linked attributes include member/memberOf, master/masteredBy and many others. They are defined in the AD schema, and as far as I know, are strictly updated as a pair (they are not flattened memberOf listings, for example).
[...]
Isn't that what slapo-refint(5) does? Maybe it needs some fine adjustment, but from the manpage it sounds promising...
bye
Christian
Christian Marg wrote:
Hello,
Andrew Bartlett wrote: [...]
Linked attributes include member/memberOf, master/masteredBy and many others. They are defined in the AD schema, and as far as I know, are strictly updated as a pair (they are not flattened memberOf listings, for example).
[...]
Isn't that what slapo-refint(5) does? Maybe it needs some fine adjustment, but from the manpage it sounds promising...
The slapo-memberOf overlay is probably more useful here, as Ando already pointed out. But yes, we can take care of linked attributes, no problem.
On Tue, 2007-11-27 at 07:23 -0800, Howard Chu wrote:
Christian Marg wrote:
Hello,
Andrew Bartlett wrote: [...]
Linked attributes include member/memberOf, master/masteredBy and many others. They are defined in the AD schema, and as far as I know, are strictly updated as a pair (they are not flattened memberOf listings, for example).
[...]
Isn't that what slapo-refint(5) does? Maybe it needs some fine adjustment, but from the manpage it sounds promising...
The slapo-memberOf overlay is probably more useful here, as Ando already pointed out. But yes, we can take care of linked attributes, no problem.
Looking at the configuration, it seems this can only currently be configured once - ie, for memberOf. Am I missing how to configure it to also handle an arbitrary number of other attributes? Ideally I would process the AD schema into a configuration file with these details.
Andrew Bartlett
On Wed, 2007-11-28 at 09:13 +1100, Andrew Bartlett wrote:
On Tue, 2007-11-27 at 07:23 -0800, Howard Chu wrote:
Christian Marg wrote:
Hello,
Andrew Bartlett wrote: [...]
Linked attributes include member/memberOf, master/masteredBy and many others. They are defined in the AD schema, and as far as I know, are strictly updated as a pair (they are not flattened memberOf listings, for example).
[...]
Isn't that what slapo-refint(5) does? Maybe it needs some fine adjustment, but from the manpage it sounds promising...
The slapo-memberOf overlay is probably more useful here, as Ando already pointed out. But yes, we can take care of linked attributes, no problem.
Looking at the configuration, it seems this can only currently be configured once - ie, for memberOf. Am I missing how to configure it to also handle an arbitrary number of other attributes? Ideally I would process the AD schema into a configuration file with these details.
To start with this module I've decided to just deal with memberOf. However, I can't get the module to start, because while it allows configuration of different schema in theory, it relies on the default schema to exist in practice:
[abartlet@naomi source]$ /usr/local/sbin/slaptest -f /home/data/samba/samba4/clean/source/st/dc/private/ldap/slapd.conf back-bdb/back-hdb monitor: "olmBDBAttributes" previously defined "1.3.6.1.4.1.4203.666.1.55.0.1.1" back-bdb/back-hdb monitor: "olmBDBObjectClasses" previously defined "1.3.6.1.4.1.4203.666.3.16.0.1.1" memberof_db_init: unable to find objectClass="groupOfNames" slaptest: bad configuration file!
The problem is that groupOfNames doesn't exist in the AD-like schema I'm loading. This is with current CVS OpenLDAP.
Andrew Bartlett
On Mittwoch, 28. November 2007, Andrew Bartlett wrote: [..]
Looking at the configuration, it seems this can only currently be configured once - ie, for memberOf. Am I missing how to configure it to also handle an arbitrary number of other attributes? Ideally I would process the AD schema into a configuration file with these details.
I think you can just create multiple instances of the "memberof" Overlay. Like this:
overlay memberof memberof-group-oc group memberof-member-ad member memberof-memberof-ad memberof overlay memberof memberof-group-oc another-oc memberof-member-ad another-member memberof-memberof-ad another-memberof
To start with this module I've decided to just deal with memberOf. However, I can't get the module to start, because while it allows configuration of different schema in theory, it relies on the default schema to exist in practice:
[abartlet@naomi source]$ /usr/local/sbin/slaptest -f /home/data/samba/samba4/clean/source/st/dc/private/ldap/slapd.conf back-bdb/back-hdb monitor: "olmBDBAttributes" previously defined "1.3.6.1.4.1.4203.666.1.55.0.1.1" back-bdb/back-hdb monitor: "olmBDBObjectClasses" previously defined "1.3.6.1.4.1.4203.666.3.16.0.1.1" memberof_db_init: unable to find objectClass="groupOfNames" slaptest: bad configuration file!
The problem is that groupOfNames doesn't exist in the AD-like schema I'm loading. This is with current CVS OpenLDAP.
Yeah, the memberof-Overlay needed the "groupOfNames" objectclass and the "member" Attributetype to initialize correctly. I just committed a change to HEAD to change that. This should fix your problem. Please test.
On Wed, 2007-11-28 at 12:20 +0100, Ralf Haferkamp wrote:
On Mittwoch, 28. November 2007, Andrew Bartlett wrote: [..]
Looking at the configuration, it seems this can only currently be configured once - ie, for memberOf. Am I missing how to configure it to also handle an arbitrary number of other attributes? Ideally I would process the AD schema into a configuration file with these details.
I think you can just create multiple instances of the "memberof" Overlay. Like this:
overlay memberof memberof-group-oc group memberof-member-ad member memberof-memberof-ad memberof overlay memberof memberof-group-oc another-oc memberof-member-ad another-member memberof-memberof-ad another-memberof
I'll try this out. BTW, must the memberof-group-oc be unique? Could I set it to 'top' in all cases, to just key off the attribute? This should simplify the generation from the AD schema.
To start with this module I've decided to just deal with memberOf. However, I can't get the module to start, because while it allows configuration of different schema in theory, it relies on the default schema to exist in practice:
[abartlet@naomi source]$ /usr/local/sbin/slaptest -f /home/data/samba/samba4/clean/source/st/dc/private/ldap/slapd.conf back-bdb/back-hdb monitor: "olmBDBAttributes" previously defined "1.3.6.1.4.1.4203.666.1.55.0.1.1" back-bdb/back-hdb monitor: "olmBDBObjectClasses" previously defined "1.3.6.1.4.1.4203.666.3.16.0.1.1" memberof_db_init: unable to find objectClass="groupOfNames" slaptest: bad configuration file!
The problem is that groupOfNames doesn't exist in the AD-like schema I'm loading. This is with current CVS OpenLDAP.
Yeah, the memberof-Overlay needed the "groupOfNames" objectclass and the "member" Attributetype to initialize correctly. I just committed a change to HEAD to change that. This should fix your problem. Please test.
Sorry about the delay in getting back to you. While I have other issues (probably related to configuration and what things I'm trying to do), I no longer have this error. Thanks!
Andrew Bartlett
On Montag, 3. Dezember 2007, Andrew Bartlett wrote:
On Wed, 2007-11-28 at 12:20 +0100, Ralf Haferkamp wrote:
On Mittwoch, 28. November 2007, Andrew Bartlett wrote: [..]
Looking at the configuration, it seems this can only currently be configured once - ie, for memberOf. Am I missing how to configure it to also handle an arbitrary number of other attributes? Ideally I would process the AD schema into a configuration file with these details.
I think you can just create multiple instances of the "memberof" Overlay. Like this:
overlay memberof memberof-group-oc group memberof-member-ad member memberof-memberof-ad memberof overlay memberof memberof-group-oc another-oc memberof-member-ad another-member memberof-memberof-ad another-memberof
I'll try this out. BTW, must the memberof-group-oc be unique? Could I set it to 'top' in all cases, to just key off the attribute? This should simplify the generation from the AD schema.
Yes, that should work. It might have an impact on performance, though.
-
Andrew Bartlett -
Christian Marg -
Howard Chu -
Pierangelo Masarati -
Ralf Haferkamp