one of those days, can't remember syntax

You need to use the GUID. If I'm not mistaken, it's stored in the user's
record as the "GeneratedUID".

dscl . -delete /Groups/<group> GroupMembers <GUID>

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

These are Directory users that have promoted them self to admin via an
old test account and we are cleaning it up, would that make any
difference?

I would have sworn in the past I have used what I posted a few minutes
ago.

What error is your command returning?

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

DS error -14134 (eDSAttributeNotFound)

If I do a dscl . list /Users UniqueID | grep <shortname> the user shows
up with their GUID so I know that they are in fact there

I'm not sure what's going on there, however I'm fairly certain that using
the GUID will get you where you need to be.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

OK

This is what confuses me and frightens me...

jamf listUsers returns the localized mobile account as having the <true>
value as the account being an admin

dscl . read /Groups/admin Does not list the account

dscl . -delete /Groups/admin GroupMembership <shortname> or <UID>
returns an error that the attribute is not found, so I am guessing that
means that the account isn't in that group

Is this a bug with Casper?

Well

On some machines it shows the admin value as true and on others it
doesn't. This inconsistency is really making me think that some users
promoted their accounts to admin via an older test account which they
got the password to. Then again, dscl returns that they are not admins. Some of these machines have obviously been changed by someone other
than the IT staff, so I know some of them have been promoted.

I was looking at a way to loop /Users and make sure all users are
demoted just back to staff and not admin at all. However, I am getting
conflicting information from dscl and jamf listUsers

Thoughts?

On Fri, Jan 16, 2009 at 11:23 AM, Thomas Larkin <tlarki at kckps.org> wrote: jamf listUsers returns the localized mobile account as having the <true> value as the account being an admin dscl . read /Groups/admin Does not list the account

That's just odd. Can you verify that these accounts actually have admin
privileges? Maybe someone at jamf can comment on how Casper determines
whether an account is an admin? At a confident guess, I'd say that the
"jamf listUsers" information is only as good as your last Recon of that
machine. Are you updating inventory regularly? I check the "update
inventory" box on just about every policy I create to make sure I've got up
to date information.

This weirdness aside for a moment, assuming you have an account that is
verifiably a member of a group that you don't want it to be a part of, you
can run this command to take it out of the group.

sudo dseditgroup -o edit -d <username to be removed from group> -t user
<group>

The UUID method I mentioned earlier also ought to work, but I've tested the
dseditgroup method this afternoon.

I assume that you've got some legitimate admins on the systems that you'd
want to skip, so you could do something like...

for i in $( dscl . -read /Groups/admin| grep GroupMembership:| awk '{for
(j=3; j<=NF; j++) printf " %s", $j; printf " " }' ) do case $i in <legitadmin1>) done ;; <legitadmin2>) done ;; *) dseditgroup -o edit -d $i -t user admin ;; esac done

Test, test, test. Be very careful when editing your directory service. You
may want to create a new group to test with so you don't risk breaking the
admin group or your legit admin accounts.

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com

On Fri, Jan 16, 2009 at 11:23 AM, Thomas Larkin <tlarki at kckps.org> wrote:

Thanks for that.

I am wondering if at one time they did promote them self to admin is
all. Also, by design in my image all proper admin accounts are stored
in /private/var so any user in /Users should never be an admin account
on the student machines. Teacher machines do have a local admin
account in /Users but there is also a hidden admin account on there as
well.

All IT staff have access to the local hidden admin account.

So as long as the user lives in /Users I can demote it back to staff and
get it out of the admin group.

Thanks for the replies, have a good weekend everyone. Three day weekend
for us people in education, gotta love those holidays we get off.

Later

Tom

What if the clever little hackers created admin accounts with homes
somewhere other than /Users?
That bit of code in the for statement grabs all members of the admin group
using dscl (except root - that was intentional to avoid any messiness),
regardless of where their home folder lives. You also don't need to contend
with /Users/Shared this way.

Anyhow, enjoy the weekend. Some of us corporate drones have Monday off too. :)

----------
Miles A. Leacy IV

? Certified System Administrator 10.4
? Certified Technical Coordinator 10.5
? Certified Trainer
Certified Casper Administrator
----------
voice: 1-347-277-7321
miles.leacy at themacadmin.com
www.themacadmin.com