In addition to collecting data from classic LDAP servers as described in RFC 2307, sebuildla can be used now to get data from Active Directory, but since the latter uses Kerberos-based authentication, a few extra requirements need to be fulfilled on top of standard LDAP setup (with the Simple Authentication bind method). This capability is present in sebuildla from AccessControl build #3317 (i.e., with signatures 12.81.0.3317 and later)
1. ldap_method should be set to 1 (SASL/GSSAPI); for the ldap_hostname token one can use the hostname of any Domain Controller from the AD domain where sebuildla should look for users and groups.
Note that AD schema uses a different attribute to store user name, i.e., it is sAMAccountName instead of uid, so the ldap_uid_attr token must be set to sAMAccountName. To check Active Directory from a Unix point one can use the ldapsearch, which, however, will also require completing Kerberos configuration in order to authenticate the account it is used for prior to authorizing its access to Active Directory.
2. AD performs authentication using Kerberos, so a Kerberos configuration file (its location is platform-dependent, but in most cases it is /etc/krb5.conf) must be configured and present on the Unix endpoint. Below is a sample Kerberos configuration assuming that user/group data must be collected from Active Directory domain called other.net. Note the prescribed use of uppercase letters in the name of Kerberos realms (AD domains in this case). Kerberos has been part of Unix for over 20 years, so its tools and components are well documented in corresponding man pages, e.g., krb5.conf(5), kinit(1).
[libdefaults]
default_realm = OTHER.NET
[realms]
OTHER.NET = {
kdc = dc01.other.net
admin_server = dc01.other.net
}
3. The user corresponding to the Distinguished Name specified in ldap_userdn for standard LDAP servers must authenticate himself to Active Directory and obtain a Kerberos ticket. That user can be a regular user account since only read permissions are needed to gather user and group data. The setting of ldap_userdn token in case of data retrieval from Active Directory does not matter since user identity will be taken out of the Kerberos ticket. For instance, if AD user under whose identity AD data will be collected is called testunxadm and his DN could be something like cn=testunxadm,dc=other,dc=net , one can obtain a Kerberos ticket for that account by running
> kinit testunxadm@OTHER.NET
Note: Kerberos relies on the DNS to resolve artefacts it needs to navigate AD topology, so it is paramount that Unix endpoint can properly resolve names of domain controllers. Microsoft TechNet has many articles explaining the subject, providing recommendations and clarifying typical user errors. It is recommended to run ldapsearch against AD with settings intended for sebuildla as a way to sanity-check one's setup. Here is a practical example from Linux illustrating that the CN attribute of user testunxadm can be retrieved via GSSAPI (Kerberos)-based LDAP search, i.e., the above LDAP and Kerberos setup appears to be functional
> ldapsearch -h dc01.other.net -b dc=other,dc=net -Y GSSAPI '(&(objectClass=user)(sAMAccountName=testun*))' cn
# testunxadm, Users, North America, other.net
dn: CN=testunxadm,OU=Users,OU=North America,DC=other,DC=net
cn: testunxadm
> sebuildla -un
CA ControlMinder: Creating users look-aside database.
CA ControlMinder: Adding data from LDAP DIT to users look-aside database.
Finally, sebuildla -un functionality provides more verbose output when the ldap_verbose token is set to a postive value. This can be very helpful during setup or troubleshooting, e.g., the above command with ldap_verbose token set to 3 would be
SASL authentication to LDAP service on dc01.other.net:389
SASL/GSSAPI authentication started
SASL username: testunxadm@OTHER.NET
SASL SSF: 56
SASL data security layer installed.
loaded 293 user entries prior to adding LDAP data.
Requesting up to 500 LDAP entries with filter (&(&(objectClass=User)(objectCategory=User))(sAMAccountName=a*))
found 232 LDAP objects for (&(&(objectClass=User)(objectCategory=User))(sAMAccountName=a*))
LDAP user data: uidNumber: WRONG MAPPING OR FILTER? sAMAccountName: ausro01
LDAP user data: uidNumber: WRONG MAPPING OR FILTER? sAMAccountName: andri02
LDAP user data: uidNumber: WRONG MAPPING OR FILTER? sAMAccountName: angth01
LDAP user data: uidNumber: WRONG MAPPING OR FILTER? sAMAccountName: aveje01
LDAP user data: uidNumber: 11695 sAMAccountName: axmje01
LDAP user data: uidNumber: WRONG MAPPING OR FILTER? sAMAccountName: agish01
LDAP user data: uidNumber: WRONG MAPPING OR FILTER? sAMAccountName: amacy01
LDAP user data: uidNumber: WRONG MAPPING OR FILTER? sAMAccountName: amajo02
. . .
The lines with WRONG MAPPING OR FILTER? in them merely indicate that the user in question does not have the uid or gid attributes that are necessary for a Unix account, i.e., the account is a pure Windows account. The highlighted line for user axmje01 above shows a user that can be considered a valid Unix account as can be seen from the following:
> sebuildla -U | grep axm
11695 axmje01