3.2. Bind to AD

You will need two administrative usernames to bind to Active Directory, a local administrator and a domain administrator. The local administrator is used to write the configuration files to protected directories like /Library/Preferences/DirectoryService. This administrator can be replaced with the root user when running scripts to bind to Active Directory (e.g., a Package Installer that runs a post-flight script as root to bind to Active Directory). It's worth noting that the dsconfigad command does not need to run as root as it will use the directory service APIs to determine your admin membership based around rules stored in /etc/authorization. You could create a different group for administration in addition to the default "admin" group that would allow local administration of many components, such as binding. However, giving out admin access for the "right" that Active Directory uses would give them access to quite a bit of the systems authorization dialogs and so would effectively be overkill for just trying to delegate a non-standard admin to bind.

In addition to the local administrative credentials, you will need a domain administrator. This delegate administrator needs to have access to join computers to the domain and also write access to the organizational unit that you specify if you are using the "Services" binding section of Directory utility or the -ou option of dsconfigad. This domain administrator should be created with a very small amount of privileges other than domain addition, as you may need to give this username and password out to your onsite IT liaisons and embed it in scripts.

The following is an example of using the dsconfigad command. As you can see, we are specifying the domain administrator's password right on the line, and this would result in the password potentially being available in the shells history depending on how we run the command. We do not need to run sudo when running dsconfigad, as it will effectively do the privilege request on its own, and prompt for the password of the current user to escalate the privileges for the operation. Later, we will discuss using this command in a script.

dsconfigad -f -a mycomputername -u domainadmin -p domainadminspassword -domain mydomain.com

Additionally, you can set the Active Directory plug-in settings one at a time using dsconfigad, while these options can also be set on the joining command. Keep in mind this ability to granularly set all plug-in options on the fly as you will be able to push out a change whether to create a mobile account on login using any tool capable of sending Unix style commands or scripts (such as Apple Remote Desktop). Like the previous command, sudo is never required as the dsconfigad command will determine admin rights on its own, though when calling the utility from a non-interactive tool, such as ARD, you will want to execute the commands with root privileges.

dsconfigad -mobile enable

One aspect common to many Active Directory deployments in imaging environments is the automation of binding. This is done because a bound system cannot be directly built into a "Gold Master" image, as the Computer ID of each imaged host will be different. For instance if one were to bind to Active Directory within a system that was to be cloned, the Active Directory preferences would be pushed out to all machines cloned from that image. These preferences contain the machine account name and password used for authenticating the joined computer to the Active Directory domain. While this configuration initially would allow authentication in most environments, once the computer password was cycled or once the machines were unbound, then all cloned systems would stop being able to authenticate. For this reason, joining or "binding" to the directory is then performed as a post flight operation on the cloned systems after first reboot. Imaging tools like Deploy Studio and the Casper suite include built-in scripts with graphical wrappers for accomplishing this purpose.

3.2.1. Naming Conventions and Scripting Automated Binding

One of the single most important decisions that will you make when determining the feasibility of a binding script will be your naming convention. This is because depending on your asset tag vendor you may have to work within a specified convention that does not correspond to anything that can be queried automatically on a fresh machine. If your asset tags were consecutive numerical values or a sequence of alphanumeric values set by the manufacturer, then you will have to match that value to a specified piece of hardware manually. Getting user input for specifics, such as asset tags, will mean that at least for your first boot, a live human being will have to be present at the time of binding to enter in this value. Most third-party imaging tools have the ability to show a dialog box that allows the imager to enter this information and have it pass to the script as a parameter. Two examples of this follow, one is Deploy Studios workflow step and the other is the Casper suites positional parameter configuration option. If you are using either one of these tools, it is suggested you consider using this functionality. However, if you are using another deployment methodology you may need to either have your script prompt the user for information, or provide this information via a pre-populated datastore, such as a csv file.

If you are ordering a large quantity of Mac OS X workstations from Apple directly, you consider asking your rep to provide you with a delimited list of Machine Access Control (MAC) addresses. Using this list, you can pre-assign hardware addresses to your organization's asset tag system or database. However, if you are dealing with existing inventory, you may still be required to prompt your imaging team for this information or at least collate it beforehand. If you are relegated to prompting your imaging team for this information a good technique is to store this custom name within a machine's firmware. Mac OS X provides a way of manipulating firmware variables using the /usr/sbin/nvram command. However, nvram cannot be assumed to be persistent, so it is best to maintain this data in a spreadsheet or database.

Binding to Active Directory can be autonomously accomplished using two main tools, dscl and dsconfigad. However, the Active Directory plug-in is not enabled by default and when looking at a binding script one major consideration is to enable this plug-in so that any bound forest will be available for use in the authentication search path for the system. You can do this by pre-populating this setting which is stored in the DirectoryServices.plist file /Library/Preferences/DirectoryService/DirectoryService.plist using the following command:

