Mac forget network Useraccount Passwords

Andixon
Contributor

Not really a Jamf problem, but maybe someone here knows something. For a few months now I have had the problem that some Macs just wont accept a users credentials after a few weeks or months. I have no idea what triggers this. One moment it works and one restart later the user just cant log in anymore. This happened with Monterey and Ventura. It also happened multiple times and I am sure it was not just typos.

This really is a problem because the Macs are encrpyted, so the users cant access their data anymore.

I cant really investigate this, because once the Macs are locked I cannot access the anymore.

I am using AD bound Macs with network accounts. 

3 ACCEPTED SOLUTIONS

AJPinto
Honored Contributor III

I'm going to wager the passwords are desyncing. AD Binding or not macOS views itself as the top password identity. If a users password is changed on another device its a crapshoot on if macOS will accept it or not.

 

I also cannot stress enough, stop AD binding. Apple has stopped building macOS with this work flow in mind. I would say use the FV recovery key to get the user back in, however as of macOS 11 this triggers a local password reset which will desync the mobile accounts password from the AD password. Using mobile accounts is what is making you rebuild the user profile (or reimage) every time this happens rather than just resetting the password on the device.

View solution in original post

AJPinto
Honored Contributor III

I am not saying the only thing that causes this is a user changing their password somewhere else. Its just that this is the cause 99% of the time when I see this issue. Console will have logs on account changes, as well as when FV passwords were updated. You can also check their AD record for when they changed their PW last.

 

The work flow in my experience:

  1. User changes their PW on another device
  2. User get their Mac, and tries to use their new PW on FV which wont work
    1. User realizes they need to use their old PW, then they get to the macOS Login Screen
      1. If the Mac is offline they may or may not realize they need to use their old PW.
        1. FV password does not update as the password change trigger did not happen on macOS, and when the user reboots they cant get back in as FV wont accept the old or new PW.
      2. If the Mac is online, its a 50/50 chance on if it will let them log in and update the password or break the user account.
        1. FV password does not update as the password change trigger did not happen on macOS, and when the user reboots they cant get back in as FV wont accept the old or new PW.
    2. The user does not realize they need to use their old FV password, and calls you for support
      1. You tell them to use their old PW and they get in, and follow the work flow above.
      2. The dont remember their old PW.
        1. You give them the recovery key which breaks their account's syncing to AD.
      3. You cant get them in and they are screwed

 



 

What documentation are you wanting? There is really nothing current for domain binding as Apple moved away from that some 10 years ago. We moved away from domain binding last year as apple and JAMFs only troubleshooting advice was to stop domain binding. It became more of an investment to maintain than it was to move away from.

View solution in original post

AJPinto
Honored Contributor III

Ah, got ya. 

 

  • Domain Bound vs nonDomain Bound
    • For macOS itself, there are really not that many differences.
      • using the FV recovery key wont break stuff.
      • Account PW syncs are handled differently, and be more reliable.
      • Creating the user account would need to be rethought.
        • JAMF can do this with a policy
        • Users can be allowed to make their own accounts
        • JAMF Connect can be purchased to handle this
    • You will lose Kerberos tickets, but there are ways to get those back.
    • For Applications that identify the user like security tools, you would need to have the app owner consult the vendor. Of our 6 security tools, one needed to be repackaged with a different option, and another needed weird shenanigans to keep working. The one that needed shenanigans is being retired as it had a lot of gaps.
  • Best Practices
    • Dont domain bind
    • Create a Configuration Profile for PW requirements in JAMF.
    • Use a SSO extension to link the local mac account identity to the AD identity.
      • Tools that can do this are Apples SSO extension (built in to macOS), Microsofts Comp Portal, NoMad, Okta Verify, JAMF Connect, and many others.
        • These tools can generate Kerberos tickets if you need them.
        • Work flow is user changes their macOS password. The SSO connector sees the local PW and Domain PW don't match, and makes the user sync them. If the user changes their password on another device the same work flow happens, the macOS password does not update automatically and nothing breaks.
  • What to Avoid
    • This one is hard to say, as it is very dependent to your environment.

 

For us the only tool I saw that checked all our boxes was JAMF Connect. It gave IDP login, MFA, had good documentation and vendor support, so on. It may be worth a review to see if it meets your needs.

