Joining the Active Directory with OS X.3 Client

• Introduction
• The University of Melbourne environment
• Configuration
• Limitations
• Troubleshooting

Introduction

These notes are based on OS X.3.5.  If you are having problems joining or authenticating, please update to the latest version of OS X.  In particular, OS X.3.4 has a number of problems with binding to Active Directories.

Apple's latest operating system, OS X.3 Panther, offers support for joining a Microsoft Windows 2000 Active Directory (AD) using Kerberos authentication. This document explains how to join an Apple computer running OS X.3 to the Active Directory, as well as pointing out several limitations in Apple's implementation.

Please note: Every OS X.3 computer authenticating against the AD requires a Client Access License (CAL).

The major features of Panther's AD support include:

• Login authentication using Active Directory username and passwords
• Single sign on access to file servers and printers
• Local caching of authentication credentials, particularly useful for laptop users
• Authentication against multiple domains
• Local administration by specified AD groups
• Support for local or remote SSH configuration

The University of Melbourne environment

The University of Melbourne Active Directory consists of two domains: UNIMELB for staff, and STUDENT for students. Panther can be configured to authenticate against either domain or both (explained in more detail in the configuration section) allowing both staff and students to use the same computers.

As part of their employment registration, University staff members are assigned unique user IDs when they join the University. These user IDs are common across all the Unix systems at the University and allow staff members to easily keep ownership permissions when transfering files between computers. OS X.3 is based on Unix and when authenticating against the AD, OS X.3 will give users their central user ID.

Panther uses a method similar to Windows to authenticate users against the AD and is subject to the same rules and restrictions. Importantly, this means accounts will be locked out after multiple unsucessful logins just as they would on a Windows computer.

Anyone who has used the "Get info" GUI tool with large directory databases would be familiar with the spinning ball of death when changing file permissions. Apple have worked around this in a fairly sensible way; by default only local users and groups are displayed with an "other" option bringing up the directory database users (which are cached for future permission use). There is also a "cancel" option for when the spinning ball becomes too much.

A large number (if not all) of departments at the university use nested groups within the university's domain structure. Unfortunately, OS X.3 does not recognise or use nested groups which is likely to be a major problem for many administrators and users. At this stage there appears to be no simple way to configure OS X.3 to recognise these groups, however we are investigating using Apple's Open Directory as an intermediary (though this will require administering groups in Open Directory rather than the Active Directory).

Group permissions are cached by OS X.3 for more efficient operation, however the caching is very slow, and updates can take up to 48 hours to be recached by OS X.3. According to Apple, there is no work around this delay.

Configuration

Note: Before starting, ensure:

• That you have configured your client to use a network time server (ntp.unimelb.edu.au) through "System Preferences" » "Date and Time" » "Set Date & Time automatically"
• Your client in registered in both IPREG and Active Directory with the same name and that forward and reverse DNS lookups are working

Graphic User Interface configuration

Active Directory authentication is configured using the Directory Access program in the Applications / Utilities folder.

Highlight the "Active Directory" line and click "Configure".

Click "Show Advanced Options" to display a sheet similar to the following, though missing the configuration details which you will need to enter.  Be sure to set the following options

• Active Directory Forest - unimelb.edu.au
• Active Directory Domain - unimelb.edu.au (or student.unimelb.edu.au)
• Computer ID - your computer name
• Map UID to attribute - UniqueID (case sensitive and optional - see note below)

Selecting the "Map UID" option will ensure that your OSX login will be given the same UID as your account on the university's central servers (like www-publish for example) meaning permissions will be correctly set when you transfer file archives to these central servers. This field is populated for centrally managed AD accounts but will be empty for other accounts and will cause your login to fail. If you are unsure about this option, it is recommended that you do not use it.

If you would like to use both the staff and student domains, select "Authenticate in multiple domains".

Once you have entered these details, click "Bind" to join the Active Directory.

You will need to enter:

• a OS X.3 username and password account with administrator rights
• an Active Directory username and password with privileges to join computers to the Active Directory
• the location of the computer within the Active Directory

The default Active Directory location of OU=Computers,DC=unimelb,DC=edu,DC=au will not work and you will need to specify a different location. An example location is as follows:

OU=ID,OU=Client Services,OU=LANSG,OU=Test,DC=unimelb,DC=edu,DC=au

If you get an error that you have insufficient privileges to join the Active Directory, it may be related to the group permissions issue discussed below.  Otherwise you should see the following.

