Binding to Active Directory Fails - Authentication Errors

Not sure if this will work for others but, but I repetitively got this on a clean install with 10.5.2 loaded until I clicked on advanced and configured AD under the services applet.

Good luck, and remember, it just works. 😉

J

I wanted to share my fix, because I did not see it listed in this thread. It took me 2 days to find it but I finally got it! This is my first Mac so it has been interesting...

My issues was in the creation of the AD object. When you go to add a new computer, there is a box that says "The following user or group can join this computer to the domain". Make sure that you enter a group that your account is a member of, that also has rights to Add/Remove/Change computers in the domain. It defaults to Domain Admins on my AD, but I am not a member of that group so it would not let me bind. Once I changed that, it worked fine.

I hope this can help some people.

We ve got nearly 100 iMacs need to bind AD domain to enable windows user to logon. I had the same problem before, tried all sorts things didnt really work.
Later i found that if you ignore the "Invalid Username/Password" message,and keep trying to bind, it will work! Few occasions I tried over ten times to be able to bind , average about 3-5 times.
My environment is Mac OS X 10.5.1 and Windows 2K3 server AD.

One thing need to mention is that *time synchronization* is really important when binding to AD. So make sure the time between AD server and Mac client is the same! Suggestion: Set the Mac client's time server same as the Windows AD server's time server.

Later on we are migrate from windows 2k3 to windows 2k8,, AD binding from Mac is much more stable. OD, AD integration works good as well.

I point anyone who tries to integrate a Mac into a Windows Domain then you should have the web site MacWindows.com bookmarked. The site is filled with IT people trying to put Macs into Windows domain reports. They have been doing nothing but this for years.

After applying many of the fixes stated here and elsewhere this is what worked for me:
1. Rename /Library/Preferences/edu.mit.kerberos and the contents of /Library/Preferences/DirectoryService/ and restart.
2. Remove the computer object from AD.
3. Re-bind to AD setting the following options in Directory Utility
Allow authentication from any domain in forest
Setting preferred server to the domain controller that responds to a ping of the fqdn of your domain e.g. "domain.com"
The key part of this is to run this command via terminal:

*dsconfigad -lu localadmin -lp localadminpwd advoptions -packetsign require*
*dsconfigad -lu localadmin -lp localadminpwd advoptions -packetencrypt require*

if you run a dsconfigad -show in terminal you should see something similar to this:

You are bound to Active Directory:
*Active Directory Forest = yourdomain.com*
*Active Directory Domain = yourdomain.com*
*Computer Account = yourmacname*

Advanced Options - User Experience
Create mobile account at login = Disabled
Require confirmation = Enabled
Force home to startup disk = Disabled
Use Windows UNC path for home = Enabled
Network protocol to be used = smb:
Default user Shell = /bin/bash

Advanced Options - Mappings
Mapping UID to attribute = not set
Mapping user GID to attribute = not set
Mapping group GID to attribute = not set

Advanced Options - Administrative
*Preferred Domain controller = +IP addr of DC+*
*Allowed admin groups = yourdomain \domain admins, yourdomain \enterprise admins*
*Authentication from any domain = Enabled*
*Packet signing = require*
*Packet encryption = require*

Advanced Options - Static maps
None

You might have to follow that up with a restart.

I'm going to start this post as sbit did above me, "After applying many of the fixes stated here and elsewhere this is what worked for me."

I had a few Macs on a small, isolated network that worked fine while bound to AD as 10.4.x systems. I successfully upgraded one to 10.5.2 and watched. After 2 weeks of normal use by our staff with no significant problems, I upgraded the 2nd, then the 3rd a week after that. Everything was fine for another 2 weeks or so after that until one lost the ability to authenticate to AD.

This symptom was a major reason for upgrading to Leopard for me. As Tiger systems, I would have to walk around each morning and click several times on each login window to see if the colored gumdrop for "Network Accounts Available " was either red or green. While running Tiger, if the gumdrop was red, the fix was easy enough. Log in, fire up Directory Utility, unbind, and rebind. Tedious and unnecessary, but at least it worked.

When the first Leopard system lost the ability to authenticate, I tried the same Directory Service resolution. No luck. I was greeted by an error stating "Invalid user name and password combination," and was presented with the option to "Force Unbind." I chose the force unbind. From then on, I was no longer able to bind the system to AD again.

I tried all the common troubleshooting methods outlined here and elsewhere:

