Some remarks on Samba4 with OpenLDAP backend

[Andrew Bartlett]

On Fri, 2009-03-20 at 23:01 +0100, Michael Ströder wrote:
> Andrew Bartlett wrote:
> > On Fri, 2009-03-20 at 18:28 +0100, Michael Ströder wrote:
> >> Andrew Bartlett wrote:
> >>> On Fri, 2009-03-13 at 19:02 +0100, Michael Ströder wrote:
> >>>> I hope you don't get this message wrong. The job including the
> >>>> provisioning scripts is well done. Still I have some questions and remarks:
> >>>>
> >>>> 1. IMHO access to the LDAPI socket should also be possible for other
> >>>> LDAP clients on the same system. E.g. I'm running my web2ldap as
> >>>> separate user on the same system and probably I'd like to access the
> >>>> OpenLDAP backend directly. So IMHO the socket file
> >>>> <prefix>/private/ldap/ldapi should be moved to another directory where
> >>>> other clients have access. Access control should happen in slapd itself
> >>>> by ACLs (as already done).
> >>> The reason it is done like this is because I would strongly prefer that
> >>> the backend was not accessed directly.
> >> Why? The OpenLDAP backend is a LDAPv3-compliant server already enforcing
> >> a particular schema.
> > 
> > For me, this isn't a good enough reason:  Just because it can be done,
> > does not mean it should be done.  
> > 
> > The stack of modules that Samba applies above the OpenLDAP server are
> > there for a reason, and enforce restrictions and apply semantics above
> > and beyond those applied by the backend.  That is why we don't allow
> > windows clients to connect to the backend directly. 
> 
> I'm not talking about regular LDAP access for Windows clients. I meant
> custom admin processes (e.g. for account syncing with external databases
> etc.).

Given that slapd can take multiple -h arguments, what is stopping you
adding an additional ldapi socket for your needs in that case?

I would not object to a default sasl mapping being added that maps a
SASL external bind over LDAPI to a privileged identity (preferably read
only, but I am willing to be convinced).

Samba currently uses DIGEST-MD5 because it allows us to easily work as
non-root in the 'make test' process, without having to deal with the UID
problem.  (Otherwise such support and such a rule would no doubt have
been added earlier). 

> > For example, Samba maintains the 'name' attribute in OpenLDAP manually
> > (mapping it to Samba4RDN).  If the backend were administered directly,
> > nothing would keep 'name' in sync with the RDN.  
> > 
> > While I will ask for this to be corrected (as it would also remove a
> > race), it gives you an idea of the things that stand in the way.
> 
> Since I know the weird AD schema a little bit I'm quite aware of what
> you have to do in Samba4 regarding schema mapping.
> 
> > I'm still confused why you don't want to connect via Samba4.
> 
> E.g. SASL/EXTERNAL over Unix Domain Socket with mapping to an admin's
> authz-DN for sync processes without having to provide a password. In
> general I'd like to be able to do everything I'm used to do with
> OpenLDAP if needed (obeying the DIT and schema requirements off course).

It would be a trivial task to add EXTERNAL as an available SASL
mechanism to Samba4.  More difficult would be to determine what it
mapped to in terms of an identity, but even so, a simple mapping from
'local root on LDAPi == SYSTEM' is practical.

Would that solve your concerns?

Andrew Bartlett

-- 
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20090403/32634a42/attachment.bin