Active Directory Won't Authenticate in Mountain Lion

if you domain is abc.def.com
try pinging abc.def.com
i have a large AD environment, and often there are several domain controllers that are down, and the way DNS works is it looks up abc.def.com and the first address it gets is the one it wants to talk to the rest of the life of that DNS record. and if it is not pingable then binding will never succeed. rebooting usually gets me a different one out of the list of 84 possibilities and the AD team gets an email that a server is not up.

Are you able to browse AD and see if the computer names are listed in the OU that you expect them to be?

I am no expert in AD. I suggest searching for the computer names using an AD browser before and after a computer is bound to see what is happening within AD.

In our environment, my JAMF AD Binding settings add Mac's to one specific OU. The work account only has permission to add it to that OU.

Also, when I do binding repeatedly for the same computer, the unbind doesn't always work perfectly from the Mac Directory Utility. I find that I have to use "Active Directory Users and Computers" browser to manually delete the computer from the OU before it can be bound again. I think we have delays that take place between our DC's that increases the fun in troubleshooting.

The computer names are not in the OU... the error I'm getting is that the Username and Password is incorrect. It is obviously correct as I can use the identical username and password (same one stored in the directory binding that I use in the JSS) and it will work on another computer... Sooooo Frustrated

PS - Re-imaging did not work

I am having similar problems even using Thursbys ADmitMac. It's doing my head in as well. At the moment I'm crossing my fingers that Apple will fix it!

check your logs for something that looks like this...
ManagedClient[2884]: ODGetNestedUserGroups nesting level exceeded on group id = 2C0C6872-FF26-49EA-829F-B1D90564DBBA

Any chance your password isn't in sync on all of the Domain Controllers? Have you tried changing the password recently?

Here is what Console says:

Directory Utility[11265]: Cannot remove an observer <ADSv1Panel 0x7fd5eaaa53f0> for the key path "progressStatus" from <ODCBindToADAction 0x7fd5e9ca5aa0> because it is not registered as an observer.

After doing some searching it looks like this is a developer bug... It looks like I'm just going to have to wait for Apple to fix this...

Find out from your AD administrator if all your DCs are the same version and patch level. You might find that one is at a different version and when the request hits that server it fails.

Supported authentication/encryption is different on the older DCs which may explain why you only started seeing the issue with your ML clients.

Try using netstat -a whilst attempting to bind to see which DC you are hitting, or use wireshark to capture whilst binding.

You may also need to check the permissions of the account used to authenticate to the DC when binding. Creating the computer record when binding initially is different to being able to modify/delete.

All DC's are the same version and patch level and the account I'm using is able to authenticate and modify/delete.

Here are my results from netstat -a while binding

Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 localhost.rfb localhost.50588 ESTABLISHED
tcp4 0 0 localhost.50588 localhost.rfb ESTABLISHED
tcp4 0 0 10.24.36.13.ssh 10.1.4.11.52584 ESTABLISHED
tcp4 0 0 10.24.36.13.50585 nk11p01st-courie.https ESTABLISHED
tcp4 0 0 *.kerberos *.* LISTEN tcp6 0 0 *.kerberos *.* LISTEN tcp4 0 0 *.ssh *.* LISTEN

All 4 of my AD servers start with 10.4 and none of them are trying to connect here. They are all, however, pingable.

Jessie,

What Time server are the Macs pointing too? Do you have an internal time sever you can point them too then try?

Also, did you have lion clients that worked?

I don't have an internal time server. I'm using the Apple Time Server. All of my Lion clients were using a custom script. The script doesn't work on my ML clients. Most of my ML clients (127) save these 8 are bound to AD with no problems...

Doesn't sound like it's the issue, but you should be able to use one of the DCs as your NTP server.

Hi Jessie,

So 8 of the 14 iMacs are failing to bind? Yet 127 ML clients are ok??

All but these 8 of my 127 ML clients bound just fine.

Will they bind when manually attempting using directory utility?

Nope, nor will they bind with the "jamf bind" command

hang on, were these the last 8 macs to be imaged/bound?

Not quite the last, but in the last bunch

Can you reset the binding accounts password & retry?

I've even had a new account created and tried it that way and was still not able to Bind

Can you try & rebind a mac that was working before with this new account?

If that fails, I guess it's nw related.

Else, what changed with the failing ones?

Yes, I can unbind a machine that was bound with the old account and rebind it with the new account with no issues. Nothing is different about these machines, they all have identical images, they are all brand new, from the same shipment.

This might seem silly, but it bit me once, so I'm just throwing it out there as something to possibly check. Assuming you have more than one domain.

You might need to make sure that your AD binding is set such that "Allow authentication from any domain in the forest" is not selected. I believe it defaults as selected.

I hadn't realized that one of our test environment domains contained an exact (but very stale) duplicate of our production environment and were in the same forest, resulting in OS X trying to authenticate against whichever one responded the first.

The "Allow authentication from any domain in the forrest" is selected

Macs are the canary in the coal mine when it comes to AD environments.

@tkimpton - I would shy away from using third party plug-ins to bind to AD, the built in plug-in that comes with the OS, works perfectly fine. I would take a look at your DNS/DHCP configurations. Out of personal experience, Thursby's ADmitMac is absolute garbage in terms of functionality when the infrastructure needs attention. Once we got our DNS issues at least somewhat sorted, native binding works beautifully, seeing other machines on the network works beautifully, and so does changing the network password.

Anyway, tangent finished.

@jshipman - I would try hard coding your DNS server configurations into the Network preferences. Network | Advanced | Choose your service (Ethernet) | Advanced | DNS

Put in the IP Address of a suitable primary and secondary DNS server (that is if the DNS servers are not already "picked up" by the Mac), and then put in the FQDN in the field to the right. Check out the proxy settings (probably already done), but be sure that the proxies are on point, and that the time is correct even if it is manually set.

After you hard code the DNS servers in the network preferences, give binding through Directory Utility another shot.