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

These scripts were found here or on github. You can maybe use this last method to get the current user and then use the first one to actually demote the user.

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

that's the script to demote all users not on the list. It could be significantly more elegant and... proper...

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

@palmeida . Thank you so much!. Will try this !!

We used this it worked from Sierra to Big Sur:

!/bin/bash

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

@rhooper We have a separate management account that we don't want to demote. How do I avoid this?

@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

@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)

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?

@rhooper It's a placeholder. You'd replace #### with the name of the account you don't want demoted.

@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

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.

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?

Found this years later and tailored it for our use - thanks!