Kerberos AD sync

[MikaelDez]

I’ve been running Kerberos for the past 6 months with little to no hiccups. Of course, my boss experiences an issue that I haven’t been able to replicate on anything other than his machine. When he signs in to Kerberos, he gets the AD sync window, like I’ve seen on every machine. He syncs the password, and then without fail as soon as he loses an internet connection or reboots his machine and then signs back into WiFi, he gets the sync window again. I have him set to sign in to Kerberos automatically - but ideally here it shouldn’t recognize any sort of disparity between his local and AD password.

I’m thinking that this could potentially be a keychain problem? Has anyone else experienced this? 

[ljcacioppo]

Typically, kerberos is looking at the password last set date for the user and determining if that matches active directory. Ive seen when de-mobilizing a user, that the password last set date is not set. - So we have resolved that issue by changing the password (or just going to change password and typing their current password in the current, new password, and new password verify fields)

[MikaelDez]

I'll check that out tomorrow, thanks! He has reset his password using kerberos at least once so I imagine it would have done that already. His Mac is the only known device with this issue. We de-mobilized his account when I pushed the configuration and I think that may the culprit, but it's inconsistent. Other users that I have demobilized are not experiencing the problem.

[ljcacioppo]

you can try to run this. If there is no entry, then the passwordLastSet is your issue (replacing the username placeholder of course)

dscl . read /Users/$username | grep -A1 passwordLastSetTime | grep real | awk -F 'real>|</real' '{print $2}' 

[MikaelDez]

Before “bothering” him I wanted to test that on my Mac and I do not get any feedback - and I’m not experiencing the password sync issue that he is. I’m going to try and find time today to investigate.

[ljcacioppo]

hmm, I just checked multiple machines and I get a result as long as I substitute in the username in the filepath in the command.

you could try running this just to see the account policy data and see if there is any password last set entry (again, replacing the username variable)

dscl . read /Users/$username accountPolicyData

[MikaelDez]

Ok I'm an idiot - I don't think I removed the $ before - I get an entry now for my account, and his did not return anything. Having him change his password with Kerberos and I'll let you know if that seems to fix it!