Rebind via ADBind

[DBrowning]

Currently my company uses Centrify to bind Macs to our AD. When we go full steam ahead on our Casper Roll-out, part of this is removing Centrify and re-binding via the Apples AD plugin. I have a script that works for unbinding the Centrify side (/usr/sbin/adleave -u Blah -p Blah -r) but how can I in this same script re-add the computer to the domain with Apples built in AD Plug or the AD Binding I have setup in Casper?

Reason for scripting this is so that I don't have to touch about 500 machines.

[mm2270]

man dsconfigad

The dsconfigad binary is what does the Apple AD binding. The man page should have all the details you need to script it, but if you get stuck post back with what you have so far. Many of us here have built custom bind scripts so its a fairly well trod area.

You can also simply call a policy in your unbind script by a custom trigger such as "bind2AD" or whatever you want to call, that's set up in your JSS to run a policy to rebind the Mac. Either way should be OK.

[cbrewer]

If your Macs are enrolled in Casper, you can use the jamf binary. You could also use dsconfigad.

Example:
jamf bind -type ad -domain mydomain.com -username johndoe -password 1234 -ou "OU=Staff Computers,DC=mydomain,DC=com" -cache -multipleDomains

[jhalvorson · Accepted solution]

Your script could be set to call a Custom Event (in the olden days, we called it a Trigger Policy).

The command in your script would be like the following:

/usr/sbin/jamf policy -trigger ADbindviaJAMF

The Custom Event is simply a Policy that has on Ongoing frequency, Custom Event name, and includes a JAMF Directory Binding. "ADbindviaJAMF" is the name of the Policy.

[dpertschi]

@ddcdennisb We've been migrating users from Centrify to native binding for a while now.

You may or may not have come across this yet, but after the unbind-restart-rebind, I've found it necessary to change ownership (a reset really) on the users local home folder before they try to log in again with the new binding. You'll have different UUID's between bindings, and without doing this they won't have permissions for some stuff in their local home.

I use this command: ```
sudo chown –R username:staff /Users/username
```

[dwhitehead]

We're on the home stretch of converting all of our machines.

dpertschi is correct.

Uninstalling Centrify will leave the existing user folder with an invalid UUID for ownership. You'll have to change the ownership back to the proper user after the machine has been successfully bound again (you may be able to mitigate this to some extent by unbinding prior to installing). One other thing to note are the Application permissions. Any apps that were installed by users via a drag + drop installer will have the same ownership issues.

Rough outline of our script structure:
*Check and download dependencies (in this case the most up to date Centrify uninstall script. Some older versions of the script were still present on our machines and wouldn't recognize 10.9.x as a valid OS).
*Check connectivity to desired DC
*Prompt user for current password (we cache the new AD account to prevent issues with users running the rebinding process over vpn)
*Store Application permissions *Remove Centrify
*Bind Machine (We use a JAMF directory binding in a triggered policy)
*Verify the Bind was successful (via dscl)
*Fix the User + Application Permissions
*Cache the users new AD account (Via createmobileaccount with the password we collected earlier)
*Remove the emergency access account
*Notify the user of completion
*Kill the current user session

Another recommendation is to build in a function that creates a local copy of the user's account in the event that it was unable to bind after x tries. This way the user is still able to login and get to all their data.

Good luck!

[DBrowning]

@dpertschi and @dwhitehead

Thanks for your comments. We had users login with network accounts so the UUID's are matching.