Posted on 11-19-2020 07:44 PM
Hello All,
I am very new to Jamf pro. Getting trained on it. I am looking for a policy or configuration profile which can demote the local admin user/ account to a standard one. We do not have AD. Everything controlled by Jamf pro
Any help would be much appreciated!!!
Thanks!!
Posted on 11-20-2020 06:05 AM
In short it's something like
dseditgroup -o edit -d $user -t user admin
where $user is the target username
To demote all users found which are not the users we care about we use
#!/bin/sh
adminUsers=$(dscl . -read Groups/admin GroupMembership | cut -c 18-)
for user in $adminUsers
do
if [ "$user" != "root" ] && [ "$user" != "####" ] && [ "$user" != "jamfadmin" ] && [ "$user" != "####" ]
then
dseditgroup -o edit -d $user -t user admin
if [ $? = 0 ]; then echo "Removed user $user from admin group"; fi
else
echo "Admin user $user left alone"
fi
done
hastags are other admin accounts we use.
we this next one to make the current user an admin
U=`who |grep console| awk '{print $1}'`
# give current logged user admin rights
/usr/sbin/dseditgroup -o edit -a $U -t user admin
EDIT
For clarity, as I was definitely not clear, a short breakdown:
get a list of users in the admin group and store them in variable adminUsers (I like plural variable names for lists)
adminUsers=$(dscl . -read Groups/admin GroupMembership | cut -c 18-)
take the items in the adminUsers variable, do the following operation on each individually. We will refer to each item as the variable user when we do the individual operations
for user in $adminUsers
first we will check if any of the following are true or false using the 'if' and the brackets [].
This line says something like: if (if) it is true that (brackets [ ) the single item from the variable adminUsers that, for this operation, is now stored in the variable user ("$user") is not equal to (!=) the word 'root' ("root" ] )... only if that past statement was true and (&&) it is true that (brackets [ ) that same item stored in variable users ("$user") is not equal to (!=) the word '####' ("####" ] )...etc.
if [ "$user" != "root" ] && [ "$user" != "####" ] && [ "$user" != "jamfadmin" ] && [ "$user" != "####" ]
then
then
remove that same user that is not any of the ones we checked above from the admin group
dseditgroup -o edit -d $user -t user admin
check if the dseditgroup command above worked by checking the exit code which can always be found with "$?". An exit code of 0 means all is well, so we check for that, and if it IS 0, then we say (echo) "Removed user 'name of users we are doing operation on' from admin group". Semicolons can be said to operate as if they were a new line here. 'fi' is the inverse of 'if' and punctuates the 'if' statement.
if [ $? = 0 ]; then echo "Removed user $user from admin group"; fi
otherwise (in reference to whether the user we are checking for does not match users in the first 'if' check. It's a double negative, so we are now going to be handling the case of when a user DOES match that list.)
else
say "Admin user 'the user we are doing this operation on' left alone"
echo "Admin user $user left alone"
end the if statement
fi
end the 'do' statement
done
to alter rights of the user "who is currently signed in" (not exactly) at the time the script is run.
get the current user by extracting it from the information in the 'who' command and store it in the U variable.
U=`who |grep console| awk '{print $1}'`
add that user to the admin group
/usr/sbin/dseditgroup -o edit -a $U -t user admin
OR, you may want to demote the user to a standard user, in which case, this will remove them from the admin group
dseditgroup -o edit -d $user -t user admin
QA
Why do some commands include the full path and some do not, such as /usr/sbin/dseditgroup?
I copied and put together parts of scripts that were useful from the work of others and my own ideas. I am under the impression that full path is a matter of reliability across environments but haven't seen issues in my small environment that I could recognize as being related to this. Could be, though...
AQ
Posted on 11-20-2020 09:03 AM
@palmeida . Thank you so much!. Will try this !!
Posted on 11-24-2020 10:26 AM
We used this it worked from Sierra to Big Sur:
localAccts=$(dscl . list /Users UniqueID | awk '$2>500{print $1}' | grep -v localadmin)
while read account; do
echo "Making sure $account is not in the local admin group"
dseditgroup -o edit -d $account admin
done < <(echo "$localAccts")
exit 0
Posted on 01-11-2021 06:18 AM
@rhooper We have a separate management account that we don't want to demote. How do I avoid this?
Posted on 01-11-2021 06:25 AM
@valentin.peralta We to have this issue. I have not been able to exclude this account as of yet. I tried to only the local admin account (student 500) but sometimes the hidden management account grabs 500. I thought maybe by excluding the specific account in the policy scope would work but have not been able to test that.
I would very much like to hear what others have done to exclude the management account, hidden or otherwise.
Sorry I could not help more
Posted on 01-11-2021 06:54 AM
@valentin.peralta @rhooper The script@palmeida posted above should do what you want. Just edit the if [ "$user" != "root" ] && [ "$user" != "####" ] && [ "$user" != "jamfadmin" ] && [ "$user" != "####" ]
line to include the accounts you want to keep as admin (add/remove extra [ "$user" != "####" ]
as necessary)
Posted on 01-11-2021 07:03 AM
Sorry all for my ignorance, scripting is not my strong point at all! In fact I would rather have a root canal. Can anyone decipher what all this means and where I would place the hidden Admin account? "$user" != "jamfadmin" would that be our hidden account? What does the "$user" != "####" translate too?
Posted on 01-11-2021 07:35 AM
@rhooper It's a placeholder. You'd replace ####
with the name of the account you don't want demoted.
Posted on 01-15-2021 03:50 AM
@palmeida That command works great. Thank you!
For the next question, is there a script that we can run that will allow System Preferences not be grayed out based on the user?
Restrictions are enabled using a configuration profile. I was thinking maybe use the Exclusions list and list the account that we do not want restricted. We have not much luck doing it this way though.
Thanks all
Posted on 01-28-2021 10:41 AM
Perhaps that's a question related to scoping. It sounds like you're trying to limit the config profile that disables the Preferences panel to only certain users.
If jamf had the data on those users, like department, and I could make smart groups based on those department names (contains 'IT', for example), I would use smart groups and scope those profiles to those groups.
If jamf did NOT have the data I wanted to use, I would make a static group and add those people to it and then scope my profile to that group.
If I can't avoid using the exclusion list, I try to avoid adding individuals to the exclusion list. I like to add groups to it because the groups can be descriptive of their purpose. I also find it easier to manage scope through group membership.
Just be mindful that smart groups are all re-computed at every inventory collection, and so many devices and many smart groups could bog down your jamf instance.
Posted on 07-19-2021 06:20 PM
the script seems to break if the user name has a space in it. it thinks its 2 users in the for loop. does anyone know how to fix this?
Posted on 12-20-2023 10:08 AM
Found this years later and tailored it for our use - thanks!