Password Sync issue with Okta and local passwords

[robertoa]

Hi All,

I'm currently trying to migrate all our users from Airwatch (old MDM) to JAMF. First step is to remove the MDM from the device and any old apps then perform the time machine backup. Some users are on Catalina or Mojave so remove old apps that need to be updated. After TMB is complete I wipe the disk and re-install macOS to latest version. When I enroll via DEP + Okta i get the option to restore data from Time Machine (other way is using Druva after config is complete). Once everything is configured I update the apps and sign the user in. Everything looks fine but when the user changes their password JAMF connect does not allow it to sync to the newly set password. I restart the device have the user log in with the last local password then get taken to the the JAMF connect Okta login screen. I connect successfully through okta with the new password but then when asked to enter last local password it says "Invalid". I suspect something in the keychain from the TMB so i reset default keychains and even cleared both JAMF connect keychains and tried again but no luck. 

Above screenshot is when trying to connect after a restart. 

Above screenshot is when trying to update via JAMF connect menu bar icon. 

Any ideas would be greatly appreciated. I'd prefer to keep TMB as a valid option for developer users so they don't have to re-build their entire environment. Other options are to do a standard enroll then restore data using Druva and re-configure apps. Tested this with an affected user and user was able to sync new password successfully. 

[Tribruin · Accepted solution]

Time Machine and MDMs don't mix very well. I would highly discourage using restoring from a Time Machine backup to an MDM enrolled computer. At the very least, do not restore the Library folder, only Document folders, which kind of defeats the purpose of making it so developers from having to set up their environment again. 

Do you have to wipe the computer? Why not just unenroll from AirWatch, upgrade the computer to Monterey, and then re-enroll in to Jamf? If you want to ADE enroll, assign the serial numbers to a Prestage in Jamf and run the command sudo profiles renew -type=enrollment to force an ADE enrollment without having to wipe the computer. That way the user keeps his profile and data intact. 

[Tribruin · Accepted solution]

Time Machine and MDMs don't mix very well. I would highly discourage using restoring from a Time Machine backup to an MDM enrolled computer. At the very least, do not restore the Library folder, only Document folders, which kind of defeats the purpose of making it so developers from having to set up their environment again. 

Do you have to wipe the computer? Why not just unenroll from AirWatch, upgrade the computer to Monterey, and then re-enroll in to Jamf? If you want to ADE enroll, assign the serial numbers to a Prestage in Jamf and run the command sudo profiles renew -type=enrollment to force an ADE enrollment without having to wipe the computer. That way the user keeps his profile and data intact. 

[robertoa]

We wipe the computer so that it enrolls via DEP. We gain more functionality using DEP enrollment vs User Initiated. 

[Tribruin · Accepted solution]

That is what the profiles command does as well. It will attempt to enroll the computer via DEP outside of setup. I would give this a shot, it might be a better solution than wiping and setting up the computers again. 

[robertoa]

Good idea. I'll keep this in mind as another possibility and give it a shot on my next migration. 

[robertoa]

Thanks for the insight Tribruin! Tested and confirmed removing the users from old MDM, unbind the device then do a sudo profiles renew -type=enrollment worked like a charm. This will cut our migration by at least half the time now since I can now do it remotely and no longer requiring taking a time machine backup and wiping the disk. If I ever see you at JNUC I owe you a beer! Thanks again. 

[dvasquez]

I would look to verify the keychain and also reset and create a new one. This removes traces of the old password from the Time Machine backup, and you can start fresh. Ensure your setting are correct with Okta, we use Azure, and then try to sync with the newly created local password. 

[robertoa]

I'm leaning more towards the keychain as well. Going to circle back to troubleshooting that and see if creating a new one will remove any traces of the old Time Machine Backup. 

[robertoa]

Closing this loop. I found the issue is that the machine was still bound to the domain when the time machine backup was initially taken. I tested my migration process on another device and found the device still bound to the network. I unbound the device, did a TMB and restored it after enrolling into JAMF. User was then able to change password and sync successfully with new one.