Some remarks on Samba4 with OpenLDAP backend

[Andrew Bartlett]

On Fri, 2009-03-13 at 19:02 +0100, Michael Ströder wrote:
> HI!
> 
> I've tried to set up Samba4/OpenLDAP CVS-RE24 (communicating over LDAPI)
> along these lines for interop testing with web2ldap:
> 
> http://wiki.samba.org/index.php/Samba4/LDAP_Backend/OpenLDAP
> 
> The article is a bit outdated regarding paths but now it works.
> 
> Note that web2ldap is capable of adding/modifying user accounts on MS AD
> W2K3 and set the unicodePwd attribute just fine.
> 
> 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.  

If direct access is desired, perhaps either make it listen on other
ldapi socket, or TCP/IP.

(The other reason for this is due to the need to ensure that the 'make
test' setup does not write outside Samba's own private area).

> 2. There's no access to the subschema subentry allowed on the OpenLDAP
> backend server for e.g. cn=samba-admin,cn=Samba. IMHO that's overly
> restrictive and prevents schema-aware clients from doing the right
> thing. I'd even allow anon access to the subschema subentry. (I have a
> fallback schema in web2ldap but I'd prefer to properly deal with the
> real schema with object classes 'user' and 'samba4Top'.)

I don't really mind if the security on that partition is changed, if you
have a good reason why you need to access the backend directly.

> 3. A one-level search from root returns also subordinate entries of the
> domain-level because of directive defaultsearchbase in slapd.conf. I
> find this annoying. What's the rationale for adding this?
> Fortunately the Samba4 demon on port 389 does not do this. But I'd
> prefer the OpenLDAP demon to also behave "normally". I think this
> directive should only be used in OpenLDAP when you have to integrate
> LDAP clients not capable to use a search root at all.

This is not intentional.  I simply worked off some other 'known working'
slapd.conf to generate the template.  Just like bad smb.conf examples,
I'm sure bad slapd.conf examples also have a near-infinite life in the
web-folklore :-)

> 4. Passwords are auto-generated. That's good. But they are passed as
> command-line args. Since there's a bash history I consider this to be
> bad practice. So passwords should be stored in <prefix>/private/ldap.

That is a very sensible suggestion - in fact, it is already supported by
the C code we support using a credentials file, but not exposed to
python and the python provision scripts.  If you wanted to extend this,
I would be happy to show you around the modifications required.

> 5. I forgot whether it was already considered on samba-technical to
> implement SASL bind with mech EXTERNAL for the LDAPI connection between
> smbd and slapd. This would allow to provision everything without a
> password. (IIRC Fedora DS already has support for this or planned to
> implement it.)

Indeed.  We don't currently support EXTERNAL in the Samba4 client, and
we would have to be careful to cope with both running as root in a
normal install, and running as a non-root user in the testsuite, but
such a configuration would be possible.

> 6. Are slapd and smbd supposed to run as root? I'd prefer to let them
> both run as non-privileged dedicated Unix users, e.g. slapd -u openldap
> -g openldap. This would have to be done in the provision script to get
> ownership/permissions of the OpenLDAP database dir/files right.

While for production operation smbd must run as root, I would welcome
patches to have provision-backend change the LDAP backend database
owning user, and have it suggest the changed slapd.conf command line.

> 7. Do you expect LDAP clients 1. to access smbd on port 389 to manage
> user accounts like on AD or 2. should user accounts be directly managed
> in the LDAP backend server? 1. would require that the AD schema is sent
> out as subschema subentry by smbd. If I understand other messages on the
> list correctly this is the plan. Right?

The way I see it, LDAP clients should never see OpenLDAP directly.  The
only reason to expose OpenLDAP at all is to allow multi-master
replication. 

> 8. How can I encode/decode unicodePwd values from the slapcat-output?
> Some Python module for that? It seems not to be the same value I send to
> AD when setting the unicodePwd.

Why would you want to do that?

In summary, I think most of your concerns come from wanting to have
direct, rather than proxied access to the OpenLDAP server.  Perhaps you
can explain a bit more why you want to do that, and we can come to an
accommodation.

Thanks,

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/20090316/88df89be/attachment.bin