Allow user to administer this computers keeps toggling on/off + AD Joined computer

[cfritzy]

I am using the Jamf bind to Active Directory and we are adding "Domain Users" group as a group that can administer the Mac for now. I am noticing the check box to "Allow user to administer this computer" keeps toggling off/on for users. I did see it before we started using Jamf but wanted to inquire if anyone has seen this happening regularly as well and if so, any fixes? I am sure it is a OS X bug/issue but just wanted to ping everyone here. Thanks in advance

[cfritzy]

To note, I have enabled the "Mobile account" option when binding/logging on for first time.

[rhs615]

We have this issue only when our Macs can't talk to our Domain controllers. When on campus, the LDAP lookup can see if theyre in the admin group and allow them to administer the computer. What we have to do is log on as the user, cache the creds, turn off the network (aka remove it from campus / kill communication with your DC), and then log in as the user. Unlock the preference pane with a local admin account, and then check the Administrator checkbox for the user. This will allow user to remain admin regardless of communication with the DCs.

[nkalister]

this is expected behavior. If you're granting admin rights via an AD group, the rights will only be granted when the machine can talk to the AD domain.
If you want to have the admin rights survive while disconnected, you'll want to add the AD account to the local admin group using DSCL or DSEDIT in a script. If you're ok with doing this manually on each machine,rhs615's post will work, too

[cfritzy]

I am sure there are some examples of the decl or dsedit script but anything handy anyone can provide? Thanks for the info. This is good to know.

[nessts]

dscl . -append Groups/admin GroupMembership username
or dseditgroup -o edit -a username admin

[cfritzy]

Last clarification on this, do you have to use individual AD usernames or can you use a domain group via this method?

[nessts]

AD groups will not resolve when not connected to the network. so you would be right back to where you started.

[cfritzy]

Thank you all. I'll start testing it out.

[mm2270]

Get current user account's short name:

loggedInUser=$( ls -l /dev/console | awk '{ print $3 }' )

or

loggedInUser=$( who | awk '/console/{ print $1 }' )

Checking a user's admin status:

/usr/sbin/dseditgroup -o checkmember -m $loggedInUser admin
Example Result: yes, johndoe is a member of admin

Making a user a member of the local admin group:

sudo /usr/sbin/dseditgroup -o edit -a $loggedInUser -t user admin

You can also build a process that would loop through all locally cached accounts on the Mac, for example, anything in /Users/ and make them all members of the local admin group. Look around here on JAMFNation to find some examples of looping through all local accounts.

[mscottblake]

@mm2270: Am I reading this correctly? Does this script add to the local admin group based on whether it is given admin from the domain?

If so, that is far more elegant than my current solution.

[mm2270]

@msblake, No, that's not what I was saying. The line checking admin status above is just checking if the account is already part of the local admin group. It could also return a "no" response, at which time you could run the next line in a script to make them part of the local machine's admin group.
Though I'm guessing there is likely a way to check a user's AD group status and determine if they should be made a local admin on the Mac. That seems doable, but would require the Mac be in sight of the domain controllers to work of course.

[MacRae]

I have had the same issue a few times. (Allow User to Administer this Computer button toggles on and off) However, mine have nearly always been resolved by repairing permissions on the Mac.