Mac OS 10.7.5 & Active Directory login issue fixed by unjoin/rejoin to domain

[david_yenzer]

We seem to have a recurring issue with a variety of iMacs and MBPs whereby users are no longer able to login to the machine. At one point in the past when a number of machines were hit with this issue, a simple reboot seemed to resolve the issue across the board. However, since 10.7.5 was released there still seems to be the same issues occurring sporadically. Our fix lately has been to touch the machine, unjoin from the domain and rejoin to the domain (which requires adding back in the piece for Admin users).

All the machines are imaged with an Active Directory binding (on 10.7.4), but we noticed that a computer object doesn't exist in Active Directory until after we've unjoined/rejoined.

Has anyone else experienced this login issue or have any suggestions? Much appreciated.

[wolfymik]

Just wanted to respond saying we have about 75 macs we support on our campus and are seeing the same issue in 10.7.5 and would love to get feedback from anyone with a possible solution.

[nessts]

what are you setting -passinterval to? try 0 -passinterval days how often to change computer trust account password in days
dsconfigad -passinterval 0

[david_yenzer]

We have noticed that we are able to manually unbind/rebind to our domain, and that process does both rebind the machine to AD and create an object in Active Directory.

However, on machines that we have not manually touched (which we don't want to touch, we want to use JAMF), we have used the unbind/rebind script but it fails out with the following error:

/usr/sbin/jamf is version 8.52
Executing Policy Unbind and rebind AD - TEST...
Mounting afp://ourserver.domain/CasperShare to /Volumes/CasperShare...
Running Script unbindAD.sh...
Script Exit Code:1
Script Result: Unbinding the computer from Active Directory...
dsconfigad: Connection failed to the directory server. (2100)
Restarting Directory Services...
No matching processes were found
Binding BPSS-0000 to [ourdomain]...
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 1)
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 2)
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 3)
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 4)
An error occurred binding to Active Directory: dsconfigad: This computer is already 'bound' to Active Directory. You must 'unbind' with '-remove' first. (Attempt 5)
Error: Giving up on Active Directory binding after 5 attempts.
Unmounting file server...
Running Recon...
Searching Additional Path: /Users/
Gathering Application Usage Information...
Finding Extension Attributes...

We are trying to run software updates to get the machine on 10.7.5 (from 10.7.4) because there was an AD fix in that udpate, but so far it's not cooperating. (1) Any ideas on what we can do; or (2) if we can alter the unbind script to force it out of the domain anyway; or (3) if we can force it to overwrite the existing bind (and rebind correctly)?

[david_yenzer]

Further investigation:
I just reimaged a machine and noticed another piece of the puzzle that may not fix it but may be the source of the issue.

Sys Pref > Users & Groups > Login Options > Edit the directory > Open Directory Utility... > Edit Active Directory >

The "Computer ID:" field shows on the imaged machine as the name of the master image "BPS_masterimage". The machine itself is named appropriately - why would the Active Directory field not have carried down so that when it bound to AD it had a unique name?

[wolfymik]

David,

Do you use deepfreeze on MAC. We do and i took nssts' advice and thawed the systems and set the passinterval to 0. So far so good. In our case what was happening is that the workstation object password was being changed while the system was frozen. After reboot the system password was set back to the old one and AD no longer knows anything about it.

[david_yenzer · Accepted solution]

We do not have deepfreeze. However, I did revisit this issue today, figured out how to unbind a machine manually through Terminal, and then translated that into altering the unbind.sh script. So far it's working beautifully on a few test machines - I'll update after I've rolled it out and seen if it works on a bigger target audience.

[david_yenzer]

I've rolled this out to all our district machines, executing on district IPs. Off network it won't rebind, obviously, since it can't contact the DC (but for some reason it still allowed removal from domain without contacting DC). Whatever, it works and no side effects that I can tell.

[mapurcel]

David we are seeing the same issue in our environment with machines failing to unbind:

Script result: Unbinding the computer from Active Directory... dsconfigad: Connection failed to the directory server. (2100) Restarting Directory Services... No matching processes were found

How did you modify the unbind.sh script to deal with this issue? thanks.

[david_yenzer]

I'll revisit this script when I get a chance and let you know. Sorry, I didn't do it today, so I clearly have forgotten everything I did! :)

[david_yenzer]

Okay, give this a shot when you get a chance.

I started with the unbindAD.sh script provided on JAMF that can be located here:
https://jamfnation.jamfsoftware.com/viewProductFile.html?id=135&fid=438

The rest of the script is the same, just look at these two specific items and make updates:

(1) In the first username/password field, I created a new AD user that can authenticate/remove a user from AD. Just plug that in with its password between the parans. I didn't want to use an existing admin password or my personal user, so I basically just made a user specifically for this purpose, but that's your decision.

# HARDCODED VALUES ARE SET HERE
username=""
password=""

(2) This is the only real change I made to the script that I figured out while playing with Terminal and manually unbinding it that way. I added the -f and the original script looks like it starts with the $username and $password but doesn't actually enter them after that. Or something like that. Anyway, this was not the same user as the one in step #1 that has access to AD - this user is our local administrator account on the machines. So basically it looks like during the process you're prompting the machine to unjoin/rejoin AD but it also needs to be authenticated by the local administrator to allow those changes. Just change the "administrator" and "enterAdministratorPASSWORDhere" as appropriate.

echo "Unbinding the computer from Active Directory..."
/usr/sbin/dsconfigad -f -r -u "$username" -p "$password" -lu "administrator" -lp "enterAdministratorPASSWORDhere"

[rtrouton]

You can force an unbind with a bogus username and password (in the event you don't want to put your actual username and password in the script.)

I have a post on how to do this available here:

http://derflounder.wordpress.com/2013/10/09/force-unbinding-with-dsconfigad-without-using-an-active-...

I've also written a script and payload-free package to handle this. Both are available here on my GitHub repo:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/force_unbind_from_active_d...

[david_yenzer]

Note that the script and changes I mentioned should actually rejoin the machine to AD also. This was a way for me to both fix a general "drop from AD" that hit our machines as well as fix our issue of the machines all having the same AD object name (possibly related).

[mapurcel]

thank you both, I'll give these a try with the next machine that shows up with a bad AD binding. Much appreciated.

[david_yenzer]

Sorry, I misspoke. This script only does the unbinding. To rebind, I used the same policy, I just simply toggled the button under Accounts to rebind to our Active Dictory and it works as expected and in the correct order - so script runs first to unbind, then it rebinds. Again, all in the same package.