[Fedora-directory-devel] LDAP/Samba 4 summary
by Andrew Bartlett
(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(a)symas.com>
To: OpenLDAP-devel(a)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(a)symas.com>
To: Andrew Bartlett <abartlet(a)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 http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc. http://redhat.com
16 years
[Fedora-directory-devel] Please review: Bug 388021: MMR breaks from master that has been reinited
by Rich Megginson
https://bugzilla.redhat.com/show_bug.cgi?id=388021
Resolves: bug 388021
Bug Description: MMR breaks from master that has been reinited
Reviewed by: ???
Files: see diff
Branch: HEAD
Fix Description: This problem occurs when you have two or more masters,
and you have updates that have originated at a master that have been
sent to other masters (so that the other masters have a valid min/max
csn for that replica in the ruv). If that master needs to be
reinitialized for some reason (crash, etc.) the reinit will erase the
changelog. The RUV for that master will now contain CSNs that are not
in the changelog. If that master attempts to update another master, it
will first look at the RUV from the consumer, which will contain the old
CSNs, and it will look for those CSNs in the changelog, fail, and abort
the update process, meaning this master can no longer send updates to
other servers.
The solution is for the master to just use the min CSN in its own RUV as
the new starting point, if it has not been purged. In the case of
purging, if the CSN is not found, this means the consumer is too far
behind and must be reinitialized.
Platforms tested: RHEL5 x86_64
Flag Day: no
Doc impact: no
https://bugzilla.redhat.com/attachment.cgi?id=263531&action=diff
16 years
[Fedora-directory-devel] Plugin questions
by Jonathan Barber
I'm having a look (again) at writing a couple of plugins, the aspects
I'm interested in are:
1) Updating samba hashes when an entries userpassword is updated (both
through the password extop and LDAP replace/add)
2) Automatically generating posixGroup memberUid attributes from
an entry of objectclass groupOfUniquenames and the DNs refered to
by the uniqueName attributes of the entry.
For the password updating, I've looked at the passwd_exop plugin
(out of curiosity, why is it not in the plugin directory heirarchy?),
and it'd be nice to piggyback on it, allowing the passwd_extop plugin to
deal with determining whether or not the connection is secure,
generating a new password if required, and for my plugin not to change
the samba hash until the userPassword has been succesfully changed.
Obviously, I'd need to also implement a postop plugin to catch straight
modifies as well.
With some experimentation, it appears possible to have two plugins for
the same extop OID, but is there a way for the extop plugins to specify
order of operation (the PDF plugin manual suggests not on page 50, but
then later suggest alphabetical ordering may be possible, and later says
that SLAPI_PLUGIN_(START|CLOSE)_FN functions are ordered)?
Or, is it better to implement as a entry store plugin and look
modifications to the userpassword attribute (assuming that at that point
the etxop must have worked and the password isn't hashed at this point)?
The post op plugins don't seem to see operations of extops, is this
designed behaviour?
Assuming there is a way of wrapping the existing password-exop plugin,
to generate the hashes I was thinking of taking the SMB hashing
algorithims from samba and wrapping them in a shamelessly stolen
pwdstorage type plugin and then using slapi_encode(). Is this sane?
For the posixGroup generation, I've prototyped the idea with a postop
computed attribute - which appears to work okay, but means that searches
for entries containing a particular memberUid doesn't work, i.e.:
$ ldapsearch -b "cn=test,o=base" memberuid
dn: cn=test,o=base
memberuid: foo
$ ldapsearch -b "cn=test,o=base" "(memberuid=foo)"
$
Looking at the cos plugin, it seems to use virtual attributes, and this
looks like a better approach. If so, is there any documentation on
virtual attributes and their interface apart from the code and the
vattrsp_template plugin (and the cos/roles/presence plugins)?
What are good methods for triggering virtual attributes on an entry
(assuming that you don't want to apply it to all the entries): tag the
entries with a particular objectclass? Provide search filters in the
plugin config that define the objects?
Thanks for your assistance.
--
Jonathan Barber
High Performance Computing Analyst
Tel. +44 (0) 1382 386389
16 years, 1 month
[Fedora-directory-devel] Fedora Directory Server and AzMan
by Geykel Raul Moreno Ceballos
Hello,
I wanted to know if there is any feature on Fedora Directory Server similar
to Microsoft Authorization Manager "AzMan" or if you're planning to do
something like that...
--
Regards,
Geykel Raul
_________________________
It claims to be fully automatic, but actually you have to push this little
button here.
—Gentleman John Killian
16 years, 1 month
