Re-bind to AD Fail
 

We have a computer that the user could not log in with his AD account once he changed his password. I was also unable to do so with my domain admin account.

He is currently able to log in with his cached password.

I removed the computer from the domain.

I am unable to rebind it to the domain. This usually doesn't happen. I can and have rebound before with other machines.

I get 2 different errors:

1) bad username and password. They are correct
2) error -14008

All have been searched - what I find on apple support is not working, what I have found here so far has not work.

User is on 10.6.4
LDAP is configured correctly.
Time is set to go with our local time server

losing hair. I don't want to have to re-image (which I know will work) to get the user back to our domain.

Domain Admin not recognized - can't bind - some Macs only
 

Ditto here. I just encountered the third Mac in our enterprise with this.
We've seen it on 10.6.3 and 10.6.4. We do create a mobile account at login.

It shakes off the user's AD login, won't authenticate my Admin ID to un-bind, after forced unbind it insists I am giving "Bad username or password" so won't bind. We get them working by just killing the AD auth so they can get to their local account.
Identical Macs down the hall I can unbind and re-bind with no problem.

My gut feeling is something is "bad" in a Kerberos local cache and needs to be flushed out. But I don't know where such things are...

Thanks for the idea and the knowledge that I am not alone in this issue.

The info is a bit OS X outated, but I am going to look through here to see if I can get something not shaking.

http://web.mit.edu/macdev/KfM/Kerber...using-osx.html

I actually found this - ticketviewer.app that may be helpful.

http://discussions.apple.com/thread....ageID=10198249

Will try tomorrow at work and report back.

Tried a couple of things
 

I checked for Kerberos tickets using the "Ticket Viewer" - nothing there to destroy.

I played with uppercase vs. lowercase DOMAIN name - whole forest and just the domain part - I had seen items in two forums about it being case sensitive. But we have always been able to use domain.enterprise.net all lowercase and changing to uppercase did not help anyway.

So, still looking. It goes funky on a Mac that was happily bound up until... it's not.
I will re-image a new machine for this client and quarantine this sick Mac closer to me. So we can perform our cruel experiments on it all day long until it gives up the in-for-ma-tion we require (sinister laugh)!:rolleyes:

Rick

how are you binding to server, via the directory utility, or some sort of script? I have seen bind to AD issues in mailing lists with 10.6.4.

Via the Directory Utility. It works fine for us until the Mac is afflicted with whatever causes this issue. It does not matter whether "Create a Mobile Account" is checked or not.

Originally bound by script.

Both using Directory Utility and again with the script are both not working out for me.

when you unbind does it remove all the entries in the search path and policy path?

I had to manually remove them due to the force unbind, but they are empty.

so if you do something like:

sudo dsconfigldap -f -r myserver.com

then rebind does it work?

will need access to the users computer to run the command. Will report back when I have access.

That command just forces all bindings to be erased. I don't have AD to test it, but that is something I would try.

Tried it via SSH
 

I tried it and then tried binding using dsconfigad... still getting "Unable to obtain rights to change Directory Services." Which sounds like the shell equivalent of what I get in the Directory Utility.

Rick

I have found that unbinding the Mac and then deleting the whole DirectoryService folder from /Library/Preferences followed by a restart and then rebinding the mac with a new name can usually get things working again.

How would that affect a cached credential, if say, this solution does not work?

I'll be quite happy with losing cached anything associated with DirectoryService and starting over.
I figure my clients' startup servers and Preferences are still in their own mobile user folders, so I'm going to try this when I can grab the box.
(If you're feeling really cautious, why not rename the prefs folder instead?)

Thx to kaptagat for the tip, successful or not and I'll report back after the attempt...

Rick

When you say new name, you mean you have to give that computer a totally different name? Sounds to me like when you unbind the computer name isn't getting cleared out of AD.

If you unbind is there still a profile for that machine?

I can tell you're paying attention. However...
 

When you FORCE UNBIND it leaves the object behind and a message tells you as much. That's because you (domain admin) haven't been properly authenticated.
And that lack of credentials authentication is what's causing the issue. What's preventing the auth, well, that's what schwartze and I are trying to solve...;)

Rick

Sorry I don't integrate AD at work, I am pure OD. I also do not do authenticated binds except for a very small number of machines. So, most of my machines use a guest profile.

The only other thing that pops in my head is proper DNS settings, which could affect kerberos, but then again you are directly authenticating with the diradmin account so that should work regardless of kerberos I would think. A bit of google searching suggests that you extend the time out settings for the client to communicate with the server.

http://discussions.apple.com/message...ageID=11919582

It seems to have fixed a few things, I guess there is maybe some overhead came with one of the 10.6 updates which causes the authentication to time out due to it not being able to look up the computer record in time?

I'm going to keep following, but won't be able to test until Friday - that is when I will try the sudo remove, then the timeout. Clearing the whole Directory Services directory is a last resort if I don't know about the cached credentials.

I'd be okay with killing the cached credentials if it didn't mean having to tell the person well above my pay grade who made it abundantly clear that re-imaging his computer was not an option, that if he can't log in cached and can't get on the domain, he'll be losing access for to what him is a very long time.

Tested removing DS Prefs, tested Timeout extension
 

Deleted the Preferences folder for Directory Services, restarted, created a brand new object in AD (Dir Util discovers it and that way I don't have to tweak the default OU structure) and...
Still was told that I was using a name/password combination that was invalid.
I tried binding using a name that was not yet in AD and same result.

Worked the timeout solution, tried 5 seconds and even 10 seconds for mdns_timeout, no change, and it did not seem to take any longer to time out.
Even changed the pdns_timeout and that didn't help either.

I tried authenticating with DOMAIN\MyAdminName (as opposed to just MyAdminName which is usually what works) and it was no better.

schwartze, not sure what you are referring to with 'cached credentials' - if you mean the local home, that was not affected and my client's keychains are intact. I turned off AD authentication and she logs in to her local user home and the servers authenticate her as she invokes them.
But our setup may be different. Here we can't use guest accounts and must show blank name and password fields.

Rick

Hi,
I'd like to know if you ever solved this problem?
I am experiencing the same problems throughout my workplace where sometimes it just won't let me rebind to a network.

I'm also having the issue that some users log on and almost instantly get a message saying 'unable to log you on at the moment'. Sometimes restarting helps, sometimes it needs rebinding. What I don't understand is that if a user uses Mac1, can't log on, moves to Mac2, can't log on. I come up, unbind and rebind Mac2, and the user can use both Mac2 and Mac1. Make any sense?

If you can help, I'd be hugely grateful!
Thanks
LCM Technician

The unable to log you on at the moment can be fixed by editing the auto_master file in the /etc folder.
It is caused by the Mac remembering the last user's credentials for their AD "H" drive so when someone else logs on, the logon fails.
Simply put a # in front of the /Network/Servers line so the file looks like this:-

----------------------------------------------------------------------------
#
# Automounter master map
#
+auto_master # Use directory service
/net -hosts -nobrowse,nosuid
/home auto_home -nobrowse
# /Network/Servers -fstab
/- -static

----------------------------------------------------------------------------

Note, you must restart the Macs to make the change effective.

I just realized I was wrong, dsconfigldap is for OD only, dsconfigad is for AD. You can use it to script unbinds, binds, whatever