Admin rights being removed when @ home

[ImAMacGuy]

We grant admin rights via a script / policy that runs this script...

#!/bin/bash
#
# this script will promote all local users to the admin group
#
for i in `/bin/ls /Users | /usr/bin/grep -v "^Shared"` ; do
/usr/bin/dscl . append /Groups/admin GroupMembership $i
/bin/echo "done"
done
#
# now to test what we did
local_accounts=`/bin/ls /Users | /usr/bin/grep -v "^Shared"`
check_admin=`/usr/bin/dscl . read /Groups/admin GroupMembership | /usr/bin/grep "$i" -c`
#
# now run a loop to check our work
#
for i in $local_accounts ; do

if [ $check_admin -eq 1 ]
   then /bin/echo "$i is an admin account"
   else /bin/echo "$i is not an admin account"  
fi
done
exit 0

what we are finding is that if a user goes home or anywhere not on teh corporate network, they loose their admin rights. It's been like this for a while, just now getting around to looking at it.

[bentoms]

On your directory binding, do you have "allow administration by" set to a group?

If you're using this method then when your not able to contact the domain the users in that group will not be admins.

I'm thinking that maybe the domain groups are working & the script isn't.

[mm2270]

Do not use dscl . append. Its been well documented in many articles and here on JAMFNation that the better and safer method is to use dseditgroup to add a user into the local admin group. seriously, don't use append. It creates a mess in the local directory node that you'll be kicking yourself over later if you need to clean it up.

The other issue I see is that the line:
check_admin=/usr/bin/dscl . read /Groups/admin GroupMembership | /usr/bin/grep "$i" -c
doesn't make sense to me, and probably not to the script either, since you already exited your for i in loop up above with "done" So how does the script know what "$i" is referring to at that point?

Try something like this instead-

#!/bin/sh

for i in $(/bin/ls /Users | /usr/bin/grep -v "^Shared"); do
    if [[ $(/usr/sbin/dseditgroup -o checkmember -m "$i" admin 1> /dev/null; echo $?) != "0" ]];  then
    echo "User $i is not an admin. Making them local admin..."
    /usr/sbin/dseditgroup -o edit -a "$i" -t user admin
        if [ "$?" == "0" ]; then
            echo "User $i is now an admin"
        else
            echo "User $i not made into local admin"
        fi
    else
        echo "User $i is already an admin"
    fi
done

[stlukesgrammar]

Hi there.

Here's a quick script which I use for our school-owned laptops. We allow local admin for staff, but not students on the school-owned machines. This script checks that the user is a staff member before adding them in,

I've got this script running at login, and haven't had any problems since implementing it..

#!/bin/sh

currentUser=$3
echo User = $currentUser

#Check if the user is already listed as a local admin
alreadyAdmin=`dseditgroup -o read -T group admin | grep -c $currentUser` 
echo $currentUser admin status = $alreadyAdmin 

#Get the user group memberships from dscl
groups=`dscl /Active Directory/**YOUR_DOMAIN_HERE**/All Domains -read /Users/$currentUser | awk '/^dsAttrTypeNative:memberOf:/,/^dsAttrTypeNative:ms.../'`

#Check for membership to the group you want to grant admin access to. 
#For us, we replace <groupName> with "All Staff"
isStaff=`echo $groups | grep -c "<groupName>"` 
echo $currentUser staff membership status = $isStaff 

#If they are staff, and not already admin, add them
if [ $alreadyAdmin != 1 ] && [ $isStaff != 0 ] then
        echo Adding $currentUser to local admin group
        dseditgroup -o edit -a $currentUser -t user admin 
fi
exit 0

HTH

[asditsupport]

Hi
I'm trying to make the current user an admin user. The script to make all non admins admin works (thanks for that mm2270) but I would like to make a script run only for the current user also. I have tried using commands from different posts and also "tried" different variations of the above posted one by mm2270 but no luck.
Thanks in advance

