AD users losing Admin rights when off the Domain

Standard

Screenshot 2015-11-04 08.36.04

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:

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 Solution

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.

github-icon1. Checks that the Mac is bound to AD, if not will report as such & exit.

github-icon2. Try & grab the username of the logged in user.

github-icon3. If nothing returned for the above, then no user is logged in at time of script execution. uThe script will then report as such & exit.

github-icon4. Will get the logged in Users UniqueID. If an AD account this is normally over 1,000, if the value is less then will report as such & exit.

github-icon5. Will check to see if the user is authenticated to AD, if not will report as such & exit.

github-icon6. Next the scripts main function will do the following:

github-icona) Grab the membership of the Mac’s local admin group.

github-iconb) dsmemberutil cache is flushed (due to the “sticky” issue mentioned above).

github-iconc) dsmemberutil is called again to see if the user is an Admin, this will come back true if the user is an admin via AD groups or the Mac’s local admins group.

github-icond) If the users is an admin, then the local admins group membership is checked.

github-icone) If the user is in the Mac’s local admins group, then the script will report as such & exit.

github-iconf)  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).

github-icong) If the user is not & admin as shown via dsmemberutil, & is not in the Mac’s local admins group, then the script will report as such & exit.

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:

Screenshot 2015-11-04 22.20.04

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.

8 thoughts on “AD users losing Admin rights when off the Domain

  1. 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?

  2. Calum Hunter

    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.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.