Previous 1 2 3 4 5 Next 63 Replies Latest reply: Feb 10, 2009 9:18 AM by Erik Black Go to original post
  • OLAUser Level 1 Level 1
    I reinstalled my system from scratch using the 10.5 disks. I then migrated over my applications from backup, but not the users. After binding to the directory, I was able to logon using a network account. I then copied over the user's old folders from the backup.

    So in other words, a clean install worked for me. One thing I've tried in the past was to specify the preferred domain controller, and use the IP, not the name.
  • Joel Bruner1 Level 1 Level 1
    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
  • themonkman Level 1 Level 1
    A clean install should not be necessary. Anything that was generated (eg config files, etc...) from a previous bind should be reversable. It should be possible to put the computer back into the state it was prior to an attempted bind. Does anyone know what files get modified during the binding process? This will be the key to those of us who've already settled into our systems and don't want to start from scratch again.

    Message was edited by: themonkman
  • Nicholas Shaff Level 1 Level 1
    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:

  • simon_kun Level 1 Level 1
    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...
  • Nicholas Shaff Level 1 Level 1
    I'll try it again... but it didn't work for my testing previously through deletion and rebooting or on a clean install.
  • Joel Bruner1 Level 1 Level 1
    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
  • Nicholas Shaff Level 1 Level 1
    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.
  • Axilla Level 1 Level 1
    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,
  • Nicholas Shaff Level 1 Level 1
    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...
  • peacefulbird Level 1 Level 1
    Having same issue, found this support from apple,

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

  • Nicholas Shaff Level 1 Level 1
    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).
  • Jason Bennett Level 1 Level 1
    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.
  • Nicholas Shaff Level 1 Level 1

    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/

    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.
  • Jason Bennett Level 1 Level 1
    I was doing some more research on this and found a few posts on 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 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.