- 1 Samba4 requirements for LDAP server Backends
- 1.1 Process
- 1.2 Development and Testing
- 1.3 Currently supported servers and status
- 1.4 Test Infrastructure Requirements
- 1.5 LDAP protocol requirements
- 1.6 Access Control
- 1.7 Schema issues
- 1.8 Future Behaviour issues
Samba4 requirements for LDAP server Backends
This document attempts to describe some of requirements that a 'general purpose' LDAP directory server must meet to have Samba4 successfully use it as a 'directory 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, development of this feature is by a process of iterative experimentation. The Samba4 test suite is expanding, and the hope is to continue to have the LDAP tests pass, as we cover more and more of the server's expected behavior.
Development and Testing
To ensure reproducible results, and because it is too easy to leave a directory server half-configured, or misconfigured, most of the testing of this feature occours within the Samba4 test system, and 'make testenv' in particular. This environment creates a directory server instance, and provisions a fresh instance of the directory.
In theory, any potential user can download Samba4 from SVN, install the appropriate directory server binaries, and run the testsuite. Likewise, any tests should be consistently reproduced.
Currently supported servers and status
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.
If OpenLDAP's slapd is in /usr/sbin, or in the $PATH, then this should test Samba4 against OpenLDAP
TEST_LDAP=yes make test
Fedora DS 1.1 is supported, and passes all bar the LDAP bitwise operation tests.
Current blockers (blocking 'make test' from passing):
- Need USN support
- Need bitwise operations
Currently Fedora DS isn't automaticlly detected. You need to specify the installed prefix.
TEST_LDAP=yes FEDORA_DS_PREFIX=/my/fedora-ds/prefix make test
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://
SOCKET_WRAPPER is a technology by which we restrain Samba's network communication to a virtual network of unix domain sockets. This allows Samba to bind to 'privileged ports', despite not running as root. Similarly, it prevents other users of the host running the test from penetrating the test environment.
While it is possible to run our testsuite without SOCKET_WRAPPER, it makes running unprivileged testsuites much easier to handle and automate. It also ensures that we do not have accidental communication between test environments on the host.
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.
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'?
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.
Future Behaviour issues
While not currently an issue, Samba4 will need to improve it's handling of the member/memberOf linked attributes. Handling these with a transaction in Samba4 is fine, but if the backend server does not support transactions, then the update is presumably racy.
Ideally, these would be calculated in the backend.
Unique ID allocation
Fedora DS has a plugin to generate unique integer values on the directory backend. We need to start using this, when available, and validate that it meets our behavior requirements. (We don't have a test for this at the moment).
Support for remote transactions would be very useful, to handle some of these things client-side. How this interacts with multi-master replication is a very interesting question.