Open Directory and Active Directory, Part 1
Pages: 1, 2
lookupd is configured manually and is able to store its configuration data in either netinfo or flat files. This is described accurately in its man page and is not covered here, due to DirectoryService's primary role in access of enterprise directories. DirectoryService and its associated plugins generally store their configuration in individual XML based files within the /Library/Preferences/DirectoryService directory.
[sinister:~] tarbosh% ls /Library/Preferences/DirectoryService/ ContactsNodeConfig.plist DirectoryService.plist ContactsNodeConfigBackup.plist SearchNodeConfig.plist DSLDAPPlugInConfig.clpi SearchNodeConfigBackup.plist DSLDAPv3PlugInConfig.plist
||preferences for OS Authentication path|
||tracks which plug-ins are active|
||LDAPv2 plug-in configuration|
||LDAPv3 plug-in configuration|
||preferences for OS contact path|
Fig 1.3 Config file sample DirectoryService configuration files
These files will usually be maintained by the Directory Access application, which lives in /Applications/Utilities on a default Mac OS X install. Directory Access Interface consists of 3 panes: Services, Authentication, and contacts.
The services pane allows an administrator to configure the host's
DirectoryService plugins to access to various directory services.
A default 10.2.5 install includes NetInfo, LDAPv3, LDAPv2, and
"BSD Configuration Files" (which allows DirectoryService
rather than lookupd to access flat files in /etc). 10.2.6 added
NIS as an option. Notice that there are also plugins not
associated with directories, like Rendezvous, SMB, AppleTalk, and
SLP. These are service discovery mechanisms. In addition to
supplying access to directories, Open Directory also supports
service discovery. We won't concern ourselves with this aspect of
its functionality, since, again, our focus is directories. Each
plugin, all of which are located at
may have a plugin-specific configuration dialog:
This reference isn't meant to be exhaustive so we do not detail the configuration options for all plugins. The LDAPv3 plugin will be covered in some depth in a later article, since it is our primary mechanism for accessing Active Directory. A few concepts are important, though:
- With the exception of the NetInfo plugin, configuration data is stored in a corresponding file in /Library/Preferences/DirectoryService
- Each plugin is capable of accessing one or more external directories. Each external source of data is known as a node. Specifically, the LDAPv2 and LDAPv3 plugins are capable of accessing multiple nodes (directories) simultaneously. For example, perhaps there are both campus-wide iPlanet Directory ,and departmental Active Directory at a large University. The LDAPv2 and LDAPv3 plugins can both be configured to access both of them. The NetInfo plugin, however, is only capable of accessing one NetInfo hierarchy at a time.
- LDAPv2 is a strict subset of LDAPv3, and the LDAPv3 plugin doesn't support the full LDAPv3 specification (for instance, start_tls). Its best, then, to think of the LDAPv3 plugin as a more functional version of it's v2 counterpart, one that includes support for SSL, write operations, and UTF-8 (in addition to a number of features not necessarily associated with LDAP specifications, like static attribute mapping, which we'll discuss later).
The authentication pane allows you to add nodes configured in the services pane to the host's authentication search path. This means that the directory specified in a particular node will be searched by user lookups: getpwnam(), getpwent(), and friends, in addition to their DirectoryService API counterparts. It also implies that user entities that are returned from those lookups may authenticate.
The authentication pane has 3 settings:
- Automatic: Make use of nodes delivered automatically via DHCP or broadcast. This is the default setting.
- Local Directory: Use only the local directory; don't use any external directory services.
- Custom Path: Use nodes explicitly specified in the configuration pane. After configuration in the services pane, you must click add to manually add them to the authentication path.
In order to allow users from a specific node to login, either locally or via directory enabled services like AppleFileServer, the node must appear in the authentication path. This is due to the granular nature of Open Directory. We'll see later that just because we want to access resources from a particular directory, we may not want users from that directory to be able to login to our host.
Out of box, Mac OS X (through 10.2.6) is configured to automatically locate NetInfo and LDAP search nodes--both of which can be returned via DHCP--and add those nodes to the authentication search path. This makes Mac OS X susceptible from a security standpoint to rogue DHCP and directory servers. A good localization or configuration policy will disable this functionality, unless it is explicitly needed, by specifying the search path as local or custom and by disabling automatic retrieval of configuration data in the NetInfo and LDAPv3 plugins.
The contacts pane allows you to add Directory Service nodes to the contacts path. This permits certain directory enabled applications (namely Mail and Address Book in a default Mac OS X install) to access a globally specified directory data. Contacts are configured separately from Authentication; you might want to search a directory without allowing all of the users from that directory to login to your host.
One final capability of Directory Access is remote configuration of Mac OS X Server. Other than manually editing extensive and mostly undocumented XML files, there is no way in Jaguar to configure DirectoryService or any of its plug-ins via ssh. However, on Mac OS X Server, DirectoryService listens on port 625. Remote clients can connect to the DirectoryService daemon by choosing Connect from the Server menu of Directory access. The resulting dialog
will prompt you for administrative credentials of the remote server. Once authenticated, you'll be able to use Directory Access like you were seated at the console of the server.
With a functional understanding of Open Directory we can seek to integrate it with Active Directory. We'll work toward this goal using tools included with Mac OS X, including DirectoryService's LDAPv3 plugin and the system's built in kerberos support. However, it's important to at least mention another option. In addition to the DirectoryService plugins that ship with Mac OS X, Apple provides a flexible API for creating more. Thursby Systems, makers of Dave, recently introduced an Active Directory native plugin. You can read about it here.
Among other things, it
- uses a machine account to access AD,
- uses kerberized LDAP connections to access AD securely, and
- requires no schema modification or additional data to work.
In other words, it allows Windows administrators to integrate Macs into the vast majority of Windows infrastructures seamlessly and securely. The downside, of course, is that it's not included with Mac OS X and is not free. Once again it's worth mentioning that Panther supports vastly increased Active Directory integration features, the details of which we'll discuss at a later date.
LDAPv3 plugin based solutions vary widely in detail. There is no one right answer to the question of Directory Integration. The right answer varies according to site specific configuration issues, political climate, and organizational policy. This article series does not concern itself with the basic details of creating or configuring a node. That is discussed in Apple's documentation and here. Instead the focus is on the options you have in integrating a node with Active Directory. In general, that question revolves around two issues: access and data, which I'll delve into in next week's installment.
Return to MacDevCenter.com