Script to delete last logged in user or delete all users except for admins

Are you using a directory service such as Active Directory? If so, user accounts won't be stored on computers unless your settings create mobile accounts. You may want to consider removing the option to create mobile accounts in the Directory Utility application and you wouldn't need a script.

To get the name of the last user who logged on to a Mac you can use:

last -1 console | awk '{print $1}'

To get a list of local accounts that are part of the admin group you can use:

dscl . -read /Groups/admin GroupMembership

To remove a user from the Mac's local list of users you can use:

dscl . delete /Users/username

Putting this all together would look something like this:

#!/bin/sh

# Get last logged on user's name
LASTUSER=$( last -1 console | awk '{print $1}' )

# Test whether the LASTUSER is a member of the local admin group.
# Returns "1" if not a member
TESTLOCALADMIN=$( dscl . -read /Groups/admin GroupMembership | grep $LASTUSER )

# Delete last user
if [ $TESTLOCALADMIN = 1 ] ; then
    dscl . delete /Users/$LASTUSER
fi

exit 0

I haven't tested. Someone else may have a more elegant way of doing this.

Thanks for the prompt and detailed response. We are using Active Directory. Unless my understanding is wrong (which is possible) we need to use the mobile accounts since these are MacBook Airs in the hands of users leaving the network and they are syncing to a network folder. I'll test this out and update the post.

Your understanding is correct. You need mobile accounts so that users can log in to the laptops while off network.

What's the purpose of deleting mobile accounts?

We are in the process of moving from an AdmitMac binding to the native OS binding. We have managed to automate the entire process (removing AdmitMac, reboot, remove two leftover files, and bind with native tools), but after binding via the OS any domain users that had previously logged in to the machine now cannot. When we delete the user (and leave the home folder) via the GUI the domain user can then login.

The script returned an error on line 11: [:=: unary operator expected
I'm assuming it was unable to pull a value when testing if the last user was a member of the local admin group, but again I have very limited scripting knowledge.

One possible reason your users can't login again after removing ADmitMac from the systems is that ADmitMac uses a different UUID for user accounts than Apple's AD plug-in. Deleting the old account but leaving the home folder works because when they log back in, their account gets recreated (with Apple's plug-in) and the OS sees the old home folder that has the same name and takes it over.
I've seen something similar with other AD plug-in based products, like Centrify DC.

You can confirm this by capturing the UUID of a user account while still on ADmitMac and then again after the account gets recreated with Apple's AD plug-in.

Try this-

dscl . -read /Users/username UniqueID

Do that before and after and compare the Unique ID that gets returned. Something tells me they won't match.
'If so, there may be another approach you can take to correct this without deleting user accounts.

You may have uncovered yet another problem, unless I'm mistyping something. I am receiving a "<dscl_cmd> DS Error: -14136 (eDSRecordNotFound)" message. Just to clarify the command is dscl . -read /Users/sampleusername UniqueID

Yes, but I just realized that its possible ADmitMac doesn't use the same record information as Apple's AD implementation. What I'd suggest, since you're getting those record errors, is try just pulling up a complete user record with a simple

dscl . -read /Users/sampleusername

If you get any output, you'll likely get a lot of information displayed. Look through that for something that looks like a UUID or Unique Identifier of some kind. It may have a different label than "UniqueID".
Also, this is only going to work on a cached mobile account since the command is looking in the local domain (the "dot" after dscl), not your domain. You can modify it to search through AD, as in-

dscl /Active Directory/DOMAIN/All Domains -read /Users/sampleusername

Change "DOMAIN" to the name of your domain. You might have to make other adjustments to that as well. I'm only going by what works for me in my company and every place is a little different.