Closed anthohny closed 2 years ago
BIG-RAT
commented
2 years ago I'd look at the account attributes either with the directory utility or dscl. I don't have accounts create with Centrify to test with. Wondering if the structure of user attributes for those account are different in some way causing the issue, like having some crucial attribute(s) stored in another directory node (other than /Local/Default).
anthohny
commented
2 years ago Hi Leslie,
Thanks for your quick response! Here is a screenshot of the Directory Utility of a user with Centrify (where the migration didn't work as expected). How would we go about modifying the script to recognize this additional information?
Let me know if you need any other information!
BIG-RAT
commented
2 years ago One would need to compare a typical mobile account generated on a computer bound to AD and see how it differs from one created with Centrify. Doing a dscl . read /Users/username to compare attributes. Been a while, not sure if Centrify still provides a script for removall of it's components.
anthohny
commented
2 years ago Hi Leslie,
Thanks for the suggestion. I'll play around with the dscl . -read command to see any differences.
We do have a script to uninstall Centrify, but we run that script AFTER the mobile_to_local runs. Maybe we need to switch the order of operations and see the results if they are more consistent. Let me build a test machine to try this out. Thanks!
prdgalex
commented
2 years ago Hi anthohny,
I'm in the same boat as you, using Centrify etc. Were you able to figure this one out?
anthohny
commented
2 years ago Hey @prdgalex We ended up finding out our Antivirus was blocking part of the script from finishing. I would start there to see if anything from this script is being blocked by your AV.
Best of luck!
Hello, I just want to start with thanking you all for creating this super helpful script! We initially had no problems with the script and it worked great! However, for the past few weeks, we are in the midst of various issues with the script not working as intended when trying to demobilzing accounts (created when using Centrify in the past).
Additional info: Jamf Connect version: 2.4.5 OS version: 10.15.x and a few 10.14.x versions. Script is pushed out via Self-Service and with switch: -mode silent.
1. The mobile to local migration works, where the account is demobilized, but the user account gets deleted. Only our localadmin account is available for the user to login to.
When this happens, the data for the staff inside of /users/username is still available. Once Jamf recognizes that Centrify is gone and there are NO mobile accounts on the laptop, it will then automatically install Jamf Connect. Once this happens, I have been advising users to simply restart their machines and let Jamf Connect recreate their account. Once they sign into Jamf Connect, luckily, the /users/username account data maps properly to the new account, so all permissions, keychains, and other data seem to be working properly. The one thing that changes the UID, since it is a new account.
We are able to recover the data and elevate the new user account to be able to unlock the disk, but we are unsure why this is happening to a few users who run the script. I just want to note that we advise users to let the script finish completely by waiting for it to self-reboot, before trying to login.
2. The other issue that I have been seeing is the mobile to local migration tool simply not working. Even after running a few times. The script does its thing, the computer may reboot itself, but the script doesn’t look like it finishes up all the way since the account is still mobile and bound to Centrify. One pop up they may see is:
Which is something you would see when creating a mobile account, not sure why this has started to pop up. This problem we haven't quite had a solution, other than completely wiping and rebuilding the machine. Any idea how to troubleshoot or modifications in how we push out the script?
3. The script works properly, however, the user is not able to login using their local credentials on Jamf Connect. They get past Microsoft Azure, then verify their password, but are met with the error that their local password is not in sync with Microsoft (see below).
No variation of the user's local password is accepted in this field. For one user, I had to have them login to our localadmin account, and change their password via Users & groups, add their account to be enabled to unlock the disk, and reboot. This helped with getting Jamf Connect rolling, but wanted to bring up this issue as this is the most recent issue we are running into (only two staff so far).
Please let me know if you need any additional info or logs. Appreciate the help!!!