This issue of “AD users losing Admin rights when off the Domain” is a wee head scratching moment that comes up from time to time.
Having recently updated the script I use workaround this issue, I decided it was time for a blog post.
The script, an explanation of the script & the issue itself are detailed below.
Contents
The Issue
When Directory Utilities AD plugin is configured like that shown above, all users whom are in the groups specified within the “Allow administration by:” text box are made administrators of the Mac.
Except, they are not really.
If you check the users membership whilst connected to AD using:
dsmemberutil checkmembership -U "$loggedInUser" -G admin
This will return “user is a member of the group”
Run the above again when disconnected from AD & you’ll get: “user is not a member of the group”
Now this membership can sometimes “stick”. So to test run the below, then the above again:
dsmemberutil flushcache
The “stickiness” comes from the cache, which with cache being cache is somewhat volatile & can be cleared at times.
To verify the above statement, on a Mac that when able to contact your AD is showing a user as being an Admin via the above through Directory Utilities AD plugin but not once the cache has been flushed. Run the below:
dscl . -read /Groups/admin | awk '/GroupMembership:/{for(i=2;i<=NF;i++){out=out" "$i}; print out}'
The above should return a list of users whom are Admins due to the users being a part of the Mac’s local Admin group, with the user(s) whom were showing as admins when able to contact the domain not being in that list.
UPDATE: As requested by ooshnoo in the comments, I have opened a bug report on this issue: 23438116. Updates to come.
The Script
Running The Script
The script can be ran whenever (for example, any JSS trigger when a user is logged in). But will need elevated privileges (fine when ran via the JSS as will be ran as root), & was attempted to be written in a portable way.
Obviously, test test test to make sure things work as they should for you.
The echo’d output is in an Extension Attribute format (more on that below), but amend to your requirements.
Active Extension Attribute
I saw Andrew Seago mention the idea of using an “Active” Extension Attribute (read: EA) at JNUC 2013 during his talk Planning for the Unknown: Managing the JSS, JDS, and Sites.
Passive EA (normal use case):
The idea is that as an EA is often a script, which updates it’s value in the JSS. Then often a Smart Group is scoped to that result & then a policy is run to correct/change what the EA finds. Sometimes this process is a bit of a faff.
Active EA:
Why not within the EA read the state & fact fix the issue we’re looking at whilst we looking at? This can lower the resources used by clients during Recon.
This will also run whenever a Recon is ran, so can check at multiple intervals which can be more or less than via a policy.
Why Not An Extension Attribute?
Logging
Well, as @daz_wallace pointed in the #london channel on the MacAdmins.org Slack, you cannot have an EA show as fail where a policy can report as failed.
For me, we add “Domain Users” to the admins group & have no compliance requirements for otherwise… yet.
As a way to get around this a little, the above reports back a few states as shown below:
Scoping
Also, EA’s cannot be scoped. So this EA will run across all Mac’s managed via you JSS every time a Recon is run.
If either of the above is a concern, then run as a script or edit the EA to suit you. Simples.
Removing Admin Rights
When revisiting this issue, I was trying to make something portable & resolved the issue in granting admin rights that would work offline.
If you have a script that could work in the same portable manner, that also removes rights based on AD Group Membership (including BuiltIn groups) & is not heavy on dscl calls. Then please DM me on the MacAdmins.org Slack.
Else i’ll muddle through & see if I can’t come up with something.
I’ve had a ticket open with Apple about this for almost 2 years now. Initially they said it was “by design” but then said it they fixed it with 10.9 I believe, only for it to be not fixed.
Have you worked with them on this?
Nope. AFAIK this was by design. It’s been like this since forever.
Basically, OS X needs to locally cache an AD users group membership.
Maybe I should log a bug too.
exactly. If you want to open a case I can give you my case number for them to reference.
Please do, & I will.
done. sent via PM.
I think this is by design.
Think of this scenario. User bob is a domain admin. He has access to laptops that he takes off the network. He gets fired an removed from domain admin. As long as the machines he has access to that are off network have the cached group membership he has admin access too.
So i’m 50/50 on this.
I run a very similar script to you Ben for my users. But i’m not sure if id rather manage this myself or if it should be the default setting for Apple to implement a caching of groups.
Also i’d imagine that cache would be aggressive. Many thousands of devices caching groups from the ad server might generate a lot of traffic i.e. in a school env.
Hmmm
I’m not sure it caching would be much more aggressive than the current looking up of membership when on domain.
I’m sure that this maybe by design, but an option to cache would be nice.
We now (compared to say 10.3/4 when this functionality first came in) have the ability to remote lock or wipe devices remotely, perhaps with that we can ensure that devices that are left with ex-employees are in an unusable state.
Very helpful, and an issue that happened to me twice in Yosemite