Need help or script to fully uninstall Centrify

We did the same, I never got this fully automated, but at least I didn't have to get out of my chair:

1. Send script to machine to uninstall Centrify and then reboot:

   /usr/share/centrifydc/bin/uninstall.sh -n

2. Send native AD bind commands to machine.

3. Reset privs for users local home folder:

   chown –R username:staff /Users/username

That last part is necessary because Centrify and Native AD plugin will set different UID's on the local files and folders.

Sounds like that can easily be automated all in one policy if that's the case.

Make a script and set it to run BEFORE with that one line command.
Then add the AD Binding payload to the policy (you have to configure an AD binding in the JSS before hand to use this). If you need instructions on how to do this let us know.
Then have a second script that is set to run AFTER that basically loops through the home directories and fixes permissions. For AD, the group ID will be different I believe. It won't be staff. It's usually unique. And you can get an idea of what it is by opening up Directory Utility on your computer and searching for any user in your domain and looking up the PrimaryGroupID so the command would really be:
chown -R $username:$PrimaryGroupID /Users/$username

You will want to make sure those computers are on your network and can reach your domain controller though. Network segments come in handy for this so you can then scope this policy to run on all computers with a limitation scope of the network segment(s) to ensure the DC can be reached.

For CentrifyDC version greater than 5.2.4, the path for the uninstall script is:

/usr/local/share/centrifydc/bin/uninstall.sh

Changed to accomodate 10.11.

I can verify the above line does work to uninstall Centrify above v.5..2.4, on 10.11 machines. I'm also experiencing the UID weirdness on the user folders, and I made a .command file to run to fix it:

#!/bin/bash
read -p "Enter User Name : " userName
# run chown to change permissions on the user’s folder
sudo chown -R $userName /Users/$userName

My problem with this is that the UID doesn't always change the way it's supposed to after uninstalling Centrify. For example, it looks like this when you run:

ls -l /Users

drwxr-xr-x+ 25 znilsson staff 850 Mar 18 14:31 znilsson

And then after uninstalling Centrify then running the Casper QuickAdd package to enroll and also bind the Mac to AD using a preset binding in Casper, it looks the same, meaning the UID hasn't changed, which means running the above chown script doesn't actually do anything and I can't log in as a network user.

What it does is attempt to log in and then the progress bar never goes away. I found that doing that, rebooting back into the local admin account and then running ls -l /Users/ again shows the UID to be something completely different. At that point, running the chown script works and everything is fixed.

Anybody have any idea why that's happening? I would love to be able to do a one-click script to uninstall Centrify, bind to AD and then fix permissions, but so far it just hasn't been that simple. Heck I'd be happy with knowing how to make the chown script work correctly the first time so I don't have to mess with logging in to a never-ending progress bar, powering off and back on, logging in to the admin account and then running the chown script.

@znilsson This script might help.

If ran post AD bind it should then do an AD lookup & chown with the users AD UniqueID.

@znilsson I believe the command you're looking for, and that I frequently fall back on to correctly differentiate between UID# for users is the -n switch on ls.

hostname$ ls -ln /Users
total 0
drwxwrxwrt   8 0           0          121  Feb 29 11:11 Shared
drwx------  12 501         20         223  Feb 29 11:23 first_local_user
drwxr-wr-w+ 18 1934567891  597654321  102  Feb 29 12:02 ad_based_user

Having encountered this issue more than enough times it's one of those that I keep telling myself, "One of these days I'm going to write a nice elegant script to deal with this."

And when using chown you likewise then substitute the raw numbers from the 3rd and 4th columns (& 9, where they respectively represent user ID, group ID, and home folder/user name) above, such as:

hostname$ chown -R $column3:$column4 /Users/$column9

Then it's just a matter of throwing the whole thing into a little loop and letting awk pull your variables for you. Of course, you'll want to exclude messing with the Shared folder and it'd be nice to check the variables to ensure they're large enough to be domain users (i.e. much greater than 5xx-valued local users)...

@bentoms Yeah... that seems about like what I've been meaning to do myself. And somehow my brain skipped over your comment just so I could write this foolishness.

I tried the script @bentoms linked to, but no dice. I have the same problem. I uninstall Centrify, I bind to AD (via the QuickAdd package, which causes Casper to apply my AD binding), verify it's bound, run the script (which does run without errors), then log out and log back in as an AD user (myself). Same problem, just get the spinning wheel, I actually get both the beach ball and the normal spinny wheel, and it never logs in.

So I have to force power down the Mac, log back in to the local admin account, run this:

#!/bin/bash
read -p "Enter User Name : " userName
# run chown to change permissions on the user’s folder
sudo chown -R $userName /Users/$userName

And then I can log out and back in as my AD user account and it's fine. So I'm pretty sure the issue is not with the script per se, since it does the same thing whether I use my little script above, or the full one posted by @bentoms. The issue seems to be that after uninstalling Centrify and binding to AD, the permissions of the account is not in a state that the scripts can "fix". It only gets that way after I try to log in as an AD user, at which point the permissions get hosed, at which point the scripts work to fix it.

I'm at a loss as to how to solve this problem since it doesn't seem to match up to the issues other people are having with the Centrify to Casper conversion, at least not exactly.

Is it possible that after you've uninstalled Centrify and bound to AD that a restart may be required? Jut curious if you have a second policy that takes care of repairing permissions whether that's in the form of a launchdaemon that runs a script that would self delete or a policy that runs on startup once per computer.

@bpavlov I am going to try the restart option next, but based on past experience it won't change anything. I will try it though, I'm in the process or resetting everything on my test machine right now. Nothing I'm doing is policy-based other than the policies I have set to run when a Mac is enrolled - meaning the Centrify uninstall, the QuickAdd and the permissions fix script are being run manually off a USB stick.

If I can ever figure out how to make this work smoothly I might try to do it via policy but until then I'm just doing it manually to try to troubleshoot.

Tried to put it in a policy and it gave me this:

Actions from policy log: Executing Policy UnInstall Centrify and bind to AD Running script UnINstall Centrify... Script exit code: 25 Script result:

WELCOME to the Centrify Suite installer!

Detecting local platform ...
preparing for uninstall ...
Do you want to uninstall Centrify DirectControl (CentrifyDC-5.2.4)
from this computer? (Q|Y|N) [N]:Install.sh completed successfully. Nothing was installed or uninstalled.

Error running script: return code was 25.

Does the uninstall script take any flags or options? Perhaps its documented somewhere on their website. You might also be able to open up the script yourself and see what modifications you can make to keep it moving along.

@NeallV You've probably taken care of this, but... When I use the command line:

/usr/local/share/centrifydc/bin/uninstall.sh

After the prompt: Do you want to uninstall Centrify DirectControl (CentrifyDC-5.3.0)
from this computer? (Q|Y|N): Y
Then:
Reboot the computer after uninstall? (Q|Y|N) Y
Then:
This computer is currently joined to the Active Directory domain. To remove the software cleanly you should leave the domain. To do so you need to provide AD username and password. Running adleave...
Then:
Enter the Active Directory authorized user [administrator]:

If I don't enter credentials, the uninstall aborts. Is this part of your procedure? I manually restart the Mac after uninstalling Centrify agent before I reinstall and join the domain--since we need Centrify for smart card use.

Forgot to do a -n at the end of the script. It works now. Thanks!

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.sh

And 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/$userName

and 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.