Click "OK" and your computer has joined the Active Directory.  You can leave the Active Directory by clicking "Unbind".

The final step is to add the Active Directory to OS X.3's authentication method list.  This is done by selecting the "Authentication" tab and adding a "Custom path".

Users will now be able to logon using their Active Directory credentials and connect to file servers without having to enter their username and password a second time.  Note that the OS X.3 graphical configuration does not support the use of network home directories - users will be given a local home directory instead though their AD home directory will be mounted as a share point.  You need to use the command line to configure support for AD home directories (see below).

You should be sure to disable automatic login and enable automatic logout on computers on which Active Directory based authentication is used. This can be accomplished under System Preferences > Security.

Command line configuration

Configuration of AD authentication can also be done via the command line using the dsconfigad utility. This can be run locally or remotely using SSH and gives access to a wider range of configuration options than the Directory Access utility. Using the command line it is possible to use the Active Directory network home as the home directory for OS X users.

dsconfigad -a clientname -u username -p password -ou "distinguished name of ou or container" -forest fully_qualified_forest -domain fully_qualified_domain

dsconfigad -show will list information about your current configuration. See man dsconfigad for more information.

Regardless of the configuration method, the information supplied is stored in the /Library/Preferences/DirectoryService/ActiveDirectory.plist file. Group membership information is stored in the same directory, in the ADGroupCache.plist file.

Limitations

With thanks to Elliot Gingold.

Group permissions and computer accounts

It is standard practice at this University to delegate authority for full control of Departmental OUs to the local administrators from that department. This is done by using standard Microsoft recommended AGLP procedures. We first create a Global security group into which we place the accounts of the local (departmental) administrators. A domain local group is then created into which this global group is placed. The full control is given to the domain local group.

As a result of this configuration, the departmental administrators are able to create computer accounts in the OU for which they have full control. Further, they are able to join Windows machines to the domain using this account. Illogically, this does not work when the machine we are trying to join is a Mac. In this case we get a message that the user does not have sufficient privileges (even though they have got full control over both the OU and the computer account).

After some testing, we are able to demonstrate that the problem lies in the way that the AD based groups are handled. If the local administrator is directly given full control (or even more limited privileges) over the computer account, the process works successfully. This is also the case if control is given to a group that the user account is directly a member of (such as the above mentioned global group). However, the extra level of redirection, standard applied in Windows setups, is not recognised. Hence full control in the AD sense may mean no access rights when a Mac is being joined.

Our current workaround advice to local administrators is to add an extra step to their usual (windows based) procedures and give the intended joining administrator explicit permission to join that computer to the domain when setting up the computer account in the AD. This is despite the fat that (s)he already has full control on that object as far as the AD is concerned.

Windows based network drives do not appear automatically

The Mac OS X Server Open Directory Administration guide for 10.3 clearly states:

The plug-in also tells Mac OS X to mount the user's Windows home directory (as specified in the Active Directory user account) to mount on the desktop as a share point.

On our first attempts this just did not happen. However, we realised that this was because of the way that the users Window's home directories are entered into the AD. They used a netbios type path, in our case \\id-staff\users\username. This, of course cannot be resolved directly by the Mac system as it doesn't support netbios names. We were able to confirm that this was indeed the problem by changing the entry to include the full dns name, viz (in our case) \\id-staff.its.unimelb.edu.au\users\username. When this was done the share point was automatically mounted on logon as expected.

Rather than changing the AD entries of thousands of users, we thought it better to add the domain suffix to the DNS search path on the Mac clients, thus allowing the address to be resolved by DNS. Hence, in the above case, the suffix its.unimelb.edu.au was added. This, however, made no difference and AD home directories mapped in the original way did not appear. Thus the DNS extensions were not being considered in this step. Note that the system itself was using them; successful manual connections could be made with the format smb://id-staff/sharename. (Before adding the suffix to the DNS configuration this, of course, would not have worked.)

Hence the problem is that the Active Directory plug-in module does not make full use of the information in the DNS configuration.

Troubleshooting

If you are having problems with authentication, try unbinding your OS X client machine, deleting the computer account in the Active Directory and then recreating and rebinding the machine. You should wait approximately ten to fifteen minutes between the deletion and recreation of accounts to allow for the Active Directory to replicate.

For problems with binding to the Active Directory, the MacWindows site should be your first visit. It is a useful resource for lots of Mac and Windows integration issues.