I wanted to be clearer about what's happening, so here's a breakdown of the process I have to go through to complete the Centrify to Casper transition, including screenshots.
So first step is uninstalling Centrify. I use the string as listed above to run the uninstall script and this part works fine:
#!/bin/bash
sudo sh /usr/local/share/centrifydc/bin/uninstall.shAnd it is interactive, so I have to manually enter Y to confirm uninstall, and then Y or N to confirm a reboot afterward. I've tried both with rebooting and not rebooting at this stage, and it makes no difference relative to the issue I'm having. Centrify is uninstalled at this point, and so far I have not had any issues with Centrify uninstalling.
Next step is to rebind to AD. So I use my Casper QuickAdd package, which enrolls the Mac and triggers my AD Bind policy, which is set to run at enroll. No problem there either, the Mac is enrolled, some policies run, and the Mac is bound to AD at this point. I have tried rebooting after Centrify uninstall AND rebooting after the AD bind - so two reboots - and it makes no difference relative to this issue.
Here's a screenshot of the ls -l command and the ls -ln command, this is how it looks at each stage of this process, even after rebinding to AD.
Right here you can see what the issue is - after uninstalling Centrify and rebinding to AD, the ls -l command still shows my name in column #3, and this is the crux of the issue. It should be showing me the number sequence as seen in the ls -ln command right above it. What this means, for the purpose of this discussion, is that the permission fix scripts do not work at this stage. They will run, but they won't actually fix the permissions, presumably because the UID hasn't changed and it's still showing my name in column #3.
So rebooting at this point doesn't change anything, and re-running the script doesn't change anything either. The only thing I've found that actually works to "break" the permissions is to log out, log back in as my AD user account, and then watch as I get the spinny wheel forever and it doesn't log in. Then I hold down the power button and force it to shut down, start it back up and log back in to the admin account. Then when I run the LS commands it looks like this:
Note that the 3rd column in the ls -l command now shows the UID rather than my name, and it mirrors what's shown with the ls -ln command. Now my home directory's permissions are in a state that the script can actually fix. So I run my small script as shown here:
#!/bin/bash
read -p "Enter User Name : " userName
# run chown to change permissions on the user’s folder
sudo chown -R $userName /Users/$userNameand immediately after running that script, my permissions look like this:
Note that with ls -l my home directory is again showing my username, and ls -ln shows that it has a new UID, indicating that the permission/AD merge process was completed successfully. At this point I can log out of the admin account and log in as myself, and everything works fine.
As of now, the only thing that works to screw up my permissions enough for the script to fix it is doing a hard power off while it's trying to log in to my AD account, as described above. No idea why. I mean if this is how we have to do it, I guess we don't have a choice, but I would love to know why it's happening like this. I don't like the idea of doing a hard power off while it's trying to log in to a user's account, but it's the only way I've found so far to get the whole process to work.
