Binding to Active Directory Fails - Authentication Errors

EPtesting wrote:
2. Downloaded update to 10.5.1 while logged in as the local administrator (DO NOT ATTEMPT TO BIND TO ACTIVE DIRECTORY!)

Heh, yah, I'll try that. I've tried everything else. From a Workgroup Config, changed to Advanced, reinstalled as Standard. All -14090 eDSAuthFailed.... but I forgot I hadn't upgraded to 10.5.1 before I tried to bind with the last clean install of a Standard config.

Argh, this is too much, I can't believe this isn't working out of the box... but you know they had to hit that Holiday Shopping window, most Digital Lifestylers won't be binding to AD on Xmas morning. sheesh :S

I agree. I've tried reverting it to a "clean" state but neither that nor a clean install of the OS resolves the issue reliably for me. Once a machine does bind it seems to work fine (we have two that bound with no problems at all).

As far as clearing files out I believe they are the following:

/Library/Preferences/edu.mit.kerberos
/Library/Preferences/DirectoryServices/*

I can confirm that this works. I've been on the phone to Apple tech and they suggested this fix for those admins facing the annoying -14090 eDSauthFailed:

Move all files in : /Library/Preferences/DirectoryServices/ to a temp directory, and reboot.

You should find that you can rebind fine. I guess Leopard just gets its knickers in a twist when you start unbinding from a domain...

I'll try it again... but it didn't work for my testing previously through deletion and rebooting or on a clean install.

simon_kun wrote:
I can confirm that this works. I've been on the phone to Apple tech and they suggested this fix for those admins facing the annoying -14090 eDSauthFailed:

Move all files in : /Library/Preferences/DirectoryServices/ to a temp directory, and reboot.

You should find that you can rebind fine. I guess Leopard just gets its knickers in a twist when you start unbinding from a domain...

I found that if you do that, your own Server won't be found in Directory Utility after reboot. And while I was able to bind to AD (using the full FQDN in lowercase) that it wouldn't show in Directory Utility until I did it twice. Then dscl would not return any results for the domain... and DirectoryService would crash at least once a minute (kinda like the beta) due to segmentation faults... I have all sorts of logs, but really, why am I beta testing a shipping product? I don't even know how to concisely tell them how this thing is messing up in bugreporter because it finds new and unique ways to crash and mess up each time I try (yes, clean intalls to minimize this kind of randomness) grrr

Joel Bruner1 wrote:
...why am I beta testing a shipping product?

Would have to agree with you on this one Joel...

I've retested clearing the DirectoryService directory and rebooting and it continues to fail.

I also tried, at the suggestion of an Apple SE I ran into at a tech update on friday, I removed the machine's old record from AD, and with cleared settings tried to bind again. Once again no dice.

This might be obvious and something you've already tried, but it tripped us up at work here until someone noticed it.

In Directory Utility in Leopard (Tiger as well, but you see it right away) you need to pick Services under Advanced Settings and check the box to actually enable AD authentication.

Leopard rearranged the applet and tabs, and it will let you try to add a server and authenticate against the AD domain without the service enabled, but it won't work and the error messages can lead you down the wrong path.

Hope this helps,
Steve

On the machines where the issue is occuring we arent able to even get bound to the domain, so attempting to log in isnt even an option yet...

Having same issue, found this support from apple, http://docs.info.apple.com/article.html?artnum=306750

DID NOT work for me, however, just see if any of u want to have a go as well.

XX

This wouldnt really help the issue here, as this is more an problem on the server end with SSO (though I did run into this as well).

I can't offer much help, but I'm having this same problem as well. I have a bunch of scripts that run when a machine is cloned that bind to OD/AD and they work fine on 10.4. On 10.5, the AD script isn't working.

When trying to manually bind, I'm getting the same errors everyone else is getting. The solutions offered in this thread didn't help here.

One thing that does seem to work is adding the computer in AD first and setting the "prefer this domain server" option in the AD settings to the IP of the server where I created the computer. Then it will bind alright. After that, it wouldn't login right away. I left it sitting for a little while and then it started logging in.

But yeah, I really don't have time for this.

POSSIBLE SOLUTION!

At least in our case I discovered a (PITA) work-around. When migrating both our Xserves to 10.5 (needed to swap drives around so it was a clean format) I unbound one from AD but forgot the other. Well upon finishing the installs I went to bind the machine that I'd unbound and started to get nervous when it failed. Once the other finished I figure "why not..." and tried binding the other server I forgot to unbind. It bound flawlessly and asked to be joined to the account.

So apparently in at least our case its an issue of the AD plug-in not being able to create new accounts in AD. I verified this using a 10.4 laptop I had sitting around via the following steps which could be used to get a few problem machines bound:

1) bind 10.4 machine as the name you'd like the 10.5 machine bound as.
2) bind 10.5 machine as that name once the 10.4 is successfully bound.
3) on the 10.4 machine delete the files in /Library/Preferences/DirectoryService and delete /Library/Preferences/edu.mit.Kerberos

This really wont work well on a large scale unless you have a LOT of time on your hands but it seems to work anyway. Let me know if this is successful for any of you.

I was doing some more research on this and found a few posts on macwindows.com about this problem. It seems that when binding, the computer looks and random server during different parts of the binding process. So It'll make your computer on one domain controller and then look for it on another DC where it won't be until the DCs replicate and error out.

So if you have one DC then you won't have a problem, but the more you have the more likely it will be to fail.

On macwindows.com they suggest editing /etc/hosts to point all DCs to one IP address. I tried this and for whatever reason, the hosts file stops working during the binding process and all the DCs revert back to their real IP until I restart the computer.

Hmm I'll have to test some things here to see if thats our problem. We do indeed have many DCs, though if this were the case wouldn't it work the second time you tried after the computer had been propagated to the other DCs? Subsequent tries on our network have still failed with rare sporadic exceptions.