[asditsupport]

Ok, I figured it out!

curUser=ls -l /dev/console | cut -d " " -f 4
sudo /usr/sbin/dseditgroup -o edit -a $curUser -t user admin

I can't take credit for this as I have got bits and pieces of info from all across the forum. If there is any other/simpler way, please do tell :-)

[emily]

Sorry to resurrect something old, but is there any reason that a managed profile would have its admin rights randomly revoked, even if the machine doesn't leave the domain? It's been happening to my machine, and I'm wondering if it's happening to my users as well (but they don't know yet).

If the rights are revoked, do they get re-established once back on the domain?

[scottb]

@emilykausalik, In OS X 10.9.x, I've seen random loss of admin rights as well. I could not find any connection to the changes and luckily, I've not had clients complain about it yet...

[EliasG]

!/bin/sh

dscl . append /Groups/admin GroupMembership $3

We had the same issue and ran the script above. Now users have admin rights at home or anywhere as well.

[emily]

@boettchs Have you seen the admin access restored at any point, or do you have to manually re-add admin rights and reboot every time?

[scottb]

@emilykausalik][/url: it comes back as mysteriously as it goes. That's the frustrating thing. FWIW, these accounts (as far as I have seen) are all Active Directory accounts, not local. And it doesn't happen in 10.7.x and 10.8.x.

[emily]

Pretty much all of our users are on 10.9.x. I haven't heard any complaints but it's been happening to me this week… two times today. Very irritating. @boettchs

[mm2270]

Not sure if its related, but we've seen a not insignificant amount of cases of AD user accounts go literally MIA inside Directory Services on our 10.9.x Macs. The issue is spotted when a user can unlock their FV2 encrypted Mac, but then gets stopped at the username & password login fields and can't get past it with their credentials. Logging in with a local admin account and either peeking in Directory Utility or running dscl commands reveals that while the users home folder is there, their account is not.
We then need to go through a multi step process of recreating their cached mobile account and fixing things so they can log in.
While this hasn't happened on LOTS of our Macs, its happened often enough that it has me concerned there are some serious bugs with the AD plug-in in 10.9.
And just to clarify. we've seen this happen if a Mac isn't used for a long time and falls out of domain trust and others that are used literally every day and still have a proper bind with AD. I originally thought this only happened if the Mac fell off the domain, but that's not the case.

[scottb]

We don't use FVII yet, but see the same things. The Macs were not in an "archive" OU nor were they disabled. AD accounts and Macs all good and used daily. It would literally turn on and off during a session too. As long as a user isn't in need of admin rights at the moment it occurs, we don't hear about it. Luckily, Casper offering software in Self Service has some of that covered (they're all admins) so they might be going out and downloading/installing things less often. I had to stop worrying about it as I seemed to be the only one seeing and sweating it, but that's because I'm testing the Macs/images for hours on end daily.

[ooshnoo]

Just to chime in here, I've had a ticket open with Apple Enterprise Support regarding this for over a year and a half. They originally said it was "by design" as a security feature, but I got our tech rep to push it through to engineering as a feature request...which they agreed to do in the release of Mavericks.

I tested many beta versions of Mavericks and running through may different scenarios, and guess what...they did fix it!!!

However then came time to rollout Mavericks starting with 10.9.2 and boom..the issue reappeared and I have since re-opened the ticket and it's now back to "waiting on engineering" status.

What the hold up is now, I have no idea...

[ImAMacGuy]

Posted: 2/3/14 at 4:01 AM by Aruja Ok, I figured it out! curUser=ls -l /dev/console | cut -d " " -f 4 sudo /usr/sbin/dseditgroup -o edit -a $curUser -t user admin I can't take credit for this as I have got bits and pieces of info from all across the forum. If there is any other/simpler way, please do tell :-)

So, theoretically, I can add this policy and make it available offline (theoretically) that will allow it to run when off the network?