3.1. Binding to Active Directory
When binding to an Active Directory server, keep in mind that it is an individualized process; each workstation will need a computer account named for the machine created in the directory. While it is possible to pre-populate these accounts, the Apple Active Directory plug-in will create a computer account in Active Directory at the time of binding with the correct credentials if one does not already exist. As with Windows client account, each OS X computer account contains a unique pre-shared key used to authenticate that individual machine to the directory. This individualistic nature is an important aspect to consider when looking at automating the process. The process of binding a machine to Active Directory can be accomplished either through the use of a GUI interface or through a decently robust set of command-line tools. We will discuss the command-line components of this process (dscl and dsconfigad) later in this chapter. First, we will look at the manual GUI tools used to bind a Mac OS X machine into Active Directory.
3.1.1. Directory Utility
The Apple DirectoryService framework is a set of code allowing for modularized access to the different directory service plug-ins available (including third-party plug-ins). The graphical application for configuring the plug-ins is Directory Utility (Called Directory Access in 10.4). This application is bundled with all versions of Mac OS X, and in older versions can be found in /Applications/Utilities. With 10.6, Apple has migrated access functionality to the Login Options of the Accounts System Preference. The Directory Utility Application is not gone in 10.6; though, it has simply been relocated to /System/Library/CoreServices, a directory used by OS X to house internal support Applications. Once opened, you will need to authenticate as a local administrator to make changes to the directory services plug-in. If you are not automating this step, you will need to supply your on-site technicians with both local and directory administrator credentials to manually complete this process. You can customize the policies in your environment to supply desktop technicians with Active Directory accounts that only have access to bind computers into the domain; likewise, you can provide non-administrators with access to edit local configurations by modifying the file /etc/authorization. Specifically, directory service changes are defined by the authorization right 'system.services.directory.configure'. Through the modification of this right, you can grant access to change directory settings to your non-admin users.
To start the binding process, open the Accounts System Preference pane by clicking on the Apple menu in the top-left corner of your screen, selecting System Preferences and then clicking on Accounts. Next, click on the Login Options, as shown in Figure 3-1.
Figure 3.1. Login options screen of accounts system preference pane
To authorize your session to edit the System Preference, click on the lock in the lower-left corner of the screen. Then click on the button to Join... in the field for Network Account Server. This will bring up a pop-up screen that simply has a field for a server name or domain name. Type the name of your domain. After a time, the screen will expand so that you can enter the ID that the computer you are binding will have once it joins Active Directory, the user name of an account in your Active Directory that has credentials to bind to Active Directory, and the password for that account. Supply this information as seen in Figure 3-2 and then click on the OK button.
Figure 3.2. Binding to Active Directory
In an effort to simplify the binding process, Apple allows you to bind to both Open and Active Directory servers from this initial screen. Keep in mind that using this screen will only allow you to bind and not configure granular settings within either of the plug-ins, though this can be done at a later time, if necessary. To bind using a screen that allows you to configure more granular settings, click on Open Directory Utility... and then click on Services in the upper-left hand corner of the screen, as you can see in Figure 3-3.
Figure 3.3. Services in Directory Utility
Use the lock in the lower-left corner of the screen to authenticate again and then from Services in the Directory Utility toolbar double-click on the entry for Active Directory. You will then be prompted with three fields by default, which are also shown in Figure 3-4:
Active Directory Forest: If there is only one Forest then the Forest will invariably be the same name as the domain name, but check with an Active Directory administrator to confirm this is the case if you encounter binding issues.
Active Directory Domain: Note that you are not connecting to a specific host, but rather a domain. The active directory plug-in will use this domain to look up special records in DNS called service records (SRV) to find the Domain Controller you need to connect to. This process is unique to the Active Directory plug-in and heavily relies on the client's configured DNS servers to be correctly pointing at servers that host these records or can facilitate communication to these servers; properly configured DNS is absolutely paramount for this process to succeed.
Computer ID: This is the name of the computer account record as it will appear in the Active Directory domain. Note that this name also typically becomes a DNS name on the network, so if you are configuring a client named "wintermute" the Apple AD plug-in will dynamically request a DNS record be created for "wintermute.wallcity.org" if the Active Directory domain is wallcity.org and points to all the configured IP addresses (including virtual) for that client; the specified value should generally conform to DNS standards regarding A records, as defined in RFC 1035 accessible at http://www.ietf.org/rfc/rfc1035.txt. For best results, the length of this value should be a maximum 15 characters, and should generally follow the Letter Digit Hyphen (LDH) Rule.
NOTE
For more information on Resource Records, see the following TechNet article: http://technet.microsoft.com/en-us/library/cc783389(WS.10).aspx.
Figure 3.4. Binding to Active Directory Using Directory Utility
|
Next click on the Bind button and you will be asked to authenticate into the Active Directory domain using the following fields, as you can see in Figure 3-5:
Username: Contains any valid user account that is capable of joining computers to the domain. Additionally, this user must have rights to create new objects in the container or organizational unit you are saving the computer into, access that can be delegated by the Active Directory administrator. If your Active Directory environment is strictly controlled, you may have to request a computer record be pre-populated rather than attempt to use the supplied credentials to create one.
Password: The password for the above account.
Computer OU: The search base for the Organizational Unit that clients will be added to. For example, if you create an Organizational Unit called Macs in a domain called pretendco.com then you would use CN=Macs,DC=pretendco,DC=com in this field.
Use for authentication: Allows for authenticating into the client computer using a valid Active Directory username and password.
Use for contacts: Allows for searching for contacts using Address Book.
Figure 3.5. Binding to Active Directory Using Directory Utility
The most common binding problem with Active Directory environments is with the Active Directory domain's DNS having an incomplete set of service records. If we had a nickel for every time a Windows admin swore up and down there were no problems on their servers, only to have all problems resolved by a quick and dirty fix—an ipconfig /rebuilddns command runs from a domain controller hosting the Active Directory integrated DNS by rebuilding the required service records. Beyond DNS, a number of binding issues are caused between incompatible policies between Mac OS X and Active Directory. For example, LDAP signing as a requirement was not supported in 10.4.
NOTE
As described in Chapter 1,you can use the directory services debug log and potentially tcpdump (which can be used to monitor port 389 to review traffic to and from your Active Directory Domain Controllers) to more granularly isolate binding issues.
Using the bind screen from the Accounts System Preference pane, you were not prompted for the organizational unit to place the computer record in whether you wanted to allow login or contact lookups. The computer record is automatically generated based on the host name of the computer you are using to bind and the authentication and contact lookups are assumed to be used. If you have not pre-populated the computer record, your computer account will be placed in the default container, computers. To continue with the previous pretendco.com example, Organizational Units are these containers, which are accessed using a convention whereas the container is a CN followed by a DC for each part of a fully qualified domain name. Therefore, if you were to enter the Computers container of mydomain.com instead of pretendco.com from our previous example, you would use cn=Computers,dc=domain,dc=com.
3.1.1.1. Testing Your Connection
Once you have successfully bound your computer to Active Directory, you should test the connection. First, verify that the light is green beside the Active Directory service as is listed in the Directory Utility application. A green light here is typically a pretty good indicator that everything is fine, but it's never a bad idea to test further. The most straightforward test would simply be to attempt login as a directory user, but logging out and then back is not efficient, especially if there are problems resulting in login window delays. More efficiently, you can verify binding from the command line (and should test it either way). As previously referenced, an integral part of logging in on Mac OS X is a user account's UniqueID attribute. You can verify that user resolution is happening and view the UniqueID using the id command. To do so from a command-line environment, enter the id command followed by the username of a directory account:
id zsmith uid=1763670396(zsmith) gid=703907591(WALLCITYdomain users) groups=703907591(WALLCITYdomain users),1842785604(WALLCITYadministrators)
The id command can indirectly display a local conflict. The Active Directory plug-in generates UniqueIDs, and with AD typically these numbers have 10 digits. In contrast, a standard local account, such as one that was configured using the Account System Preference pane and the setup assistant at first boot, has an id starting at 501, incrementing upwards. Open Directory users start at 1025. This makes it possible at first glance to determine the approximate origin of an account. For example, if you saw a unique id in the range of 600 to 1,000 then the account was likely initially created using the accounts system preference pane.
If the id command fails with id: jdoe: no such user check the account you are using for testing to see whether it exists and check that your computer is set to correctly try to "Search" for users in Active Directory. Typically this "Search Path" is filled in automatically for you by the Directory Utility application at the time of binding. However, if you are manually configuring or attempting to troubleshoot an automated binding you can verify this configuration in Directory Utility. Open the Directory Utility, choose Show Advanced Settings from the windows tool bar, select Search Policy, and verify the /Active Directory/... line item is displayed. Contrary to popular belief, the order listed is not typically relevant for user and group resolution, as you will see the local directory is always accessed first, then typically it should be the next network directory that contains users. If you are having problems that are resolved by moving /Active Directory up in the search order, you may have a configuration problem in your other directory servers or a conflict in the namespace that users occupy.
While id is probably the easiest, the best utility for testing your directory services is dscl. The utility provides an interface for programmatically interacting with the DirectoryServices Application Programming Interfaces (APIs). This program can be run via an interactive shell or from within scripts. After first binding to Active Directory, use dscl to test that the directory is available and that user resolution (the ability to resolve user accounts) is working. While you could just logout and log back in depending on any problems encountered, you can more easily see that binding is working from the command line. From a shell prompt, use the dscl command followed by the computer or path to connect to. In order to establish a connection to the currently running DirectoryService daemon, we'll use localhost:
dscl localhost
The syntax for moving through the configured directory services is much like navigating a filesystem or ftp server from the command line. Once you have initiated your session it will show an interactive prompt (>). Use the ls command to list the DirectoryService Plug-ins. If you do not see Active Directory listed, the plug-in itself is not enabled. Even if you are bound to an Active Directory domain, you will not be able to navigate to the directory node until this plug-in is enabled (by default only the LDAPv3 and local plug-ins are enabled), although when you use the Directory Utility to bind systems the Active Directory plug-in is enabled by default. Review the"Binding to Active Directory with a Script" section to see an example of how to enable this plug-in from the command line.
The ls command will show you the currently enabled plug-ins (including third party) in the list. In addition, you will be able to navigate into the Contacts and Search paths, which will show you the hierarchy of all configured and enabled plug-ins. You can then type cd followed by the name of any item in the list of current plug-ins.
Active Directory BSD Local Search Contact
In this case, type cd 'Active Directory'.
NOTE
Standard command-line conventions apply here in regard to space. Be sure to use quotes around the path when using dscl as Active Directory is one of the few plug-ins that has a space in the name. Alternatively, you can use the built in tab auto-completion to automatically quote this path for you.
Once you have changed directories into the Active Directory plug-in, you will see the Active Directory domains and forests that were previously configured at bind time in the appropriate nesting order. The Apple Active Directory plug-in only allows you to configure one Active Directory forest at a time, the default behavior is to allow authentication from all domains within a forest on the local machine. This is an important note, as it means that depending on your organization's directory topology you may not be able to see the users if you are in a separate forest. If you would like to restrict access to this computer (or server) to only one domain, you will need to uncheck the Allow authentication from any domain in the forest button in the Directory Utility or run the command dsconfigad -all domains disable, depending on your configuration. You will see either All Domains or your domain name, wallcity.org when listing this value in dscl.
/Active Directory > ls All Domains
To test that your binding worked correctly you can change directory into the respective value and do an ls. If you receive an error when changing directory, your Active Directory binding has most likely either failed or the current DirectoryService daemon has lost contact with your sites Domain Controller.
/Active Directory > cd 'All Domains' /Active Directory/All Domains > ls CertificateAuthorities Computers FileMakerServers Groups Mounts People Printers Users
A common procedure used to verify connectivity is to use the dscl command along with the read verb to view the attributes associated with a given account. This will allow you to verify that user lookup is working within the Active Directory plug-in itself and look for any potential issues, such as a missing attribute. While you could ls Users, depending on the size of your organization you may not receive all of the information that you are looking for. By default, the LDAP server in Active Directory will return a maximum of 1,000 results. Although many more can be enumerated, this is just a limitation for how many are shown at once. Therefore, we will simply cd into the appropriate directory and then use read to view the attributes for a known good user account:
/Active Directory/All Domains > cd Users /Active Directory/All Domains/Users > read zsmith dsAttrTypeNative:accountExpires: 456878888655687 dsAttrTypeNative:ADDomain: wallcity.org dsAttrTypeNative:badPasswordTime: 0 dsAttrTypeNative:badPwdCount: 0 dsAttrTypeNative:cn: Charles Edge dsAttrTypeNative:codePage: 0 dsAttrTypeNative:countryCode: 0 dsAttrTypeNative:displayName: Zack Smith dsAttrTypeNative:distinguishedName: CN=Zack Smith,CN=Users,DC=wallcity,DC=org continued...
|
One thing to keep in mind is that while viewing data from the Active Directory plug-in directly (by changing directories into it), you can verify that you have a connection to your organization's directory services. However, simply being able to view the raw directory service data does not in fact mean that you can authenticate against it. As with dsconfigldap in Chapter 2, the final step is to use the information gathered about your test user and verify that you user matches in the /Search path as well.
/Active Directory/All Domains/Users > read /Search/Users/zsmith dsAttrTypeNative:accountExpires: 456878097655687 dsAttrTypeNative:ADDomain: wallcity.org dsAttrTypeNative:badPasswordTime: 0 dsAttrTypeNative:badPwdCount: 0 dsAttrTypeNative:cn: Charles Edge dsAttrTypeNative:codePage: 0 dsAttrTypeNative:countryCode: 0 dsAttrTypeNative:displayName: Zack Smith dsAttrTypeNative:distinguishedName: CN=Zack Smith,CN=Users,DC=wallcity,DC=org continued...
If the two read commands return different results you have namespace collision, which could possibly be resolved by altering your Search path (this was covered in much more detail in Chapter 2). In some cases, it may be necessary to simply delete the conflicting user account. You can view the current search path with dscl along with a read verb, the path, and the attribute to display (in this case, /Search SearchPath).
/Active Directory > read /Search SearchPath SearchPath: /Local/Default /BSD/local /Active Directory/All Domains /Active Directory >
Once you have verified that user result ion is functional from the DirectoryService daemon, you can verify that Authentication is correctly happening (so far we have only verified that user resolution is possible). Type exit to end your interactive dscl session for the localhost.
/Active Directory/All Domains/Users > exit Goodbye
3.1.1.2. Testing Authentication
Being able to look up user accounts in Active Directory allows you to apply them to local facilities, such as file system permissions, and to nest them in groups on other configured directory systems. Authentication is a corner stone of any modern Directory Service. Apple provides a command-line tool called dirt in Mac OS X 10.5 that you can leverage to access the DirectoryServices Application Programming Interface and perform authentication queries.
dirt -u zsmith -p 'bw4r3c3n1nj4s' Call to dsGetRecordList returned count = 1 with Status : eDSNoErr : (0) Call to checkpw(): Bad Password path: /Local/Default Username: zsmith Password: bw4r3c3n1nj4s Error : eDSAuthFailed : (−14090)
NOTE
You can also run dirt interactively without supplying the -p flag. This is typically beneficial as passwords will be stored in the current users shell history when providing this parameter from the command line. If you use dirt with a password specified from the command line be sure to clear your history, history -c, and you may want to securely remove your history files as well, srm $HISTORY. Dirt is more thoroughly covered in Chapter 2.
As you can see from the example, the password specified was not correct, and the Directory Service request had an error with the numerical value of −14090. These error codes are documented as part of the DirectoryService API and can also be checked using the DirectoryServices main page.
NOTE
While dirt was used to test authentication in Mac OS X 10.5, dscl is used to test authentication in Mac OS X 10.6.
3.1.1.3. Testing Authentication at the Login Window
Once you have tested user resolution with dscl and authentication with dirt, you are ready to begin a graphical login test. While you could have skipped to this step, it's normally best to test that "raw" authentication is working before trying to troubleshoot and isolate any issues encountered at a graphical prompt such as the login window, as seen in Figure 3-6.
Figure 3.6. Login window
Logout from the Apple menu and login as your test Active Directory user account, keeping in mind that many other factors will affect this type of login compared to the command-line tests you have previously performed. If all steps taken previously with id, dscl, and dirt succeed without issue, but you still cannot login then you likely have a home-directory specific problem. When you are logging in, you can use the text immediately below Mac OS X to click through various informational items about the system. One of these will indicate that Network Accounts Available, a useful troubleshooting step to verifying that you can authenticate.
3.1.2. Home Directories and the Apple Active Directory Plug-in
Home Directories can be one of the more complicated aspects of integrating Mac OS X with Active Directory. But it doesn't have to be. The Active Directory plug-in supplied by Apple by default creates a local home directory in the /Users/ directory. If you do not want to synchronize data to another location using Mobile homes or leverage network-based home directories then your work is made easier and you are basically done. However, depending on your required configuration you might have many tasks remaining. For example, a very common procedure on Microsoft Windows is to redirect folders to network share points. The most common folder to be redirected is My Documents. Redirection of My Documents via Group Policy object is not applicable to Mac OS X, and so the fun begins.
To configure the location of a home directory use Directory Utility from /Applications/Utilities folder (10.5) or /System/Library/CoreServices(10.6). Next, click on Services in the Directory Utility Toolbar and then check the box to enable Active Directory. If you are not already operating with elevated privileges, then you will be prompted for the credentials of an account with access to add data into Active Directory. Go ahead and type that in and then click on the Show Advanced Options disclosure triangle, as shown in Figure 3-7. Here, you will see a number of options to control the User Experience, Mappings, and Administrative options. The home directory options are in the beginning stored in the User Experience tab.
Figure 3.7. User environment with Active Directory
The very first option is to Create mobile account at login. By checking this box, you will cache an account locally, allowing login from the login window even when a system is not on your network. When a user logs in using an Active Directory account, they will now be prompted for whether the account will be a mobile account. Unchecking the box for Require confirmation before creating a mobile account will then suppress the dialog box and simply create the account automatically.
Next, choose whether to Use UNC path from Active Directory to derive network home location (which is a check-box to enable home folders that reside on a network path). Combined with mobile accounts and OS X's home folder syncing, this option allows data in the home folder to be available even when systems are not on the local network. This option is also preferable in order to keep the load minimized on your file servers that house home directories throughout the day.
|
If you have decided to leverage the Use UNC path from Active Directory option, then network home directories will be used. You will then have an option to specify the Network Protocol that will be used for home directories. Both AFP and SMB are supported. In Active Directory Users and Groups, when you set a users profile setting for the home folder location, the setting is provided via a UNC path; \serversharefolder. The Active Directory plug-in converts the UNC path to a standard URL. So \serversharefolder becomes afp://server/share/folder or smb://server/share/folder according to which protocol you have selected.
Once you have configured all of the options for home folders that are appropriate for your account, you can test your settings by logging in as an Active Directory username and password that has a profile location which has been configured. Then verify that login occurs as intended and the appropriate home directory is utilized given the paths and folders entered both into Active Directory and the plug-in. If you have any issues, attempt to mount paths manually and check the permissions on the destination directory structure.
3.1.2.1. DNS Concerns
Active Directory uses Sites to assign domain controllers to specific subnets on your network. The Apple Active Directory plug-in uses DNS to lookup a Global Catalog server for your domain and subsequently queries it to find the correct Domain controller to bind to. You can manually view these DNS records which use the SRV or "service" type to hold their information within an Active Directory integrated DNS network.
Open Terminal in /Applications/Utility, and enter in the following command to do a lookup on the service record to locate the global catalog:
dig -t SRV _gc._tcp.wallcity.org ; <<>> DiG 9.4.2-P2 <<>> -t SRV _gc._tcp.wallcity.org ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50668 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; QUESTION SECTION: ;_gc._tcp.wallcity.org. IN SRV ;; ANSWER SECTION: _gc._tcp.wallcity.org. 600 IN SRV 0 100 3268 grodd.wallcity.org. ;; ADDITIONAL SECTION: grodd.wallcity.org. 3600 IN A 192.168.53.249 ;; Query time: 59 msec ;; SERVER: 192.168.53.249#53(192.168.53.249) ;; WHEN: Sun Jun 7 21:52:50 2009 ;; MSG SIZE rcvd: 93
The answer to the question that you are posing to dig is in the Answer Section. Here, it is shown as grodd.wallcity.org. If you do not receive the name of a domain controller, you will want to check that you are using the correct DNS servers for your site. A common error is related to using an external DNS server that has been manually configured at some previous time (e.g., 4.2.2.1). This forces your lookup to use your organization's external DNS provider, which may not match your internal DNS server, especially if you use an internal domain like .local.