defaults write /Library/Preferences/DirectoryService/DirectoryService 

"Active Directory" Active

We often recommend to actually add this "enabled" copy of this file in your image prior to deployment. As if you programmatically have to enable the plug-in, you must restart the DirectoryService deamon to have it pick up on the changes. This process while only slightly intrusive can increase the time it takes a system to become usable when binding at startup or first boot automatically.

As shown earlier, using the Terminal application (found at /Applications/Utilities) can be leveraged to create a simple binding script using dsconfigad. However, this only allows you to bind to Active Directory and does not add the directory to the currently configured /Search or /Contact paths. This is an important difference when using the command line as it is an integrated step when using the graphical tools to add newly configured domains to the computers authentication search policies.

dsconfigad -f -a mycomputername -u domainadmin -p domainadminspassword -domain mydomain.com

Once you have bound through the command line, the Active Directory domain will need to be added to your search path. To do so, you will use dsclfor testing binding. In this case, we will use it to change information in the /Search (where information regarding your search policy is stored). Therefore, first change the SearchPolicy attribute to custom by using the following command:

dscl /Search -change / SearchPolicy dsAttrTypeStandard:LSPSearchPath 

dsAttrTypeStandard:CSPSearchPath

dscl /Search -append / dsAttrTypeStandard:CSPSearchPath "/Active Directory/All Domains/"

As the previous code shows, you can also enable options in the active directory plug-in granularly. When specifying multiple advanced options, you can specify each with their own invocation of dsconfigad, or you can supply them all together via a single command. When specifying multiple options, the command can become a bit unruly, but the same result is achieved. Each option from the GUI translates to an option (or flag, if you will) at the command-line interface. There are a number of other options that are available, but each is likely not to be required for all cases.

• Basic Options—Commonly Used:

• -a computerid: name of the computer to add to the domain (if none is specified then the default with be the hostname)

• -f: force the process (i.e., remove the existing entry from the Active Directory plug-in)

• -r: remove computer from domain (unbind)

• -luusername: username of an administrative local account

• -lppassword: password of the administrative local account defined with -lu

• -uusername: username of an Active Directory administrator

• -ppassword: password of the Active Directory administrator specified with -u

• -ou dn: fully qualified LDAP DN of container for the computer (defaults to CN=Computers)

• -domain fqdn: fully qualified DNS name of Active Directory Domain

