We are using the Kerberos SSO Extension, and every time a user logs in, a Mac centric box appears that says "Kerberos is trying to authenticate user" with an option to put in their password. If they cancel that box, another box appears having them put in my password to connect to the domain. This happens after they originally synced their local and AD passwords and got confirmation that it was successful and after testing, it was successful. The first time they synced their passwords, a box appeared that stated "Would you like to automatically sign in from now on?" and they chose yes, but obviously that's not working. I would rather not have my end users having to log in multiple times (Once to get into the device, and then another to validate password syncing). Thanks in advance for any help.
Kerberos SSO Extension help
+8Best answer by TGarrod
After working with JAMF support, we found a solution. In our configuration profile we had "User Presence to access the keychain" set as required. We instead chose "Skip" for this variable, and ever since, the Kerberos SSO has worked like a charm.
+17Out of curiosity, were these computers ever bound before? There is a known issue where the passwordLastSet time isn't set for accounts that have been converted from mobile accounts to local accounts, and we were seeing the behavior where the users were prompted to sync every day, but either resetting the password through Active Directory and officially syncing it, or going into system preferences and choosing 'Reset Password' and manually setting the password on the Mac to their current AD password resolved the issue for us
+8Out of curiosity, were these computers ever bound before? There is a known issue where the passwordLastSet time isn't set for accounts that have been converted from mobile accounts to local accounts, and we were seeing the behavior where the users were prompted to sync every day, but either resetting the password through Active Directory and officially syncing it, or going into system preferences and choosing 'Reset Password' and manually setting the password on the Mac to their current AD password resolved the issue for us
I will also mention that we are seeing this occur on Mac’s that previously had mobile accounts and were bind to AD. I’ve wiped the Hard Drive and reinstalled the OS and verified they are no longer in AD, but the prompts still appear after each login.
This issue does not occur to Mac’s that are new out of the box that hadn’t been bound to AD or had a mobile account configured.
+17I will also mention that we are seeing this occur on Mac’s that previously had mobile accounts and were bind to AD. I’ve wiped the Hard Drive and reinstalled the OS and verified they are no longer in AD, but the prompts still appear after each login.
This issue does not occur to Mac’s that are new out of the box that hadn’t been bound to AD or had a mobile account configured.
The way Ive always identified the issue is by running the following command:
dscl . read /Users/$username | grep -A1 passwordLastSetTime | grep real | awk -F 'real>|</real' '{print $2}'
If it comes back blank, the password sync is always going to report as wrong, and that's why it prompts every time. We have fixed this issue by telling the user to go into System Preferences -> Users and Groups, choosing reset password and typing their current password in all three boxes, old password, new password and new password verify. Running the same check command confirms if the passwordLastSet entry has been updated
+8The way Ive always identified the issue is by running the following command:
dscl . read /Users/$username | grep -A1 passwordLastSetTime | grep real | awk -F 'real>|</real' '{print $2}'
If it comes back blank, the password sync is always going to report as wrong, and that's why it prompts every time. We have fixed this issue by telling the user to go into System Preferences -> Users and Groups, choosing reset password and typing their current password in all three boxes, old password, new password and new password verify. Running the same check command confirms if the passwordLastSet entry has been updated
Thanks for your reply. I'm new to JAMF and Mac Administration so please bear with me. Is Terminal the correct location to enter the command you provided? When I enter it into Terminal, nothing happens. Thanks for your help!
+17Thanks for your reply. I'm new to JAMF and Mac Administration so please bear with me. Is Terminal the correct location to enter the command you provided? When I enter it into Terminal, nothing happens. Thanks for your help!
Yes, terminal is correct. First, just confirming that you replaced the $username placeholder with the username of the logged in use.
Secondly, if you did and it returns no response, then it has no entry for passwordLastSet, and therefore constant prompts are expected behavior like I detailed above. If that is the case, I would go through the manual password "reset" process I suggested in my previous comment and run the command again to see if that field updated
+8Yes, terminal is correct. First, just confirming that you replaced the $username placeholder with the username of the logged in use.
Secondly, if you did and it returns no response, then it has no entry for passwordLastSet, and therefore constant prompts are expected behavior like I detailed above. If that is the case, I would go through the manual password "reset" process I suggested in my previous comment and run the command again to see if that field updated
Thanks. I ran the command and it came back with 1637616690.630877 so according to what you wrote above, it does have a passwordLastSet entry. I'm still troubleshooting, but it's sporadic when it's happening. For example just as a test, I added my work MacBook to the SSO config profile, which is actively bound to AD, and it worked as expected. I'm having trouble finding a rhyme or reason why this happening sporadically.
+8After working with JAMF support, we found a solution. In our configuration profile we had "User Presence to access the keychain" set as required. We instead chose "Skip" for this variable, and ever since, the Kerberos SSO has worked like a charm.
+1Hey @TGarrod, would you mind sharing the full configuration of the SSO Extension (for Kerberos) as you have it in your JAMF config profile?
I'm struggling to get it working and it's quite strange as in my testing, I did get it working and saw an SMB Share remain mounted for 36 hours, but subsequently, it has stopped working as expected, so I'm really not sure what's going on and could use some help from someone who has it working in their environment.
+4Hello All - hoping someone will reply on this - we're experiencing a similar issue, with the Kerberos extension asking users to log in again and again. Seemingly to verify "user presence" as noted above. We have two concerns by solving this issue by setting presence to "skip" - one, if there is a security concern we are not thinking of, and two, if this will prevent the utility from updating the keychain without the user signing in and / or prevent the users from accessing shares as is mentioned in the last comment. Does anyone know?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.