Apple SSO Kerberos Extension

1. I do not believe the password can update on Active Directory just by changing the password on the local Mac. The Kerberos SSO works by checking the password Last Set locally and the password Last Set attribute from Active Directory to see if they match, and if the password has been set on AD more recently than on the Mac, they receive the prompt to sync their password with AD

2. It would not lock the local Mac as the account is a local account on the Mac

3. I am unaware of the ability to force the password change via the kerberos SSO extension. You may want to look at something like Jamf Connect (this would need modern auth, not AD though) or NoMAD Login. With NoMAD Login you can have the computer check the validity of the password on authentication, but that only works if their is line of sight to the domain controller when logging in. If these are laptops off site, that won't really help

4. I don't believe the order should really matter. Personally, I used NoMAD Login to convert mobile accounts to local accounts, and then deployed the Kerberos SSO after and it worked fine (except for the caveat that converted accounts dont seem to set the passwordLastSet attribute when converting, s a manual password change (either to the same password or different) locally on the Mac seemed to resolve that issue though.

5. https://www.apple.com/business/docs/site/Kerberos_Single_Sign_on_Extension_User_Guide.pdf

https://hcsonline.com/support/white-papers/a-guide-for-configuring-the-macos-catalina-kerberos-single-sign-on-extension

We're using almost all local accounts with the Apple SSO Kerberos extension and I can confirm that yes, it's possible to update the AD password using the extension. In fact, that's how I change my password every time and how we've trained our users to do it. There is a Change Password... item that can be configured to appear in the SSO menu that when selected, asks the user to enter their old (existing) password and the new one twice.

The above obviously won't work if someone has forgotten their old password, but as long as you know it and are using local accounts (does not work with AD cached mobile accounts that I'm aware of), then it works just fine.

As far as the Apple extension syncing from both directions, it will detect a change in the AD password when signing into the extension (known as UPC - Unannounced Password Change) and prompt the user to enter their AD domain password and the password for their Mac. Since LDAP is considered the authority in this situation, the extension will update the Mac local account password to match the AD one. This also updates FileVault, which is one nice advantage of using this.

I know I've said it a few times already here, but the important thing to remember is Apple Kerberos SSO extension is really designed around local Mac accounts, not cached AD mobile ones, so if you plan on moving to it and want to take full advantage of it's features, you may need to convert any AD accounts to local ones.

This is all great information regarding Kerberos SSO - thank you! I am testing it in anticipation of moving away from Enterprise Connect. Do you know what the trigger is for the extension to prompt for syncing after changing the AD password? I've changed the password for AD, but I haven't gotten a prompt on the device to re-sync the local password. I've restarted the machine, signed out of Kerberos SSO and signed back in with the new AD password, but my login password is still the old one. Is there a time I need to wait to detect the change?

@vogel Have you found a solution for this issue? We're seeing the same in our environment: initial SSO sign-in syncs the local password, but after an AD password change, the extension doesn't re-sync the local password, even after restarts.

I'm running into the same problem. Did you find a solution?

My next step would be trying NoMad, hoping it works better than the Apple Extension. 

@GrootUser1337 , the problem in our environment turned out to be the resource account we were using for testing purposes (in order to avoid having to change our own AD passwords). Although it was superficially a "person" account in our on-prem AD, it didn't have the necessary attributes to trigger the extension to resync passwords. Once I bit the bullet and used my own account, the extension worked perfectly. We've been deploying it for several months and haven't heard any reports of issues.

Old thread but we're having this exact same issue but with EVERYONE! What attributes was it looking for, do you know the specific ones? When we change the passwords on AD the users are never prompted to resync, but the initial install of the SSO extension works fine. 

You have to start the password change on the Mac. The SSO Profile on the Mac will then check the local and AD password and sync both passwords.

It is not working if you change the AD password via a website service etc.

You're definitely correct that it's not working if we change it via a website service (which is what we've been running into), but unfortunately changing the password with 'Change Password' in the SSO doesn't seem to do...anything for us except change the login to the SSO sign in. 

What's weird is that it all works beautifully the FIRST time we install the SSO extension. It sees that the AD password is different and asks to sync. But if someone changes the password (via the website) after that...nothing.

For example I have LocalPassword1 and I install the SSO extension. It immediately sees that my ADPassword is different, so it prompts me to sync it. That's great! I now log into my computer and all resources with ADPassword.

I then go to our website to change my ADPassword to ADPassword1. Nothing happens on my Mac. It still wants ADPassword to log in, but all resources use ADPassword1.

If I use 'Change Password' from the SSO extension and do ADPassword2, now my logons look like this:

Resources: ADPassword1
Mac: ADPassword
SSO sign in: ADPassword2

Here's the kicker: if I go to the AD password website and sync my password to everything, my SSO Sign in will revert to ADPassword1. 

So things ARE talking to each other but not completely?

As far as I know must the Mac Client start the communication to the AD, once a new AD-Password has been set via a different service, things are messed up.

Did you try to uninstall the SSO Configuration Profile and to re-push it to the Mac Client? That should start a new sync between the local Mac password and the AD password.

Yes and if we do that, it works perfectly.

But I don't want to do that every time one of our hundreds of users changes their password.