-- Main.iturner - 20 Apr 2006 - Sept 2009

Binding a Macintosh Client Through Command Scripting

During testing, it was discovered that it is disadvantageous to "bind" the client to the OpenDirectory - connecting is necessary and sufficient. The Open Directory Master has had the OpenDirectory service settings modified to disable directory binding.

Also during testing, it was discovered that installing our image on a fresh out of the box new iMac resulted in an incorrect time, which causes Active Directory to reject binding! The time was out significantly - over 4 hours, even though the mac image is set to automatically synchronize. Some investigation shows that the time service, as a safeguard, requires manual intervention for large discrepancies - in this case merely authenticating as administrator to the date and time gui. The script has now been adapted to try to do this automatically, by issuing systemsetup commands:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/systemsetup -setusingnetworktime "off"

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/systemsetup -setnetworktimeserver "ntp.student.cs.uwaterloo.ca"

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/systemsetup -setusingnetworktime "on"

Any script performing these binding duties will require the following administrative credentials.

• Local administration (in fact you must run as root, which removes the need to code local credentials on individual commands) on the Macintosh client terminal (cscfadm account by default).
• Domain administration in the Active Directory domain (DOMAIN\Administrator account by default).
• Open Directory administration on the Macintosh server (diradmin account by default).

The commands which perform the clients' binding operations are called dsconfigad, for binding to an Active Directory domain, and dsconfigldap, for connecting to an Open Directory. In both cases local administration credentials must be provided. The dsconfigad command also requires the credentials of a domain administrator account in the Active Directory domain to which the Macintosh client is binding. Similarly, the dsconfigldap command requires the addition of administration credentials of the Open Directory to which the Macintosh client is connecting. Below are basic examples of how the commands are used at a Macintosh command prompt.

• dsconfigad -la admin -lp ***** -u administrator -p ####### -domain fqdn -a computer_name_in_AD
• dsconfigldap -l admin -q ***** -u diradmin -p @@@@@@@ -n LDAP_config_name -c computer_name_in_OD -a full_name_of_OD_server

It is recommended that the client name used when binding to an Active Directory domain be different from the client name used for binding to an Open Directory realm. At this time, I am not certain what the consequences are if this rule is ignored. However, I do not see any problem in following this guideline provided an appropriate naming convention is adopted. The current naming convention is ad_$thishost and od_$thishost
The value of LDAP_config_name in the dsconfigldap command can be any value which is descriptive of the LDAP binding to the Open Directory realm. It will only be used in the labeling of the LDAPv3 service in the Directory Access applet on the Macintosh client.

Additional capabilities for customizing the configuration are provided through the networksetup command provided as part of the Apple Remote Desktop client installation.

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/networksetup

The functions we use: set the computer name in the Sharing panel,

* not used currently because the values are in fact provided by DHCP, they just do not show up in the GUI: set the DNS servers, and set the DNS search domain.

networksetup -setcomputername $thishost

networksetup -setdnsservers "Built-in Ethernet" "129.97.152.10" "129.97.152.100"

networksetup -setsearchdomains "Built-in Ethernet" "uwaterloo.ca"

Some of the above commands require a client name be given for the terminal in question. All CSCF terminals are given a fixed hostname and IP address prior to being placed into service (notwithstanding whether they are DHCP clients). Therefore we can feel free to let the Macintosh terminal ascertain its own hostname at any time and use that information to bind itself to both the AD and the OD. Any UNIX based terminal can obtain its own hostname locally using the following command.

hostname | awk -F. '{print $1}'

Or, failing that, over the network using the following command.

dig -t PTR -x Terminal_IP_Address | grep PTR | grep -v ^';' | awk '{print $5}' | awk -F. '{print $1}'

Even simpler for the Mac, using TCSH as the shell: set thishost = `hostname -s`

Binding the Macintosh terminal to an Active Directory domain and connecting it to an Open Directory realm is only the first step. Both bindings must be added to the client terminal's authentication list, and the Active Directory to the Contacts list. This must be done in a specific order: Active Directory entry first, Open Directory (LDAPv3) entry second. The dscl command is used for this purpose. You will need the terminals' local administration credentials again (unless running as root). An oddity found while debugging is that the first dscl command will fail with a spurious error, following ones will be successful. The workaround chosen is to put a throwaway "read" command at the head of the chain.

1. dscl /Search -read
2. dscl /Search -create / SearchPolicy CSPSearchPath
3. dscl -u admin -P ***** /Search -append / CSPSearchPath "/Active Directory/fqdn"
4. dscl -u admin -P ***** /Search -append / CSPSearchPath "/LDAPv3/full_name_of_OD_server"
5. dscl /Search/Contacts -create / SearchPolicy CSPSearchPath
6. dscl /Search/Contacts -append / CSPSearchPath "/LDAPv3/full_name_of_OD_server"

In addition, to "turn on" the tick-box, and actually activate the Active Directory plugin you require (still as root):

defaults write /Library/Preferences/DirectoryService/DirectoryService "Active Directory" "Active"

plutil -convert xml1 /Library/Preferences/DirectoryService/DirectoryService.plist and

# Restart DirectoryService (necessary to reload AD plugin activation settings)

killall DirectoryService

There have been some issues with some of the functions, so adaptations from Mike Bombich, ie direct modification of underlying plists, has been effective. http://www.bombich.com/mactips/scripts.html - see the script pointed by ad-bind-login.sh (Leopard)

Our Specific implementation

• the scripts are stored on the primary OD controller
• there is a version specific to each OSX version (separate directory)
• the production versions are under Groups * do NOT expose them; read is restricted to administrators
• development versions are in the administrator's home directory, and are RCS'd
• test versions might also be found separately within Domain Scripts; prior to production
• the ARD procedure is to securely copy iMacScript1 within the local client administrators file space; then securely run the unix script (which also obviously cleans up after itself, for security reasons.

1. cd /Users/cscfadm/Documents
2. tcsh -x iMacScript1
3. rm iMacScript1
4. echo "Done remote run of iMacScript1"

There is also an iMacScript2, stored in the "SL" for Snow Leopard file tree; for machines that refuse any user login, where a "broken" Kerberos is the cause, and manual unbinding is also known to not work; then iMacScript2 can be copied to the client, and remotely run, as above. That will force an unbind. Then the correct version of iMacScript1 must be run to rebind.

Obsolete - not applicable after OSX 10.4

As a supplementary note, there may be issues with a workstation if you remove it from the Open Directory domain. A symptom is the login screen settings may persist; there might also be trouble with Remote Desktop. To clear the holdovers:

1. Start Netinfo Manager as the local admin, for the local machine
2. Under /Config, there is a field mcx_cache; clear it
3. Under /mcx_cache, there are fields: computer_lists, computers, and groups; clear each of them
4. Log out