Removed account still listed as having admin?

[jhuls]

Some time back we used a particular account labeled as "ctsetup" which had admin privileges for doing some setup work on our Macs. Once done Casper would remove the "ctsetup" account with a policy. In looking just now at a system remotely via ssh I used the following to view user accounts and don't see "ctsetup" which is how it should be...

dscl . list /Users | grep -v ^.

If I view to see who is a member of the admin group via the following command, I do see "ctsetup".

dscl . read /Groups/admin GroupMembership

I don't know enough about the dscl command and how it works so I wanted to see what someone here could explain on the subject. I found those lines while looking online. Why would "ctsetup" even show up as a member of the admin group if it no longer exists...or does it?

Is there a good resource for learning more about dscl?

[mm2270]

@jhuls You can start with the man page in Terminal learning more about dscl. Also, almost all man pages are available online in your browser if you prefer reading through them that way. For example, here is the full Apple man page on dscl.

As for the issue you're describing, I'm not sure where you found the command dscl . list /Users | grep -v ^., but that isn't giving me the correct results when I run it on my Mac. It lists no accounts, which isn't even remotely accurate. The grep -v ^. part is telling it to only get the reverse of any accounts that don't start with a period, which isn't making sense to me. I'm wondering if that was meant to be grep -v ^_ instead, which would exclude all the system created accounts that have a _ symbol as the start of their names.

Can you just drop that part and run dscl . list /Users instead and see if that "ctsetup" account is still there?

[jhuls]

Hmmm...it looks like jamfnation dropped the last part of what I pasted. Lets see if this works.

dscl . list /Users | grep -v ^_.*

[jhuls]

So that worked...and next time I'll try to remember to use Preview before posting. sigh

Anyways...It doesn't matter whether I exclude the grep portion though as there still isn't a ctsetup account...which like I said should be gone. I've not visited the system to try logging in with it but if it's not in /Users, I'm assuming I wouldn't be able to log in with it.

[dwandro92]

My guess is that Casper just removed the account using a method equivalent to running dscl . -delete /Users/ctsetup. When an account is removed in this way, it doesn't seem to modify the group records like one would assume that it should.

You should be able to resolve the issue by executing the following command: sudo dscl . -delete /Groups/admin GroupMembership ctsetup.

[jhuls]

Thanks @dwandro92 ...I figured I could remove it out of there. I'm just a bit surprised that it wasn't removed when the user account was removed.

I can't test it now but it makes me wonder if that opens up a security issue. What might happen if that account is removed yet remains in the admin group as I've described and then later a new account of the same name is created that is intended to be a standard user account? I wish I had more time today because I'm really curious to see if this would play out to where that user account would have admin privileges again unintentionally.

[dwandro92]

@jhuls, if the username still appears in the group record and the account is re-created as a standard user using System Preferences, dscl . -create /Users/ctsetup, or jamf createAccount -username ctsetup -realname "Test ctsetup", they will still have admin privileges.

On a related note, the group record appears to remove the user successfully when the account is deleted using System Preferences or jamf deleteAccount -username ctsetup -deleteHomeDirectory.