Active Directory/Mac account passwords out of sync

Are your caching the accounts on the Mac systems? Basically, in your AD bind configuration is the "Create mobile account at login" box checked? If so, you may have a stale cached record. Instead of hitting the domain, the system is referencing the cached record on the system. Are you using network homes?

R-

Apple Consultant Network

Apple Professional Services

Auther "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

I have seen cases where after the Mac screensaver has activated the user is unable to unlock it with valid AD credentials. Rebooting and relogging in then works, I have also been told (if enabled) going to the fast user switching screen from the screensaver and then logging in with the same valid user details also works.

Unplugging the network cable, waiting and then trying again to unlock the screensaver sometimes helps as well as then it uses the local cached credential and does not try to talk to the AD server.

Note: The password has not expired and user is entering correctly when this happens.

I get the impression the Kerberos ticket may have expired and is not being renewed sometimes.

With Kerberos as used by both OD and AD it is important that all the computer clocks are closely synced although I don't believe this is the cause of all the above cases.

The fact that the issue is following you to other machines in the mystery and the condition I have not seen. Unless, the same user has accessed both machines in the past. This does not explain how it would track to a freshly imaged device however...

The "stale cached record" is in reference to the .plist file that is created for the user (in /var/db/dslocal/nodes/Default/users) when they cache the account. I've seen many conditions (usually with laptops) where the user will never re-associate with the domain and effectively continue to work off the local cached account record. In some cases, the file needs to be purged from the machine and the user need to log in to create it.

A possible test you can perform is to flush the cached record from the machine, reboot, and then try logging in as the user. A new cache file should be created when you login for the first time.

Hi

Number 6 sounds like a problem I've seen recently in a fairly large AD environment where a handful of users from amongst a thousand or so were affected.

This particular environment had a folder structure that placed users' home folders two levels down from the share itself. There was a policy that gave traverse rights all the way down from the parent share to users' home folders. Above this in the interface was an additional 'stale/out of date' policy that denied access to the parent folders upstream from the users' folder. Once this stale policy was removed and the new policy that allowed traverse rights re-applied/re-propagated the user was able to log in. Even though 'gpupdate /force' is supposed to refresh policies within 15 minutes it took a while (some 4-5 hours) before it finally took.

Maybe the above might go some way in explaining what you saw?

HTH?

Tony

Hello,

I have a few questions to help troubleshoot further. When you are logging in with these accounts and you get a prompt to change your password, what is the exact message you see? It may be that the Keychain is out of sync with the login and it wants the old password to update the login keychain with the new one.

Let me know and we can narrow it down.

Thanks,

Abraham

Question for you Strontium90, I followed your instructions on a test machine, and deleted the user.plist file. Upon logging back in, the computer did not recreate the file, and now I can only login when connected to the network. There is no cached record of the user.

Any advice on how to force the Mac to recreate that .plist file?

Check to see that the account in system preferences is still a mobile account and if not the ctrl click the account and set as a mobile account.

If it is confirm the computer is on the domain.

let us know if this helps

unbinding/binding the machine is causing DNS to hand out a new IP entry

So the issue is that there are multiple DNS entries for the computer hostname.

Go to the active directory server and go check DNS and remove the older entry.

If for some reason your on a windows machine and you ping the hostname in cmdline

then you can get wrong IP address.

Cool way to see this is if you then ping -a 172.168.x.x you can get a completely different Computer hostname given DNS has handed out that IP again.

Typical issue with DNS in a windows environment and your system admin should be able to resolve this no problem.

Also I should say that the reason the credentials weren't working before when you tried to connect was due to the DNS entry of the hostname and by deleting the PLIST you then rebound and were able to recreate the plist because the domain and the machine had a trust again.

Hope this helps. Let me know!

We are having the same issue on our campus.

We are binding our Macs directly to AD, and not using a secondary binding mechanism, such as Centrify. We don't select mobile accounts other than for the users Mac laptops. The issue is with the Mac desktops, and those predominatley in public areas.

The problem is that users who are mainly Windows users, in a 180 password change policy, will be asked to change their password the first time they attempt logon to any bound Mac on campus. Regardless of when they last changed their AD password via their PC at login. If they do change their password at this point, they are then moved to a 42 day policy that exists somewhere, but they can then logon to any Mac on campus without issue. Mean while they still remain in the 180 day Windows policy. Eventually if they go back to any Mac they will be notified that their password will expire in X number of days, or that it has expired

I'm in a 42 day policy, so at some point after changing my password I start seeing a message at login stating that I have X number of days before my password will expire. This message will follow me around campus to any bound Mac I attempt to logon to. However once I've change the password the message goes away.

As a test I went a couple of days without changing my password after I'd received the message telling me that my password has expired. I could still go to a PC and logon without issue.

I am not all that knowledgeable about this, but it appears the Macs are looking at a different set of accounts for the validating of credentials than the PCs are, and these follow the users to the different Macs on campus