Some remarks on Samba4 with OpenLDAP backend

[Michael Ströder]

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.

> (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).

Hmm. On my system I used --prefix=/opt/samba4 and therefore this stuff
is under /opt/samba4/private. But I really wonder why you don't have a
directory for storing publicly readable stuff and the really protected
stuff for key material, password database etc. Something other demon
processes usually do under /var/lib/<demon-name>.

>> 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.

I could imagine that people will try to manage the user accounts or
other configuration-related stuff directly in the OpenLDAP backend. And
given that there's still a long way to go until schema stuff is fully
implemented in Samba4 this seems to be a valid reason to me. Or some
admins might want to sync data with a LDAP client running on the same
box binding with SASL/EXTERNAL without a password.
In any case the OpenLDAP backend should behave like a normal LDAP servr
IMHO.

>> 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 :-)

Yes, the famous copy&paste-based... :-)
So please remove defaultsearchbase directive.

>> 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.

It would be possible to handle the credentials file directly within
Python or is there a C wrapper module needed?

>> 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.

I'd vote for running as non-root in a normal install.

>> 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,

Why?

> 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.

Let's see.

>> 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. 

I disagree, see above.

>> 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?

I forgot the auto-generated Administrator password. :-)
And I'd simply like to reset it by manipulating the unicodePwd attribute
in the OpenLDAP backend.

Ciao, Michael.