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.

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.