- 1 Setting up Samba as an Active Directory Domain Controller requirements for LDAP server Backends
- 1.1 (De)motivation
- 1.2 Alternatives
- 1.3 Process and experimentation
- 1.4 Development and Testing
- 1.5 Test Infrastructure Requirements
- 1.6 LDAP protocol requirements
- 1.7 Access Control
- 1.8 Schema issues
- 1.9 Replication
- 1.10 Future Behaviour issues
Setting up Samba as an Active Directory Domain Controller requirements for LDAP server Backends
This document attempts to describe some of requirements that a 'general purpose' LDAP directory server must meet to have Samba as an Active Directory Domain Controller 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.
While this is an area of active development in Samba as an Active Directory Domain Controller, it is not supported, or expected to be supported in the near future
This page is a guide to setting up Samba as an Active Directory Domain Controller to use a general purpose LDAP server as the backend. However, unlike with Samba as a classic domain controller using an LDAP Backend this mode of operation is not recommended and is only available to support some esoteric configurations. Even if you provision Samba4 with the LDAP backend, the clients will still communicate with the LDAP service provided by Samba4 on port 389 (this is necessary for correct operation as an Active Directory Domain Controller) and you'll still be forced to use the Active Directory schema. What's more, using the LDAP backend is incompatible with DRS replication. Having removed it, the team is now involved in an experiment at reinstating the supporting code, in support of a long term effort to revive this feature . This does not yet work in any released or development branch. You have been warned.
The currently supported alternatives are to either run Samba as a classic domain controller using pdb_ldapsam, or to use the samba-tool domain classicupgrade process to import the Samba attributes from your existing LDAP backend into the internal LDAP Server.
Process and experimentation
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.
The LDAP directory server backend is not a feature that we have listed as a requirement to issue a Samba4 alpha, and due to the lack of interest from other developers, it is currently tolerated more than liked. (There is a lot of other work to do, and the directory server backened doesn't advance that cause). As such, it should be regarded as an experiment. How well it works and ensuring that it continues to pass the testsuite will help shape viewpoints into the future.
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 occurs 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.
The aim is that 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, on multiple platforms.
Having the relevant parts of the automatically testsuite run against a backend directory will also help avoid silly breakage, and foster confidence.
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, and makes it secure to run on our donated build farm hosts.
In attempting to ensure that the backend directory 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. (We don't have the code to do this at present).
If we can generally avoid queries that require client-side re-evaluation, I hope we can reduce some of the over-complexity currently present in the ldb_map codebase. This code does a wonderful job, but is quite hairy in places.
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.
We need the directory to provide these values, as otherwise direct modifications will not update the USN.
Currently single user
Currently, the Samba4 server connects to the backend directory as a single account. The real end user account is not used, nor is ldap proxy authorization, as ACLs are evaluated in Samba, not in the LDAP server.
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'?
Samba4 ACL gateway?
The other approach is that Samba4, which will understand the NT ACLs on the entry, and which has the full details on the user's group membership, could do all the ACL evaluation, treating the directory server backend as just another DB. External access to the backend directory server should be tightly controlled.
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).
Get effective Rights
If the target server is responsible for access control, then having the ability to get the user's effective rights would be very useful.
For maximum utility, this needs to be in terms of a list of writable attributes on an entry.
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.
Initially, the ldb_map project on which the directory server backend is partly based, was created to attempt to map LDAP servers with a Samba3 schema into something Samba4 could use. The hope was to provide an upgrade path from Samba3, and a way to use existing LDAP infrastructure.
This isn't the focus of the current development, but has provided a testsuite for ldb_map behavior. This area needs work, and the testing script revived.
As it seems at the moment, there are two possible ways we can get replication in Samba4.
- DRS replication
- LDAP replication
However, with the current design, the two cannot be mixed. When Samba is set up to use the LDAP backend, all the modules related to DRS replication are disabled. There are no current plans to mix DRS replication (required to be part of a forest) with LDAP replication.
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 have a similar thing for OpenLDAP, 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.