- 1 Samba4 requirements for LDAP server Backends
- 1.1 Test Infrastructure Requirements
- 1.2 LDAP protocol requirements
- 1.3 Access Control
- 1.4 Schema issues
- 1.5 ==
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.
Test Infrastructure Requirements
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).
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.
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.
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'?
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).
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.