Volume Number: 23 (2007)
Issue Number: 10
Column Tag: MacEnterprise, networking

Strangers in a foreign land

Integrating OS X with Active Directory

By Philip Rinehart, Yale University

Of the topics that come up on the Macenterprise list, Active Directory and its integration with OS X is discussed frequently. Why? Many environments are using Active Directory for integration for the Windows side of the house, and many Mac administrators don't want to manage the information store separately for Macs alone. This month we will look at some tips for working with the Active Directory plug-in. Let's get started!

Binding, what is it? Directory Services uses a machine account and "binds" the account to the Active Directory domain. When logging in, the authentication framework is able to use the bound machine's account for non-local users. As a result, a user is granted access to a machine without a local account. With the Active Directory plug-in, there are a number of intricacies that make binding difficult. We will look at one of the most common issues. Before we begin this discussion, though, remember to check forward and reverse DNS, a common binding problem. For more information about testing, check out the article here, http://macenterprise.org/content/view/305/84.

Finding my Organizational Unit

Often, an administrator does not have access to the default Organizational Unit used by the Active Directory plug-in. How does an administrator find their Organizational Unit then? Fortunately, the tools for performing a lookup are built into OS X! Let's look at a rather verbose command.

ldapsearch -LLL -Hldap://yourdomaincontroller.ad.test -x -D "admin@ad.test" -b "dc=ad,dc=test" -W  "cn=activedirectorycomputerobjectname" dn

Looks rather complicated doesn't it? Fortunately, it isn't that hard to understand once we dissect it a little bit. The first option, -LLL is not strictly necessary. However, using it omits comments, restricts the output to LDIFv1 (not important here), and the last L prevents printing of the LDIF version.

Next, the -H option is specified. This option is very important! Enter the URI of a domain controller that has a copy of the Global Catalog. Ldapsearch uses this domain controller to look up information about a computer account.

Next, the -x option is used for simple authentication, not SSL. In some cases, SSL is not used on domain controllers. The -D option is important, as it supplies the Active Directory credentials that are used to authenticate for the LDAP search.

-b provides the search base. The search base is the point in the LDAP tree where the search should begin. If unsure, enter the top level of the forest. -W is similar to using the -x option, telling ldapsearch to prompt for the password, instead of supplying it with the ldapsearch command.

The last two entries are used to get the actual Organizational Unit path. The first option "cn=activedirectorycomputerobjectname" looks for the computer account in Active Directory. The last option tells ldapsearch that only the dn attribute is important. It's o.k. not to specify it, but every attribute is then returned. Sounds like a lot, doesn't it? Try executing the command once. After you have the hang of it, you will find how powerful ldapsearch can be. As a sanity check, here's an example of how the ldapsearch results might appear:

dn: CN=mbp,OU=One,OU=Two,OU=Three,OU=Four,DC=ad,DC=test

With this information, it's easy to determine the OU path for machine binding. Note however that the machine account must exist before this search is executed. The command and its results could also be wrapped in Applescript, an Automator action, or any other scripting language. Once the machine is bound, the fun begins!

One of the hidden gems of the Active Directory plug-in is the ability to use "static maps". Usage of static maps was originally conceived for usage with the LDAP plug-in, but it can now be used for mapping any needed attributes. Let's use an example. On the list, a discussion about using NFS shares on Active Directory asked about how to provide an attribute for each user logging in that would be exactly the same. Static maps to the rescue! Here's how to do it:

This will require a little bit of command line magic. Open a terminal, and enter the following command:

dsconfigad -staticmap attributetype attributevalue

Three attributes should not be statically mapped, UID, RecordName and GeneratedUID. As stated in the man page, mapping these attributes may produce "unexpected" results. What is the syntax? It's pretty simple, first the attribute value. Attribute values are preceded by a pound sign "#". If the goal is to have every non-local user use the same value, enter #value to provide each user with that value at login. Another feature, variable mappings, is not available with the Active Directory plug-in. It should also be noted that using static maps is only available from the command line using dsconfigad.

Timeout values

