Extension attribute below

!/bin/sh

accounts=$(dscl . -read /Groups/admin GroupMembership | tr " " " " | grep -v "GroupMembership:" | grep -v "root" | grep -v "_sophos" | grep -v "_mbsetupuser" | grep -v "_jss" | grep -v "casper")

echo "<result>$accounts</result>"

Not sure what commands the jamf binary runs 'under the hood' to get that. My question is, what account is "izzey.felczak" on that Mac? Is it a real account with a home folder, or is it a directory only based account? I have a feeling jamf only picks up real local accounts, not something that is only admin when connected to a directory service, but I could be wrong.

Can you post your EA also? It might shed some light on the issue, though my assumption is it's using the dscl . read command mentioned in your post title.

OK, cross posting, as I see you did post your EA. So, reading the group membership from the admin group is unfortunately not going to be 100% accurate. The reason is that if an account is deleted, it doesn't always get removed from the admin group's GroupMembership. What might be better is to use a combination of reading the admin group and checking to see if those accounts actually exist, and only if they are still present, add them into an array, and print the array at the end.
Example:

#!/bin/bash

admins=$(dscl . -read /Groups/admin GroupMembership | tr " " "
" | grep -v "GroupMembership:" | egrep -v "root|_sophos|_mbsetupuser|_jss|casper")

while read USER; do
    if [[ $(dscl . read /Users/$USER 2>&1>/dev/null; echo $?) == 0 ]]; then
        adminsArr+=("$USER")
    fi
done < <(printf '%s
' "$admins")

echo "<result>$(printf '%s
' "${adminsArr[@]}")</result>"

This takes the result of checking the admin GroupMembership, minus the accounts you want to exclude, and then checks to see if dscl is able to read each account record without an error. If so, it adds that account into a new array and after exiting the loop, prints that final admin array as the result.

On my own Mac, I have one or two temp accounts I had once created that I then deleted, and unfortunately these still show up in the admin GroupMembership. It likely has to do with how the accounts were deleted. I assume if they get deleted from System Preferences, it cleans up the admin group membership. If they are deleted from the command line in some ways, it may not. sysadminctl probably cleans up the membership though.

Thanks @mm2270, hopefully this will help. Are you saying you could use sysadminctl to clean up the Admin Group?

Thanks again

Joe

No, I don't think sysadminctl can be used for that. You would need to use dseditgroup instead I believe.

I suppose if cleaning up that admin group membership is really that important, you could craft a reverse type script that would check the admin GroupMembership and compare them to see if a local account exists on the Mac, and if it doesn't, remove the entry from the admin group. But that's a little risky to be honest. If the script messes up, you could end up removing valid accounts from admin and end up in a real pickle. It's probably not worth it honestly.

Should just mention that in above: dscl . -read /Groups/admin GroupMembership

is checking the LOCAL database.

It is possible - if you are using something like AD-Binding, that some users might also have admin rights via AD group memberships.
for example, as 'domain admins' or 'enterprise admins' or other AD management groups.
- So that's something else to be aware of.

@PeterClarke makes a good point, and that thought had crossed my mind. Users can get admin rights when in range of the domain controllers, if they are directory based, and groups they belong to have been added to the "Allow administration by" section, but those accounts may not actually be in the local admin group. Not sure if that's also a factor here, but certainly worth mentioning just in case.