• -show: show current configuration for Active Directory (this option doesn't make any modifications to the directory or the Active Directory plug-in)

Advanced Options—User Experience:

• -mobile: enable or disable mobile user accounts for offline use

• -mobileconfirm: enable or disable warning for mobile account creation

• -localhome: enable or disable force home directory to local drive

• -useuncpath: enable or disable use Windows UNC for network home

• -protocol: afp or smb change protocol used when mounting home

• -shell: none for no shell or specify a default shell /bin/bash

Advanced Options—Mappings:

• -uidattribute: name of attribute to be used for UNIX uid field

• -nouid: generate the UID from the Active Directory GUID

• -gidattribute: name of attribute to be used for UNIX gid field

• -nogid: generate the GID from the Active Directory information

• -ggidattribute: name of attribute to be used for UNIX group gid field

• -noggid: generate the group GID from the Active Directory GUID

Advanced Options —Administrative:

• -preferredserver: fully qualified domain name of the preferred Domain Controller

• -nopreferred: do not use a preferred server for queries

• -groups "1,2,...": list of groups that are granted Admin privileges on local workstation

• -nogroups: disable the use of groups that were specified in the -groups for granting Admin privileges

• -alldomains: enable or disable allows authentication from any domain in the forest

• -packetsign: disable, allow, or require to enable packet signing

• -packetencrypt: disable, allow, or require to enable packet encryption

• -namespace: forest or domain, where forest qualifies all usernames

• -passinterval: how often to change computer trust account password in days

If your environment requires customization of the Active Directory binding screens, the previous options can be used to granularly configure the options you would otherwise use in the screens in Directory Utility. You can also access a few that have not yet been added.

3.2.2. Map UID and GID

As previously mentioned, Mac OS X requires certain attributes to be able to login, such as primary group ID and Unique ID. As Active Directory does not contain the Unique ID by default, this value must be generated on the fly using some other kind of unique information. One important attribute of this generation is that it cannot be completely random; it is important that every system bound to Active Directory resolves the same UniqueID for any respective user. To accomplish this, Apple uses the first 32 bytes of the user's GUID to generate a numerical value used as a statically mapped value for the Mac OS X Unique ID.

As the plug-in can run the same mathematical operation on the GUID on two different machines and received the same value, it acts as a practical substitute for manually configuring these values in your environment. Windows Server 2003 R2 and higher have a schema attribute called unixid, which could be used to store custom values in the directory. If your organization is already using unix clients that authenticate to Active Directory, then you may already have this information populated in the Directory. Mapping this information on the Mac OS X side is often only beneficial for consistency. However, it can play a vital authorization rule when using the NFS file sharing protocol, which uses the local systems UID to map privileges on remote server shares mounted on the clients system. If your organization does have these fields populated, it is incredibly important to make sure that these fields are populated automatically when you ingest new users. WindowsServer 2008 can do this using ADSI or Power Shell Active Directory command lets. Quest Software has some examples for manipulating large numbers of Active Directory fields in a programmatic fashion using this "new" language.

By default, UID and GID attributes are not mapped, but rather generated when you are using dsconfigad to bind a computer to Active Directory. To map the default fields referenced previously, open Directory Utility from /Applications/Utilities and then click on Services in the Directory Utility toolbar. From here, fill in the basic Active Directory binding information from earlier. Once you have done so, click on the disclosure triangle for Show Advanced Options and from the resultant screen, click on the Mappings tab.

From the Mappings tab, enter the information for the Active Directory attribute to map UID and GID information to. Alternatively, dsconfigad can be leveraged to map fields not included in the GUI. To do so you will use the -staticmap flag followed by the attribute type and then the value for the specified attribute.

3.2.3. Namespace Support Using dsconfigad

By default, dsconfigad assumes that your forest name is the same as your domain name, or authentication will only succeed to the domain that was specified when the system was bound. Some environments have multiple domains. Active Directory allows two accounts with the same username (although not the same GUID) to exist with a given forest, provided they are in separate domains. The Directory Utility allows you to specify either the forest or a specific domain, allowing you to control the scope in which a client system will authenticate against at bind time. When bound to a forest, the AD plug-in allows you to go a step further, providing the ability to authenticate to separate domains within a forest by adding the domain name to your login credentials.

But you don't want to have to unbind and rebind every time you'll log into a different domain, if you will be switching between domains often. To provide you with the option to login using multiple domains within one forest, you can use the -namespace flag followed by domain. The -namespace flag then prefixes the domain name to all accounts that are located in the forest. If you have conflicting accounts in separate domains then the computer should be bound into the domain with which your account resides. To enable namespace support you would use the following command:

dsconfigad -namespace forest

Once run, you will authenticate against the forest and will need to specify the domain name in front of the username every time a user authenticates to the system. If you would like to switch back to using domain namespace at a later date, you can specify the -namespace flag with domain as the setting and you will no longer have to enter this.

3.2.4. Active Directory Packet Encryption Options

The Active Directory plug-in can be configured to enable the encryption options Apple has developed for communications between the Active Directory plug-in and Active Directory Domain Controllers. These include packet encryption, packet signing, and a timeout value for setting the computer account password rotation interval with your Active Directory domain controllers. These options are configured either post or during bind time using the dsconfigad command.

A number of Active Directory environments require packet signing in order to block man in the middle attacks and therefore to verify the authenticity of data being exchanged between the Active Directory plug-in and Active Directory, thus protecting both the domain and the client. From the Active Directory perspective, configuring packet signing requirements is a policy configured from an Active Directory domain controller. Active Directory password policies let you to allow or even require packet signing from the client for LDAP traffic, the protocol that data will be exchanged in this scenario. By default, packet signing is an allowed option for clients in Windows Server 2003 and Windows Server 2008, but is not required for client systems.

While not the default setting, it is a good practice. Therefore, many environments require packet signing for Active Directory clients. In Mac OS X if you want to require packet signing for the client to communicate the server then this would further validate that communication is signed (and therefore authentic), so you can set the packet signing setting to require as well for a more highly secure solution. If you require packet signing from either the server side or the client side, then you should verify signing is an allowed option, if not required on the other or you may run into incompatibility issues. To change packet signing options in Mac OS X, you would use the -packetsign flag with dsconfigad. Settings available with the -packetsignflag include: allow, disable, and require. Therefore, to configure dsconfigad to require packet signing use the following command:

dsconfigad -packetsign require

If the change is successful, then you will see the following output:

Settings changed successfully

Packet encryption is another option in Mac OS X and Active Directory. Packet encryption keeps the contents as secure as they are authentic by forcing data to be encrypted. To enable packet encryption, use the -packetencryption flag with the same settings available with the -packetsignflag (allow, disable, and require). As with packet signing, verify that both the server and client support encryption before setting the option to required, although for high security environments (or most environments these days) it is a good idea to set the client and the server to require both authentication and signing. To set encryption requirements for the client, use the following command:

dsconfigad -packetencrypt require

If the change is successful, then you will see the following output:

Settings changed successfully

Every computer that is bound to Active Directory has a computer account, and that computer account in turn has a password. Active Directory rotates these passwords routinely. The Active Directory plug-in supports the rotation by using the -passinterval flag with dsconfigad. The passinterval can be set and when set, defines how often, in terms of days between the password rotation intervals.

dsconfigad -passinterval 7

All of the settings in this section can be set or changed during bind time or following bind time, and can be independent of any other settings.