Controlling the timeout values for the Active Directory plug-in involves editing the ActiveDirectory.plist in /Library/Preferences/DirectoryService. First, note that this procedure is completely unsupported by Apple! A very common problem occurs with mobile accounts and Active Directory is extremely slow logins. This problem commonly occurs due to the fact that the Domain Controller is firewalled, and unavailable outside the corporate network. For each Domain Controller, a value of 240 seconds is assigned. Imagine what happens when the laptop user goes home. Login times, and even wake from sleep times can become almost unbearably long. Fortunately, an administrator who knows what values to change in the plist can alter them, reducing the timeout times manually. Open the ActiveDirectory.plist in your favorite editor. Next search for the following entries:

<key>LDAP Connection Timeout</key>
<string>240</string>

This entry usually occurs in multiple places. Depending on your environment, change the value to a lower value. Restart the computer, and the timeout values should be in effect. It has been reported that for some environments the value may get overwritten, but in my experience it has worked.

Question marks in the Dock

The last thing that appeared recently is the appearance of a host of question marks in the dock on Intel-based machines when using the Active Directory plug-in with mobile accounts. Credit Mike Yocom and Brian Warsing for this solution. It is a bit involved, but does solve the problem quite nicely.

Step one: Convert com.apple.dock.plist for each user to xml. This task is best accomplished with a loginhook. Here is the command:

plutil -convert xml1 -o /tmp/foo.xml com.apple.dock.plist

Step two: Use a bit of xmlmagic, using xsltproc to filter out "_CFURLAliasData" entries from the plist.

xsltproc -o com.apple.dock.plist /path/to/style-sheet/com-apple-dock-style.xsl /tmp/foo.xml

And the required style sheet:

<?xml version='1.0' encoding='utf-8'?>
<xsl:stylesheet version='1.0'
xmlns:xsl='http://www.w3.org/1999/XSL/Transform'>
<xsl:output method='xml' version='1.0' encoding='utf-8' indent='yes'
doctype-public="-//Apple Computer//DTD PLIST 1.0//EN"
doctype-system="http://www.apple.com/DTDs/PropertyList-1.0.dtd"/>
<!-- This template copies the entire root -->
<xsl:template match="@*|node()">
    <xsl:copy>
        <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
</xsl:template>
<!-- This template removes the _CFURLAliasData node -->
<xsl:template match="array/dict/dict/dict/key">
    <xsl:variable name="foo">
        <xsl:value-of select="." />
    </xsl:variable>
    <xsl:choose>
        <xsl:when test="$foo = '_CFURLAliasData'">
            <!-- Do nothing. I mean don't print it -->
        </xsl:when>
        <xsl:otherwise>
            <!-- Output a copy of the orig. node -->
            <xsl:copy-of select="." />
        </xsl:otherwise>
    </xsl:choose>
</xsl:template>
<!-- This template dumps the data nodes with the alias data -->
<xsl:template match="array/dict/dict/dict/data">
    <xsl:for-each select="." />
</xsl:template>
</xsl:stylesheet>

Step 3: There is no step 3!

It really is that simple once all of the pieces are in place, and solves the immediate problem so that question marks will not appear in the dock. This month, we've tackled some of the most recent issues with Active Directory. As always, Active Directory integration continues to be a very complex problem, as each environment has unique qualities. Keep sending in feedback to Apple, and keep discussing on the lists, to make the Active Directory plug-in as good as it can be! One last thing, check out the following Best Practices paper about Active Directory integration from Apple: http://images.apple.com/itpro/pdf/AD_Best_Practices_2.0.pdf. It also supplies very useful information about troubleshooting and integration. Until next month, see you on the lists!

Philip Rinehart is co-chair of the steering committee leading the Mac OS X Enterprise Project (macenterprise.org) and is the Lead Mac Analyst at Yale University. He has been using Macintosh Computers since the days of the Macintosh SE, and Mac OS X since its Developer Preview Release. Before coming to Yale, he worked as a Unix system administrator for a dot-com company. He can be reached at: philip.rinehart@yale.edu. The MacEnterprise project is a community of IT professionals sharing information and solutions to support Macs in an enterprise. We collaborate on the deployment, management, and integration of Mac OS X client and server computers into multi-platform computing environments.