Samba4/LDAP Backend

Revision as of 03:15, 13 March 2007 by Abartlet (talk | contribs) (Samba4 requirements for LDAP server Backends)

Samba4 requirements for LDAP server Backends

This document attempts to describe some of requirements that a 'general purpose' LDAP server must meet to have Samba4 successfully use it as an LDAP backend.

This is by no means a complete list, but lists things currently known. As the development of this area continues, more requirements will be specified.

Currently supported servers and status

OpenLDAP

OpenLDAP 2.3 is supported, and seems to pass our tests. Known issues are related to bitwise operations: In some versions, if the per-thread errno variable is ERANGE then the bitwise tests will fail.

Fedora DS

Fedora DS 1.1 is supported, and passes all bar the LDAP bitwise operation tests.

Test Infrastructure Requirements

ldapi://

To facilitate testing in our testsuite, we need the LDAP server to either be compiled with our SOCKET_WRAPPER technology, or listen on ldapi:// This just makes running unprivileged testsuites much easier to handle and automate (otherwise, we must run our tests as root).

Foreground process

In attempting to ensure that the LDAP server is not 'left behind' at the conclusion of the tests, it is useful to have the LDAP server stay within the process group of the parent script (ie, not become a deamon). The process group will be terminated if the CPU or wall clock time becomes excessive (trapping run-aways).

LDAP protocol requirements

Bitwise extended match

We test for support for Microsoft's bitwise extended match operations in the testsuite. Microsoft clients use this for operations on the groupType field in particular, and we need the backend server to support these queries.

By supporting this extended match, Samba has to do less work on the query, and in particular does not need to download all possibly matching values to evaluate the search expression.

USN Support

Windows provides a USN to clients, indicating the 'time' (as a increasing integer) that a record was created or modified on this replica.

For OpenLDAP, we read the contextCSN of any partitions and entryCSN/lastModified attributes on records, but ideally we would have these values provided already in integer form, and more closely aligned to the AD behavior.

Access Control

Currently anonymous

Currently, the Samba4 server connects to the backend directory as anonymous, except when provisioning.

When we connect as 'system' we should use either EXTERNAL or DIGEST-MD5 authentication. User authentication could be as forwarded GSSAPI credentials, or more likely some form of impersonation.

NT ACLs in the target directory?

Should the target directory handle NT ACLs, as may be set by some clients (Samba3 old-style ADS join in particular)?

This implies that the target directory needs to understand what SIDs a user has, even for foreign sids. Perhaps forward as an additional SASL 'mech'?

Impersonation

If the target directory server is to handle ACL evaluation (for consistency), we may need to use the LDAP proxy-Authorization support. Alternate options include SASL authorization (which would map more closely to the way we handle this in LDB).

Schema issues

Currently Samba4 uses the AD schema, with every object then given an additional objectClass of extensibleObject.

This clearly isn't ideal, and once we enforce schema compliance for LDB internally, we should start to look at allowing the backend server to enforce schema control.

Minimal essential schema

As Samba4 loads the AD schema by default, we have to avoid conflicting with any schema already installed in the target LDAP server. We hope to provide as much of the schema as possible, for the default case.

Ideally, it should be possible to remove the unessential/conflicting schema elements before the server first starts.

Traditional or ADS Schema?

Should we attempt to map the schema from Samba's AD schema to some 'more normal' AD schema?

Mapping creates a number of complex issues, and restrictions on how the backend server must operate. There are a number of conflicts between the way that Active Directory and more general purpose LDAP servers represent objectClasses. The most ovbious is that 'person' does not require a surname in AD.

There are also a number of attributes that have been added to 'top'. Perhaps the mapping module might always add 'ms_top' as an objectClass, to compensate?

This also raises the question about 'what are the traditional schema elements' and how should we map to them.