10.8.4 - 10.8.5 combo update - Active Directory bind is broken on a few machines even though it still shows good.

[ClassicII]

Hey guys,

We have noticed on some of our 10.8.5 machines that were updated from 10.8.4 that the AD bind is broken.

If you look at all the stats it shows good. For example the casper record shows a good bind and a nice green light in users and groups next to AD. All the info inside the directory utility is good.

The user is unaware of this until they try to utilize something that depends on AD groups.

The only fix is to force unbind and then rebind.

Is any one else seeing this ?

[hodgesji]

We discovered a similar issue a while back and narrowed it down to the macs password interval setting. It was set to check in with the AD server every 14 days. If the mac checked in and the server was unavailable at the time, the mac would still change its password and the server would not. This would mean communication was broken. Fix is unbinding and rebinding, but you can stop it from happening again by changing the password interval settings with terminal:

See the current settings: dsconfigad -show
Change interval: dsconfigad -passinterval 0 (where 0 is the # of days between checking in)

Not sure if you are experiencing the same issue. Also not sure that setting the pass interval to never is the best approach either?

[hodgesji]

Edit: oops on the double-post

[JimAllsop]

How can I confirm it was the password change interval that caused this issue? I'm seeing this in our environment with macs on 10.8.5 and 10.9.2 do you know @hodgesji

[bentoms]

@JimAllsop, there are a few things:

Does the mac still have a computer object in AD?
Is the time correct on the mac?
Does the binding look correct in directory utility?
Does unbinding then rebinding resolve temporarily?

Also, why not test it on a Mac post rebind? Make a note of the date, & if this is happening every 3 days. Check it again after 5.

[JimAllsop]

@bentoms

Does the mac still have a computer object in AD?

yes

Is the time correct on the mac?

Yes

Does the binding look correct in directory utility?

Yes

Does unbinding then rebinding resolve temporarily?

Actually it solves the issue for the user what I would say permanently.

I stumbled on this thread actually for another problem that I thought might be mine. I have had 6 users in the last 3 days not be able to change their password until we did all sorts of crazy stuff. Un-bind and rebind for some of them.

We are an AD shop with windows servers and a ton of macs. They are all mobile, managed, admins. I have directed my staff to have users change their passwords on their computers like this.

Help Desk: Changing users password on a mac is to be done the following way. Turn off Wi-Fi. Connect to LAN via ethernet cable. Open a web browser to confirm IP and connectivity of hardwire connection. Close Outlook and Mail programs. Navigate to System Preferences, Users & Groups, Change Password. Change password. Quit system preferences. Open outlook or mail. (which ever the user uses for email.) Select send and receive if password pop-up did not happen. (this could take 1-4 minutes depending on server activity.) Enter new password in mail or outlook pop-up window. Select “remember password in keychain”. Confirm email works with new password. Restart computer. Have user log into computer with new password for the FINAL confirmation step in the password change process.

We saw the error "The Server is not available. Change your password when the server becomes available." The only way to change the password using the system pref is to unbind and rebind. The other users my team changed the password in OWA, then changed it in the key-chain manually if able. Most of them they had to change it in OWA, delete the key-chain and make a new one.

I was wondering if somehow our macs were unbinding like the OP issue.

[hodgesji]

Here's my method. In terminal, type:

id userName

Where userName is an AD user that has logged in to that machine before. If the command returns any AD groups that this user is in, then the machine can still communicate with the AD server. If all you get is local groups, then it can't.

[ClassicII]

Jim those machines are disconnected. But you have to find out why.

You can use the directory utility to look at the computer record or the active directory keychain item to see when the last time it tried to make contact.

What does the active directory system keychain say as a mod date? or does it have a duplicate entry? When it has a dupe it can not reach or talk to the AD Server.

[JimAllsop]

You can use the directory utility to look at the computer record or the active directory keychain item to see when the last time it tried to make contact.

We took to computers this morning and had a round table meeting with network, systems, and helpdesk and we found out that the last time AD shows a check in for that computer was weeks off and one of the computers was several months since it last checked in with AD.

We are testing a theory that upgrading OS is what broke the AD relationship. We are now testing in our shop to see if upgrading OS breaks the AD bind.

It is a little to much of a coincidence that the last time these computers checked in, is the same time we have a help desk request to upgrade from 10.8.5 to 10.9. But we have not proven this theory.

[ClassicII]

Please let us know what you have found we are getting ready to do the same thing.

At one time we thought that the 10.8.4 - 10.8.5 update did the same thing you are talking about.

Can you check to see if those machines have a dupe keychain item for the ad entry ?

The machines should check in every 14 days to change the computer trust password.

[JimAllsop]

Yeah that is what is funny. The 2 macs that we tested today were my 2 tier 3 techs. And I know for a fact that they have been in the office working! I am the one that made the request telling them to upgrade their machines to 10.9.

I don't remember seeing a dupe in their keychains this morning when we were talking about it.

We noticed this problem simply by trying to change some users passwords. We think this also might be a part of the issues we are having with departments network share drives.

If we have the time we will test on some of our loaners set up with 10.8.5 and then upgrade them to 10.9 and see if it breaks the trust.

[jrserapio]

Hey all,

Did anyone find a root cause to this? Seems to be happening in my Environment JSS 9.3, OSX 10.9.2. Seems to happen when a user resets their password on their PC instead of the Mac, but the tests have not been conclusive enough. Been trying to comb through the logs, but haven't found anything that I can point the finger at.

Thanks.

[mm2270]

I've seen some similar issues here with Macs on 10.9.x, where a Mac in active use will suddenly lose its AD trust. Have seen it occasionally under 10.8.as well but in almost all cases under Mountain Lion and earlier it was because the Mac hadn't been used on a network connection for a few months. As mentioned, the password interval setting will eventually make the computers AD password get out of sync with AD and then communication stops working.

Just also wanted to point out that the dsconfigad -show command is more or less useless for determining whether a Mac has a valid AD bind. The problem is that it looks at the local plist file created at the time of bind, and possibly modified later, but doesn't verify an actual working connection to your domain controllers. If the Mac hasn't been on a network connection to update its computer password and sync to AD, the bind is busted but dsconfigad will still think its all peachy because of that plist file. I found this out a good year and a half ago and built an extensive Extension Attribute which verifies our AD binds. We don't even bother to look at the built in "Active Directory Status" in the JSS anymore, as that uses the same method that dsconfigad -show does.
The only valid way is to perform some kind of lookup against AD, such as making the Mac lookup its own computer record or a user account.

[easyedc]

Apple has indicated to us that this is a known issue in OS X 10.9.x. They did say that if you can run either a

$ dseditgroup -o checkmember -m <username> <groupname>

or a

$ id <username>

and if you get a complete response to the Users membership/account information, that means it should have replicated out enough for logins. During testing, that does not appear to be the case. Apple followed up with additional information saying to try to remove that user from the group upon whose membership his authentication success is predicated. This should disallow access entitlements which are based on membership in the group. At that point do a temporary permissions change that would allow this user to access the share through some other entitlement. Options being:

• Make this affected user the POSIX owner of the share (recursively) and test his login that way. • You could temporarily change the permissions on the share so they were read-write-execute for “Everybody” (which includes this user) and test his login capability in that situation.
• Apple suggested to disable the profile that constrains access to the share. I brought up the fact that I am pushing configuration profile through JAMF with the setting to "allow access to: AD Group" and to try to just simply disable that and see if that worked.

I'm part of the way through these (we have a not-so-fast process to manipulate AD user accounts.

[Olivier]

In case someone wants to check if the current computer password is still the good one (means the one used for that AD computer object), simply go in system keychain, look for "/Active Directory/blahblah" entries, right click, Get Info, Show Password.

Copy the password, and run "kinit yourcomputername@yourdomainfullyqualified" : it will prompt for the password. Paste it and if you get a "kinit: Password incorrect", then the passwords are not synched, and the consequence will be a broken AD trust relationship.
If it is accepted, then you will see the computer Kerberos ticket using "klist".

I don't trust the "nice green light in users and groups next to AD" anymore, simply because it does not show you AD status in a reliable way (it can be green while some nodes displayed with "odutil show nodenames" are offline, giving false sense of proper AD connectivity).

[spraguga]

/url">@Olivier][/url Just incase anyone is still referencing this thread, I wrote a script for this here:
[https://jamfnation.jamfsoftware.com/discussion.html?id=13069

[azbikowski]

I created an extension attribute to validate the Active Directory bind...

#!/bin/bash
# Quick check to verify Active Directory bind is working.
RESULT=`/usr/bin/dscl '/Active Directory/REDBRICKHEALTH/All Domains' read /Groups/Domain Admins distinguishedName`
RESULT=`/bin/echo $RESULT | /usr/bin/sed -e 's/
//'`

if [ "$RESULT" == "dsAttTypeNative:distinguishedName: CN=Domain Admins,CN=Users,DC=redbrickhealth,DC=local"  ]; then
        RESULT="Valid"
else
        RESULT="Error"
fi
echo "<result>$RESULT</result>"
exit 0

Used the AD Validation attribute to put the computers with a failed AD bind into a Smart Computer group, apply policy that forced an unbind and rebound using the JAMF AD Bind configuration. That took care of things for 90% of the Macs. From there we were left with the Macs that were really having a problem joining Active Directory for one reason or another.