Automation of AD binding

lwindram
Contributor

In our environment, we have had two significant and persistent issues. Our primary devices are MacBook airs, and we image them using external drives. The image has consisted of an 1.) an OS and 2.) a package which installs a firstRun script and it's associated launchDaemon. The script takes care of wireless authentication, local admin account creation, binding to AD, and enrollment in Casper. The wireless and the local accounts always deploy successfully, but the bind and the enrollment have been less consistent. The bind occasionally fails at imaging but devices also can become unbound while in use.

I implemented Rich Trouton's caspercheck script (http://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/) last week, with positive results. I am now including this script/LaunchDaemon as a package at imaging time.

I decided to use his process (and a lot of his code) to tackle our AD binding issue as well. The process is the same, but is sped up slightly to ensure consistent binding. The script is called at boot and every four hours afterwards. It verifies that the device is on the network, forces a check-in with the timeserver, then verifies the bind using a lookup. If successful, it exits; if not, it binds the computer. This is now also being deployed as a package at imaging time.

Having these self-healing components inherent in the image means that the imaging process is no longer even dependent on the network being available. We have been dealing with these two issues for a few years, and it was a near-religious experience to watch a device both enroll and bind itself.

The binding script and the launch agent are here: https://github.com/LWindram/adBind

Note: the credentials for the AD account are stored in the script. When I build the deployment package, I set the permissions to 750 for the script, which is enough to prevent our users from viewing them.

5 REPLIES 5

mojo21221
Contributor II

The only thing I would check is the making sure the Time Server, Computer Names were changed prior. Also, make sure the time is correct. Here is what our Time script looks like. I think I borrowed it, so thanks to the nameless...

#!/bin/sh

# Use "/usr/sbin/systemsetup -listtimezones" to see a list of available list time zones.
TimeZone="America/New_York"
TimeServer1="YOURTIMESERVER.COM"
TimeServer2="time.apple.com"

############# Pause for network services #############
/bin/sleep 10
#################################################

/usr/sbin/systemsetup -setusingnetworktime off

#Set an initial time zone
/usr/sbin/systemsetup -settimezone $TimeZone

#Set specific time servers
/usr/sbin/systemsetup -setnetworktimeserver $TimeServer1
echo "server $TimeServer2" >> /etc/ntp.conf

# enable location services
/bin/launchctl unload /System/Library/LaunchDaemons/com.apple.locationd.plist
uuid=/usr/sbin/system_profiler SPHardwareDataType | grep "Hardware UUID" | cut -c22-57
/usr/bin/defaults write /var/db/locationd/Library/Preferences/ByHost/com.apple.locationd.$uuid LocationServicesEnabled -int 1
/usr/sbin/chown -R _locationd:_locationd /var/db/locationd
/bin/launchctl load /System/Library/LaunchDaemons/com.apple.locationd.plist

# set time zone automatically using current location /usr/bin/defaults write /Library/Preferences/com.apple.timezone.auto Active -bool true

/usr/sbin/systemsetup -setusingnetworktime on

/usr/sbin/systemsetup -gettimezone
/usr/sbin/systemsetup -getnetworktimeserver

exit 0

Look
Valued Contributor III

Put the AD bind script inside Casper and then call it using a policy trigger, makes the credentials just a little bit safer and means they can be changed at anytime globally without having to redeploy. Also means if there is something that needs to be tweaked this can also be done instantly.

lwindram
Contributor

@mojo21221 - I initially set the timeserver in the firstBoot script and then modify it as needed using smart groups. I didn't try to set it here as I want to know if it not already set to what I want it to be.

@Look - I like that idea - I would still deploy the LaunchDaemon, but have it run jam policy -trigger myScript instead of calling the locally stored script.

JAMFOrinda
New Contributor

Hi,
I had an issue that the log file did not really explain:
2015-07-01 14:25:20 AD user lookup failed for user . Proceeding to rebind.
2015-07-01 14:25:35 ======== adBind bound computer ========
But the computer was not bound to AD. I tracked it down to the name being to long.

My solution was that I altered your script at line 103:
compName=$(uname -n|cut -c 1-15)

You may not want to do the same, I don't know, but you might want to change the script so it logs the issue.
Just thought I would let you know. Thank you so much for sharing your work.

JAMFOrinda
New Contributor

I made some more changes to get this working for us. I thought I would fork your original so that others can see what I did. You can find it here:
https://github.com/memoryerror/adBind/tree/patch-1