• check the time
• made sure forward and reverse DNS was clean for client and server
• verified DNS responded with correct LDAP/AD information with the cool "dig -t SRV ldap.tcp.domain.com" command
• removed the edu.mit.Kerberos file and DirectoryService directory in /Library/Preferences and rebooted
• tried deleting the machine account in AD
• tried manually adding the machine account in AD
• checked and unchecked the "Allow authentication from any domain in the forest" option
• I specified one particular domain controller
• I tried using the dsconfigad tool to bind from the command line
• I parsed through gobs of data from the "sudo killall -USR1 DirectoryService" command in /Library/Logs/DirectoryService/DirectoryService.debug.log
• If I tried the Services Tab in Directory Utility, I received an error "Invalid user name and password combination"
• If I tried using the "+" sign in the Directory Servers Tab of Directory Utility, I received the "eDSPermissionError -14120 Unable to add the domain" error
• another related symptom- if I tried to get a Kerberos ticket through the GUI or kinit, I was given the entertaining, but not helpful error message "KDC reply did not match expectations."

I'm sure there was more that I tried, but I was nearly at wit's end when I asked a more Linux-savvy colleague to take a look. We attacked it from a Linux perspective and had success! Here's what fixed it for us.

We reviewed the man page for krb5.conf and the Files section at the end states:

Changes made in the Kerberos application are saved to >~/Library/Preferences/edu.mit.Kerberos.KerberosApp.plist,
and take precedence over the Kerberos configuration files. The order of precedence (with highest precedence first)
of the Kerberos configuration files is as as follows:

~/Library/Preferences/edu.mit.Kerberos
/Library/Preferences/edu.mit.Kerberos
/etc/krb5.conf

We copied a krb5.conf file from a working SuSE EL 10.2 system to /etc on the Mac and attempted to bind using the following:

dsconfigad -a ThisComputer -u "adminname" -ou "CN=Computers,DC=INITECH,DC=ORG" -domain initech.org

At this point, I was also able to manually request a kerberos ticket with kinit, although I suspect I probably could have done so at any time after the kerb5.conf file was in place. We were prompted for our domain password (which was FINALLY accepted), asked if we wanted to join the existing account, and all was well.

Well sorta.

We tried an id command on a network user who had not previously logged onto the Mac (so it wouldn't use cached credentials) and was told there was no such user. So I had to log on locally to the Mac, open Directory Utility, and add the domain to the authentication search path. I'm sure there was a way to do this from the command line, but at that point I was ready, even eager just to get it done.

OK- so you've made it this far, and I haven't even posted the working krb5.conf file. I hear your concerns, and here it is. I'm sure your see the parts that need to be tailored to your specific site:

[libdefaults]
default_realm = INITECH.ORG
clockskew = 300
[domain_realm]
.initech.org = INITECH.ORG
[realms]
INITECH.ORG = {
kdc = 172.16.0.50:88
default_domain = INITECH.ORG:749
kpasswd_server = 172.16.0.50:88
admin_server = 172.16.0.50:88
}
[appdefaults]
pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
debug = false
retain afterclose = false
minimum_uid = 0
try firstpass = true
}

I hope this helps someone else out there.

the posting above is the only one that began to help me with my problems.

in our case edu.mit.Kerberos had information in it that showed all requests were being proxied by our Apple X Server. After altering the file to directly contact an AD Domain Controller binding was possible.

I have 2 domains at my university. ec-admin.easternct.edu and ec-resnet.easternct.edu. Active Directory works fine on EC-Admin.

But on ec-resnet. I get error -14090 (eDSAuthFailed) error.

Help would be appreciated

Hi,

We had a similar problem at our university. Basically one computer suddenly stopped authenticating network users against active directory. Unbinding and attempting to re bind brought up the authentication errors others in this thread are experiencing. After much reading and some trial and error ... here was our solution (system was 10.5.5):

1. Delete the /Library/Preferences/edu.mit.Kerberos file.

2. Use the /System/Library/CoreServices/Kerberos tool:
- on the edit menu choose "Edit Realms"
- click the "+" and add your domain (all caps seems to work the best)
- click the "Servers" tab and add the AD server you want to authenticate against three times ... kdc, kpasswd, and admin (use the combo box)
- click the "Domains" tab and add your domain in all caps again
- click ok
- click "New" to get a new ticket and use a regular domain account and if all is well you should be granted a ticket.

3. The info set in step 2 will now be in a newly created /Library/Preferences/edu.mit.Kerberos file. Take a look at it in the terminal if you want.

