Open Directory and Active Directory, Part 2by Michael Bartosh
Editor's Note: In this second part of Michael Bartosh's series of articles examining Mac OS X's Directory Services architecture, he looks at access. If you haven't read part one yet, you should probably take a look before reading this one. Also, note that Michael is a speaker at the O'Reilly Mac OS X Conference in his session titled, Mac OS X and Active Directory: A Study in Directory Integration. If you haven't registered for this event yet, this article will give you a good idea of the quality content that will be presented there.
Apple's LDAP plugin requires access to the directory before any user may log in. That is, the credentials of the user logging in may not be used to bind to the directory to access data. Users may authenticate with an LDAP bind operation, using the credentials entered into the loginwindow, but this connection is used only to authenticate the user, not to query the directory for data. Access to the directory is generally configured in the "Connection" pane of an LDAPv3 node.
Unless the LDAP directory is accessible by anonymous query, user credentials
to access the AD must be entered into the Directory Access application
in the form of a user's distinguished name and password. These credentials
are stored on the filesystem in reversible format in the LDAPv3 plugin's
DSLDAPv3PlugInConfig.plist. This file
should be considered sensitive stored with restrictive permissions (mode
Session by Michael Bartosh:
Participants in this session will be exposed to Mac OS X's directory services infrastructure in depth, and will learn to leverage its capabilities to maximize end user satisfaction while minimizing impact on enterprise systems. While Active Directory is the primary example, these strategies are applicable to almost any directory service.
O'Reilly Mac OS X Conference
Out of box, anonymous users are not allowed to look up data stored in
Active Directory. Thus, AD requires that user credentials be entered
and stored as described above. Unless an AD administrator chooses to
allow anonymous LDAP access (which is neither suggested nor likely),
the best practice is to create a domain user that is allowed only to
search the domain via the LDAP interface. This can be achieved by creating
a domain-local policy that disallows local login to that user. Keep
in mind that in a secure environment, all principals are required to
have regularly changed passwords. This would require an update of each
and every Mac accessing the directory (each time the password is changed,
DSLDAPv3PlugInConfig.plist file must be updated). For
that purpose we recommend Radmind.
As an added security measure, this special-purpose user can be granted access to only the data that Mac OS X requires for AD integration. This data will vary from site to site, as described in Data below. Should you wish to allow anonymous queries on certain AD attributes, you can find Microsoft documentation here and a step-by-step process here. Be aware that anonymous queries to AD require a Distinguished Name of "anonymous". The Connection pane of the node's configuration dialog should look something like this:
Some sites require that no users have access to any user record other than their own. In some cases this is a requirement of federal, state, or local law; in others, it's simply a matter of user privacy. This presents quite a difficulty in the context of the LDAPv3 plugin. If a special purpose "ldap-search" user has been created, any user logging into the client system will have access to the same data as that user, either via the lookupd command or libc system calls. It is feasible at such sites to allow directory access from a single machine. That is, the credentials of the machines primary user may be used in Directory Access to query AD.
This presents issues on a couple of levels. First, it reduces the security of the system by storing the user's kerberos password in reversible format on the client's filesystem. Second, if the user's LDAP password changes, that change must be maintained in Directory Access. This is feasible primarily in an office setting where machines are generally dedicated to a single user and access to workstations is secured. Our recommendation is to implement a policy allowing access to non-sensitive data and use a special purpose ldap-user who is allowed to query only those attributes required for Mac OS X authentication. This is not always feasible, however.
Connecting to the Directory
Before 10.2.5, the LDAPv3 plugin opened an LDAP connection to the directory on system startup. This connection persisted until it was broken and re-established or until the client powered down. In small environments, this was not an issue. However, as the number of Mac clients increases, so will connection load. 500 Macs would generate between 500-550 simultaneous persistent connections under normal circumstances. Versions of Jaguar through 10.2.3 additionally suffered from a bug that could cause multiple LDAP connections per client to open, which could result in an unresponsive client console. This often resulted in exceeded connection limits on the LDAP server (8 to 10 connections per client were not uncommon). 10.2.5 introduced an idle timeout; after a few minutes of inactivity, the LDAPv3 plugin will drop its connection to the directory. You can adjust idle timeout by adding a key value pair to DSLDAPv3PlugInConfig.plist:
<key>Idle Timeout in minutes</key> <integer>5</integer>
Unfortunately, 10.2.5 also introduced a bug that sometimes prevents the DirectoryService daemon from being restarted once it's died. This is a show stopper in many environments.
- Divide Mac clients among multiple domain controllers. In large environments, do not configure all Macs to query a single domain controller.
- Set reasonable per-client connection limits on the directory
- If you're experiencing the above bug, upgrade to a Mac OS version that does not display this behavior. If this isn't feasible, configure a cron job to kill the DirectoryService daemon every 30 minutes. It will restart itself when needed, and this will close spurious connections to the directory. Do not attempt this with 10.2.5 or 10.2.6.
LDAP is an insecure protocol. Although optional security features are built into the LDAPv3 specification (SASL, TLS, etc.), they are not required by default and in practice are not widely enough used. To get around this issue Windows Active Directory clients use kerberized LDAP to access domain controllers. Initial credentials are supplied by a machine account in the domain (the credentials for which are regularly changed automatically, without user intervention). The domain controller (acting as a standard KDC in this case) is authenticated to the client in addition to the client authenticating to the domain. This mutual initial distrust is built into kerberos and prevents man-in-the-middle attacks. Although a complete discussion of kerberos is well beyond the scope of this document, this presents a reasonably secure infrastructure. See MIT's kerberos site for details.
Although kerberos is well integrated into Mac OS X, the LDAPv3 plugin is not able to make a kerberized connection to the AD. The highest out of box common denominator for LDAP security between the LDAPv3 plugin and AD is a plain LDAP bind. LDAP binds are not very secure and happen over clear text. Credentials can be maliciously harvested using tcpdump or any other network monitor. The contents of the packet look something like this:
21:40:03.591439 10.1.0.6.49153 > w2k.example.com.ldap: P 1:59(58) ack 1 win 3330 4 <nop,nop,timestamp 1344485319 0> (DF) 0x0000 4500 006e 0872 4000 4006 1e10 0a01 0006 E..n.r@.@....... 0x0010 0a01 0001 c001 0185 d4d5 5dd7 3739 b2ec ..........].79.. 0x0020 8018 8218 1469 0000 0101 080a 5023 37c7 .....i......P#7. 0x0030 0000 0000 3038 0201 0160 3302 0103 0427 ....08...`3....' 0x0040 434e 3d53 616d 2041 6461 6d73 2c43 4e3d CN=Sam.Adams,CN= 0x0050 5573 6572 732c 4443 3d65 7861 6d70 6c65 Users,DC=example 0x0060 2c44 433d 636f 6d80 0561 7070 6c65 ,DC=com..apple
Mac OS X is capable of making an
ldaps:// (LDAP over SSL)
request. While inferior to kerberized connections (during which passwords
never travel over the network), it does present a reasonable amount
of security. Unfortunately, AD is not configured out of the box to accept
ldaps connections. To do so requires significant administration resources
(in planning, testing, and implementation). Microsoft's directions are
Additionally, SSL on a large scale increases the system load on the
domain controller. At a small scale this is not significant, but as
connection load increases it does become an important factor.
In part three I'll cover "data". Once Mac OS X has access to a directory, it needs to find certain data in order to recognize users, groups and any other data you've decided to use. I'll go over several strategies for directory data integration.
Return to MacDevCenter.com