Jamf Connect Documentation | Jamf

 

View solution in original post

5 REPLIES 5

AJPinto
Honored Contributor III

I'm going to wager the passwords are desyncing. AD Binding or not macOS views itself as the top password identity. If a users password is changed on another device its a crapshoot on if macOS will accept it or not.

 

I also cannot stress enough, stop AD binding. Apple has stopped building macOS with this work flow in mind. I would say use the FV recovery key to get the user back in, however as of macOS 11 this triggers a local password reset which will desync the mobile accounts password from the AD password. Using mobile accounts is what is making you rebuild the user profile (or reimage) every time this happens rather than just resetting the password on the device.

I dont think it is a syncing issue. Because it mostly happened without a network connection, when the password is cached. Afaik none of the users changed their passwords before this happened.

Also: Wouldnt this be an issue with the mobile accounts and not with the AD binding, because thats where the password is?

I really want to move away from AD binding, but unfortunately I am missing time and resources. 

Can anybody provide me with the necesary documentation for this?

AJPinto
Honored Contributor III

I am not saying the only thing that causes this is a user changing their password somewhere else. Its just that this is the cause 99% of the time when I see this issue. Console will have logs on account changes, as well as when FV passwords were updated. You can also check their AD record for when they changed their PW last.

 

The work flow in my experience:

  1. User changes their PW on another device
  2. User get their Mac, and tries to use their new PW on FV which wont work
    1. User realizes they need to use their old PW, then they get to the macOS Login Screen
      1. If the Mac is offline they may or may not realize they need to use their old PW.
        1. FV password does not update as the password change trigger did not happen on macOS, and when the user reboots they cant get back in as FV wont accept the old or new PW.
      2. If the Mac is online, its a 50/50 chance on if it will let them log in and update the password or break the user account.
        1. FV password does not update as the password change trigger did not happen on macOS, and when the user reboots they cant get back in as FV wont accept the old or new PW.
    2. The user does not realize they need to use their old FV password, and calls you for support
      1. You tell them to use their old PW and they get in, and follow the work flow above.
      2. The dont remember their old PW.
        1. You give them the recovery key which breaks their account's syncing to AD.
      3. You cant get them in and they are screwed

 



 

What documentation are you wanting? There is really nothing current for domain binding as Apple moved away from that some 10 years ago. We moved away from domain binding last year as apple and JAMFs only troubleshooting advice was to stop domain binding. It became more of an investment to maintain than it was to move away from.

I dont know. Documentation on how to start. What are the differences between having the devices bound to AD and not having them bound? What are best practices? What should I avoid? I also have not started yet because I have found so little about this and I do not have much knowledge myself. 

AJPinto
Honored Contributor III

Ah, got ya. 

 

  • Domain Bound vs nonDomain Bound
    • For macOS itself, there are really not that many differences.
      • using the FV recovery key wont break stuff.
      • Account PW syncs are handled differently, and be more reliable.
      • Creating the user account would need to be rethought.
        • JAMF can do this with a policy
        • Users can be allowed to make their own accounts
        • JAMF Connect can be purchased to handle this
    • You will lose Kerberos tickets, but there are ways to get those back.
    • For Applications that identify the user like security tools, you would need to have the app owner consult the vendor. Of our 6 security tools, one needed to be repackaged with a different option, and another needed weird shenanigans to keep working. The one that needed shenanigans is being retired as it had a lot of gaps.
  • Best Practices
    • Dont domain bind
    • Create a Configuration Profile for PW requirements in JAMF.
    • Use a SSO extension to link the local mac account identity to the AD identity.
      • Tools that can do this are Apples SSO extension (built in to macOS), Microsofts Comp Portal, NoMad, Okta Verify, JAMF Connect, and many others.
        • These tools can generate Kerberos tickets if you need them.
        • Work flow is user changes their macOS password. The SSO connector sees the local PW and Domain PW don't match, and makes the user sync them. If the user changes their password on another device the same work flow happens, the macOS password does not update automatically and nothing breaks.
  • What to Avoid
    • This one is hard to say, as it is very dependent to your environment.

 

For us the only tool I saw that checked all our boxes was JAMF Connect. It gave IDP login, MFA, had good documentation and vendor support, so on. It may be worth a review to see if it meets your needs.

Jamf Connect Documentation | Jamf