MacDevCenter    
 Published on MacDevCenter (http://www.macdevcenter.com/)
 See this if you're having trouble printing code examples


Open Directory and Active Directory, Part 2

by Michael Bartosh
08/12/2003

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.

Access

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.


Fig 2.1 Directory Access: Connection pane of LDAPv3 node configuration.

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 configuration file, DSLDAPv3PlugInConfig.plist. This file should be considered sensitive stored with restrictive permissions (mode 500).

Access Controls

Mac OSX Conference

Session by Michael Bartosh:
Mac OS X and Active Directory: A Study in Directory Integration

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
October 27-30, 2003
Santa Clara, CA


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, the 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:


Fig 2.2 Directory Access: Querying Active Directory anonymously.

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.

Recommendations

Security

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 here. 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.

Next Time

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.

Michael Bartosh


Return to MacDevCenter.com

Copyright © 2009 O'Reilly Media, Inc.