Behavior of Jamf Connect When AD Forces Password Change

test_qweqwe
New Contributor III

We recently tested a scenario with Jamf Connect and Active Directory where we enabled the "Change password at next login" flag on the AD user account.

Here's what happened:

  • I was logout of Jamf Connect and on the Self Service+ UI, I noticed the status said: Password out of sync” and Sign in to your Identity Provider”.
  • On the next login attempt via Jamf Connect, I expected a prompt to change the password. Instead, Jamf Connect displayed an error saying that the password is expired, with no option to change it directly from the login window.

This raises a few questions:

  1. Shouldn't Jamf Connect handle the password change flow directly when AD requires it?

  2. What are the recommended access limitations when a user is not signed into Jamf Connect?

    • Currently, I can still request admin access via Jamf Connect even if I'm not signed in.

    • However, if I log out and log back in, the system prompts me for the current password as expected.

How do you structure access policies around Jamf Connect login state in your organization?
Are there best practices for restricting local or admin privileges until the user is fully authenticated via Jamf Connect?

Would love to hear how others are handling this!

2 REPLIES 2

AJPinto
Esteemed Contributor

 

Jamf Connect syncs with your IDP, something like Okta, Entra, Google, etc, not AD. 

 

With Jamf Connect there are two components at play:

  • Jamf Connect (The login Window App): Jamf Connect will check the IDP for on demand account creation when the user logs in for the 1st time. Every subsequent login Jamf Connect will use the macOS System Keychain for user credential validation which is how macOS is designed to work. You cant change your password from the macOS log in screen or Jamf Connect (log in window app), so change password at next login would do nothing here.
  • Jamf Connect Menu Bar: This tool parodically checks your IDP account to ensure the password still matches the local macOS account. If the passwords do not match, Jamf Connect Menu Bar should prompt you to sync your password. I would not Imagin there is a specific workflow for change password at next log in from AD, if the IDP comprehends change password at next login and tries to enforce it on Jamf Connect Menu Bar when its validating user credentials I'd not be shocked for it to confuse Jamf Connect as the IDP refused the account authentication. Seems very plausible for Jamf Connect Menu Bar to assume the account is locked or disabled.

 

Jamf Connect's Privilege Elevation for Local Accounts:

  • If you are allowing users to give themselves admin access without any checks and balances that is a significant configuration problem and you may as well just make your users admins.
    • Ideally you should have Privilege Elevation configured using UserPromotionRole, and limit the users that have this Entra/Okta role to your IT and Support staff. General users should not have the ability to grant themselves unsupervised admin access for any amount of time.
    • In they very least, adding your end users to the roles allowing UserPromotionRole will force and IDP check before Admin Access is provisioned.

 

I'm a strong supporter of the concept  if you allow users to manage their own admin access, even for temporary windows of time you may as well just not manage admin access at all as you are only giving the illusion of control.

 

A rule of thumb, macOS views itself as the top IDP, peroid. Dont expect macOS to care if you lock or disable an IDP/AD account. PSSO may have more functionality in this space, but I have not tested it myself.

 

TD;DR:

Change Password at next login is a Windows centric configuration, macOS really has no comprehension of it. If users can give themselves Admin Access with Jamf Connect's Privilege Elevation you have it configued wrong.

https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Configuring_Privilege_El...

thlemaire
New Contributor II

Jamf connect ( the Login window App) can work in two ways. Account provisionning and then Local authentication or full IDP mode.  this depends on how you set your keys in your configuration profil.  Denylocal and LocalFallBack https://learn.jamf.com/en-US/bundle/jamf-connect-documentation-current/page/Login_Window_Preferences...

But this can lead to multiple user authentication on filevault and then on the MacOS Login window.