Skip to main content

I am piloting Jamf Connect with Google as our IdP for some students in K-12. (with the hope of also doing staff)

Currently if they forget their password, we need to reset their Google password, and then, as admin reset the local password on their computer.

This requires physically having access to their computers. There's almost no point to have Jamf Connect if a password reset requires local login to finalize.

 

(Further, after this process, it always requires the "verify" step... I think that's a different issue, but now some students have to type their PWs twice to get in.)

Is this everyone else's experience too?  Seems pretty untenable. What would people do with a globally disperse workforce where IT can't physically have access to the machine?)

Would Azure or another IdP handle this better?

@Hiller , Jamf Connect isn't the end all be all. It really just keeps the local password and the Idp password in sync when a password reset/change is required, (It also keeps keychains in sync, which is nice) It's up to the user to remember their password (even on a Windows machine). If this does happen you have two options:

Method 1

1. Disable jamf connect login with a check-in/startup policy.

2. Reboot the machine.

3. Reset the local password with the recovery key at the FV2 login screen.

4. Reset the IDP password.

5. log into the computer with the new FV2 password.

6. Sync the FV2 and IDP password.

 

Method 2

1. Boot to Recovery

2. Reset the password with the recovery key.

3. Reset the IDP password.

4. Reboot.

5. Use the FV2 password to bypass the FV2 login.

6. Use the IDP password to login/sync both passwords.

Not really jamf's fault but Apple's fault.

If you want to reduce the number of logins enable passthrough authentication btw.

Been working with Jamf Connect since 2020 (deep in the quarantine). Deployed and managed it without ever touching a user's machine. (500+ fleet all remote and global) It's honestly resolved most of my password reset problems, just takes some time to understand.

Should see improvements with jamf connect and platform sso in ventura.

@Hiller , Jamf Connect isn't the end all be all. It really just keeps the local password and the Idp password in sync when a password reset/change is required, (It also keeps keychains in sync, which is nice) It's up to the user to remember their password (even on a Windows machine). If this does happen you have two options:

Method 1

1. Disable jamf connect login with a check-in/startup policy.

2. Reboot the machine.

3. Reset the local password with the recovery key at the FV2 login screen.

4. Reset the IDP password.

5. log into the computer with the new FV2 password.

6. Sync the FV2 and IDP password.

 

Method 2

1. Boot to Recovery

2. Reset the password with the recovery key.

3. Reset the IDP password.

4. Reboot.

5. Use the FV2 password to bypass the FV2 login.

6. Use the IDP password to login/sync both passwords.

Not really jamf's fault but Apple's fault.

If you want to reduce the number of logins enable passthrough authentication btw.

Been working with Jamf Connect since 2020 (deep in the quarantine). Deployed and managed it without ever touching a user's machine. (500+ fleet all remote and global) It's honestly resolved most of my password reset problems, just takes some time to understand.

Should see improvements with jamf connect and platform sso in ventura.


Also, if you want to save money on JC, you can use the free version named XCreds. Just listened to the episode on the macadmins podcast. the creator of Jamf Connect is "involved" with it's creation as well. May switch to it to save some money.

@Hiller , Jamf Connect isn't the end all be all. It really just keeps the local password and the Idp password in sync when a password reset/change is required, (It also keeps keychains in sync, which is nice) It's up to the user to remember their password (even on a Windows machine). If this does happen you have two options:

Method 1

1. Disable jamf connect login with a check-in/startup policy.

2. Reboot the machine.

3. Reset the local password with the recovery key at the FV2 login screen.

4. Reset the IDP password.

5. log into the computer with the new FV2 password.

6. Sync the FV2 and IDP password.

 

Method 2

1. Boot to Recovery

2. Reset the password with the recovery key.

3. Reset the IDP password.

4. Reboot.

5. Use the FV2 password to bypass the FV2 login.

6. Use the IDP password to login/sync both passwords.

Not really jamf's fault but Apple's fault.

If you want to reduce the number of logins enable passthrough authentication btw.

Been working with Jamf Connect since 2020 (deep in the quarantine). Deployed and managed it without ever touching a user's machine. (500+ fleet all remote and global) It's honestly resolved most of my password reset problems, just takes some time to understand.

Should see improvements with jamf connect and platform sso in ventura.


Well, that's promising. I was about ready to throw this out the window.

But... I'll try to get my process down and see if I can do it in a reasonable way.

Thanks!

Well, that's promising. I was about ready to throw this out the window.

But... I'll try to get my process down and see if I can do it in a reasonable way.

Thanks!


Good luck man, you may also want to join #MacAdmins on slack to interact with the Jamf Connect engineers directly. They're in #jamfconnect.

Also, if you want to save money on JC, you can use the free version named XCreds. Just listened to the episode on the macadmins podcast. the creator of Jamf Connect is "involved" with it's creation as well. May switch to it to save some money.


Does XCreds require LDAP to sync that password like with Jamf Connect? I'm looking through the product description but not finding an answer. Thanks!

Reply


Terms & ConditionsCookie settings