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.
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:
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:
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:
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 at the end of this post is my current method to resolve this issue, the below is a walk through of what the script does, With the GitHub icon to the left taking you to the relevant section of the script on GitHub.
NOTE: The below starts in the scripts middle due to the use of a function that's declared at the top of the script.
f) If the user is an admin via dsmemberutil but not in the Mac’s local admins group it is presumed that the user is in the AD groups for admin rights. The user is then added to the Mac’s local admins group, the script will report as such re-run the function (so back to step 6).
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.
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?
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:
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.