Hal

Thanks for your help, and I was looking into the groupmembership option with dscl actually right after I posted it. I think, I can do something like this, probably loop it out for every account in /Users, since by my design of the OS X image, no admin account should ever exist in /Users

maybe something like this, and granted I am just learning how to code loops

I am sure my code is off but I just need to delete the short name from the group membership on that machine locally and it should do the trick. Now, if someone got creative and moved their home directory to a non standard location (which I highly doubt) then I guess they win for now, lol.

You must also check every file on every computer for unwanted suid binaries.

something like: (this one only check /usr/bin)
Dangerous things here are an s in the first triplet and owner root
or an s in the second triplet and group admin. If you don't clean those out then your back on square one again.

So basically you should get a list of those suid commands from a clean machine then compare that with the other machines list. But if your users are savvy enough then thats no help either. Ever heard of a root kit?

Everything gets reimaged once a year so I am not worried and my servers are secured and no one has access to those but the few that need access to them.

I highly doubt any user moved their home directory, I could maybe see a root kit, but I doubt that as well. They are mostly concerned with getting video games on the computers than anything else. I walked into an unmanaged iMac lab about a month ago, and saw that every computer had Halo installed. While I could honestly care less what the users do with their computers as long as they don't abuse the machines physically (it is not may job to manage them as people), other people don't want them playing video games.

It all started from the smallest little over sight of my department too, and before we cold contain it, every user knew what was going on. Some standards I did managed to set up this year were as follows

All local admin accounts live in /private/var

All approved local managed accounts start with a number (that formula has been here since before me, but we still use it).

All applications are owned by root and part of the admin group, users can read and execute but not write, everything in /Applications/utiltiies is off limits via WGM group policy

I created nested groups of users and enforce group policy over MCX for lots of things so I don't need to over kill the local policies on the machine.

The only thing I could think of that may be an actual reality is a key logger, and perhaps that is how they snaked some of the passwords in the past. Well, that and there are some people in my department that have written passwords on sticky notes, and I hate that, but I have no power over it.

What I do have power over, and have proved this three times now, is that I can massively change passwords pretty darn fast.

for -i in /Users returns: -bash: `-i': not a valid identifier
for i in /Users returns just: "/Users"

You probably meant to have: for i in /Users/*
[and even that will run "/Users/Shared" through the mill.]

Also... dscl . delete /Groups/admin GroupMembership $User
was probably intended as: dscl . -delete /Groups/admin GroupMembership "$i"

--

Test loops and script lines with harmless things like ls or echo
For testing, we can even have echo entire commands (most times):...should just echo the "dscl" commands onscreen... not actually call dscl.
[there are limits to that trick, so... fair warning]
Anyway, without the red echo that version might fly.

Nope... needs fixing... hang on.
There... didn't really want full pathnames, just usernames.

--

More fun: running any script as root will turn every ls into ls -A
meaning .DS_Store or .localized or any "dot" files (except . and ..) will also get assigned to $i
<sigh>
Change the first line toAnd stop asking so many questions. :D

Hal

Thanks man, and well I am asking because I don't know and there are smart people like you to give me answers. :D

I am a bit confused on how the local database for OD on a client machine and the LDAP DB on the server side talk to each other. When I run inventory reports with our Casper Suite it shows users flagged as Admin accounts, which at first I thought they were logging and simply flagging their mobile accounts to admin their computer, which you can do to mobile accounts. Apparently, it will allow a mobile user to admin just that computer and not any other machine, so it should technically flag the local DB that account is in group 20 for staff (everyone is in staff) plus group 80 (admin group) but not an admin from the LDAP.

There is a lot of confusion on my part on how exactly this works. After some testing it seems no matter what local group I put a user in (I can even toss them in wheel) group policy from OD trumps it via MCX. As a test I synchronized a test account of mine that is modeled for a student, same policies. Once I sync'd the account I logged in as local admin and promoted that account to admin of that machine. To verify it was in the admin group I did a dscl . read /Groups/admin and sure enough my test account was listed. When I run the id command on it, it doesn't list the admin group at all, only the staff group and whatever group it is tied to in Open Directory. So all group policy applies. I think the downside is, now that the account is promoted they can probably somehow root the system with their credentials since technically they are listed as a local admin account. They can also drag unapproved apps into the apps folder and run them, which is the main concern from the Administration and Education side, they don't want the users playing video games all day.

So, next thing I did after promoting the account to admin is I tried to delete that user from the /Groups/admin from dscl. After removing it from the /Groups/admin the account could no longer install software with it's credentials when it asked for an admin password. So, in theory all of this works. I was just a bit confused on how Leopard managed local and network/mobile accounts from the client to the server and I had to do some testing today to answer those questions.

Thanks again, this script should come in real handy on cleaning up un wanted local user accounts that exist in /Users. It will also take out any user that has promoted their own account via dscl . delete /Groups/admin GroupMembership <shortname> I appreciate all of you guys helping on this one.

Looks like I am going to have to lock the image down a bit tighter for next school year. Kids are smarter than i thought, well some of them at least.

I'm not familiar with (any actual hands-on usage of) OD, LDAP or Casper.
As far as those three go, i must bow out to your (and others') experience.

I confirmed from testing that if a mobile account is promoted to admin, MCX and group policy still trump it, since on the directory their user account is only a member of staff. However, their account can authenticate locally to run admin rights on that machine locally since it was promoted to admin via the check box in System Preferences >> Accounts.

So, even though if the user did promote them self via an old user account we were unaware of (from previous people managing them) they are still restricted to group policy, which I have nailed down pretty tight. The only exception is a user who may know a thing or two about terminal commands and could (with admin rights) basically root the machine and/or physically change their particular machine to a different group or many other things that can be done from the command line. 99% of my users don't know the first thing about the command line, however there are a few smart ones out there that have probably done a few things.

As for the Casper Inventory flagging the user twice, once with admin rights no one knows why that is happening and I uploaded my inventory DB to Jamf support so they could look at it.

Not to revive an old thread but I thought I'd give an update

I found the cause of the password leaks, and it was totally do to some people using a wrong image that had known passwords on it. I know what account it is and I know what it used to be and I set up a simple casper policy that is on going and hits every machine and deletes that one account.

Then I have a script that removes all users from /Users from the admin group via dscl, since no user in /Users should ever be an admin and we put our hidden local admin accounts in /private/var.

Thanks for everyone's help on this. It took me a while to track it down but when running reports on certain machines I noticed that they didn't have windows installed on them, and all of our clients dual boot. Then that immediately told me it wasn't imaged properly, since our netboot imaging process is automated and if you image any macbook you are getting windows via the automation I set up in the auto run data in Casper.

So, every machine also doesn't have windows installed on it which has that old account on that old image that the users know the password for and use it to gain admin rights. The persons using the wrong image have been told to never use that image (and I don't even know why I kept it around, I SHOULD HAVE DELETED IT, lesson learned). Sort of my fault I suppose.

Now I have a script that detects NTFS partitions and if there isn't one a dummy package is installed via Casper and then I create smart groups of the policy receipts to get a full list of machines that need to be reimaged.

Please everyone who reads this, learn from my mistake. Eradicate all of your old images, especially ones that contain accounts that are known to many people.

Man this thread is old but this is how I did it....

I changed the echo statements to invoke the dscl commands, but that is proof of the concept of what I used.