4. Attempt to bind to your domain using directory services ... it will tell you that OS X needs to control the edu.mit.Kerberos file and will force you to "replace" it (but will create a copy called "edu.mit.Kerberos.pre Active Directory" in the same location. Go ahead and replace.

5. You'll probably get the same authentication error now. Go and take a look at the newly modified edu.mit.Kerberos file and you will see lots of items missing. Copy everything from your old kerberos file (the pre Active Directory one) and paste it in to the new edu.mit.kerberos file after the two commented lines (deleting everything else in that file first). Save and exit.

6. Try to bind once more and this time it should bind ... but you are not done yet. Once again the OS has replaced your hard work so go back and edit the new edu.mit.Kerberos file. There will now be 4 commented lines at the top ... delete lines 3 & 4 to tell kerberos that you are intentionally messing with this file. Then copy and paste the "[domain_realm]" and the "[realms]" portion from your pre active directory file into the new edu.mit.Kerberos file. Save and exit.

7. logout or restart and then try logging in a domain user ... hopefully it works now.

Essentially the key seems to be providing a direct reference to a kerberos (AD) server.

Why would this work? I'm still trying to figure it out but it seems that in some cases the OS X machine cannot choose or find a kerberos server (even if you specify one in the AD dialog). This is demonstrated by after attempting to bind in step 4 above if you go back to the kerberos tool and request a ticket it will give you a kdc server error. Possibly this is an issue with DNS ... in our case it happened on 1 out of the 60 macs we operate which makes it even more bizarre. The only thing different about this machine was that we added all the extras (ilife, garageband, etc) post imaging. Other than that it is the same as the others in that lab.

In large organizations this may not work as you may not want all your macs authenticating to a single AD server. I did not test the possability of just using the fully qualified domain name as the kdc/kpasswd/admin server. This might work as DNS is capable of resolving that to the ip's of the AD servers. As our machine was up and running I was hesitant to bring it down again to test this 🙂.

Hope this helps someone!

I got the same error of "invalid user name password combination". I have a Golden Triangle arrangement where my machine is bound to both OD and AD. I was bound to OD before attempting to bind to AD. Removing the computer account from OD and then binding for AD worked with no problem. I was then able to add the computer account to OD for MCX settings.

I was having trouble logging in with my AD account to some iMacs added to our AD. In fact, not a single AD account was able to login. Directory Utility claimed it can't see the domain controller (which it could, since it was online, in the same subnet as other identical computers, it could ping the domain and packets were sent back and forth between it and the domain, without loss). Unbinding it didn't work, but it offered to force the ubind, which I did. Then I was unable to bind it back (updated to 10.5.6 rebooted, still not binding). The error I kept getting was invalid username and password (after entering the domain username and password that we use for binding). Using the same username and password worked on other computers (either brand new, or existing computers that I unbound, then bound back with no issues -- again same subnet, same image). I deleted the computer accounts from the domain, but the problem persisted. Finally, I used fseventer to see what's being access during the bind process. The system threw the error message not after communicating with the domain, but after checking the plists in /Library/Preferences/DirectoryService and /var/db/dslocal/nodes/Default/config -- so I deleted these two folders and was able to bind back with no issues! WARNING: *This deletes a lot of directory service settings, so use it at your own risk!* Here are the commands I used:
<pre>
sudo rm -rdfv /Library/Preferences/DirectoryService
sudo rm -rdfv /var/db/dslocal/nodes/Default/config
sudo sudo killall -USR1 DirectoryService
</pre>

Message was edited by: PetarM

PetarM... you are the MAN!

This fixed the exact same problem for me I was having on one Mac that wouldn't re-bind. Thanks!!

Now, if only I could figure out why random Macs un-bind themselves from AD. This issue is really driving me crazy. Things will be just fine for a few days or a week or two and then the Mac will not accept any AD users' login until the Mac is un-bound and re-bound to AD. Arghh!

I have this same issue where I have to rebind to Active Directory to get users to login. Although in some cases when the computer is shut down and restarted, the user is able to log in again.

I have a Windows 2003 DC. I believe this has been happening since 10.5.5 since no one in our school was having an issue logging in until about November.

A lot of complex things going on in this topic, but all are missing one important thing:

If you do not have permission to modify an AD object, you cannot modify it!

If you were not the one who's account originally bound the Mac to AD in the first place, you won't be able to rebind it. You will get errors.

If you are the domain admin, check your ACLs on the OU you're putting your Macs in.

If you are not, and weren't the one who originally bound the Mac, have your domain admin remove the Mac from AD first, then you should rebind fine.

Hi Joe, the problem for us now is that Macs randomly "un-bind" themselves from AD. This is a major pain as it creates a lot of extra work we don't need. I know this is straying from topic but have you any idea what would cause this?

Thanks