How to check for AD binding while in the process of enrolling?

[znilsson]

The problem is: We find some Macs out at one of our properties, we tell them how to self-enroll into Casper, and they get a message that the quickadd package has failed. The reason it failed is because it's trying to bind these Macs to AD but they are already bound, so it attempts to bind 5 times and then fails out.

The rest of the process actually worked, the Mac is enrolled, the polices have taken effect, but on the client side the installer says it failed. And nothing is actually wrong, I mean as long as it's already bound to AD then mission accomplished.

So my question is how can I prevent the installer from failing out if the Mac is already bound to AD? I tried setting up a smart group that checks if the Mac is already bound to AD but then it becomes a chicken or the egg problem - the smart group is only comprised of Macs already enrolled into Casper, and this is an issue AS the enrollment process is happening so it won't see the Mac we're trying to enroll when it checks to see if it's bound to AD or not, because it's not checking on the Mac itself, it's checking against the Casper smart group.

So would the solution be somehow getting the AD policy, or maybe a script, to check to see if the Mac itself is bound to AD before attempting to bind it? Or is the solution more along the lines of suppressing failure warnings? Suppressing it is fine, I don't care as long as it's bound to AD one way or the other. I just don't want the installer to fail out because of it.

[alexjdale]

If the bind is happening as an enrollment policy, you can scope that policy to a smart group of systems that are not bound to AD. The enrollment process performs inventory (including smart group membership) before running enrollment-triggered policies, so there is no "chicken and egg" issue. The chicken is first.

Source: I just did some similar stuff during an M&A using a smart group enrollment policy.

[znilsson]

Thanks for the info. Yeah I have the AD binding set up as a policy that runs at "enrollment complete". I just didn't think the casper database would be updated with the client info by the time the policy would check against smart groups since it all happens so quickly, but if it does then there's no problem and I am making it more complicated than it needs to be, haha.

I'll set up the smart group that only includes non-bound Macs, scope the policy and test it out. Thanks.

[nkalister]

code to check if a mac is bound to AD will depend on the plugin used to bind.
For Centrify, I just check to see if any Centrify files are present on the machine, like /usr/bin/adinfo.
For the Apple plugin, I use dsconfigad first to look for a computer object name:

dsconfigad -show | grep "Computer Account" | awk '{print$4}' | sed 's/\$//g'

If that doesn't return empty, then I do a 2nd check just to be absolutely sure:

dscl . -list /Config | grep -e "Active Directory" -e "AD DS PlugIn"

If that also returns non-empty, then the mac definitely thinks it's bound to AD.

[Look]

The binding process makes a plist file that you can look for along the lines of...
"/Library/Preferences/OpenDirectory/Configurations/Active Directory/DOMAIN.plist"
Check an already bound one for what would replace DOMAIN with.
Also if you having trouble unbinding and rebinding a machine deleting this file sometimes allows this process to proceed.