Granting one-off admin rights via LDAP group membership

The dseditgroup commands will be the way to go.

As for making sure it will only work with actual domain accounts, on my Mac when logged into my LDAP/AD account, if I run:

ls -l /dev/console

the output has a column that reads something like <DOMAIN>Domain Users

If I run the same against a local (non AD) account, it does not list it that way (obviously)

So, if you wanted to make sure you were only grabbing accounts that were actual domain accounts to elevate rights to, you could easily build a check into the script that if that test fails, exit out of the script (possibly with a jamf message to the logged in user) If it passes, continue on, get the current user account name and then plug that into the rest of the script with dseditgroup.

Finally as you said, just scope the policy to the LDAP groups you want to see it. You'd also want to make sure users have to log into Self Service with their AD accounts, which is probably the case already I'm guessing?

Interesting when I run that I get the following (with no mention of the domain):

crw------- 1 (My ID) staff 0, 0 May 16 08:32 /dev/console

2 things that might explain the difference:

1. I'm currently offsite, so I'm logged in in cached mode
2. We're currently using a 3rd party AD plugin - and the account should be acting like a mobile account.

(I say should, because there's a bug in their code)

All that said, wonder if that would account for the difference.

I was also offsite when I ran the command above and got the <DOMAIN>Domain Users column, but we are using Apple's built in Active Directory plug-in to bind our Macs. The accounts are also set up as mobile with cached credentials.
Given this, I'd say it is your 3rd party plug-in accounting for the difference. I have used products like Centrify Direct Control in the past (not sure if that's what you're using) and it creates accounts with completely different UIDs and other properties than Apple's plug-in would.

All that said, do you get any domain specific information by just reading the account with dscl like: 'dscl . read /Users/youraccount'?
For example, when I do that on my AD account, I see a row stating "OriginalNodeName" with text under it stating "/Active Directory/<DOMAIN>/domain.company.com"
Perhaps you see something as well in the output that would help you out?

i wrote something similar awhile back. in my case, i defined local admin rights based on a machine's OU membership in AD. remove the machine from the OU, and the admin rights can be revoked.

here's my ugly, but working, solution:

https://github.com/rockpapergoat/scripts/blob/master/accountmanagement/deputize.rb

if you want to get the currently logged in user via ruby, all you need is a:

require 'etc'
Etc.getlogin

also, why do you need to assign local admin rights?

i'd look at the rationale for doing so first, then determine if you need it in your environment. chances are, you can give your community what they want without granting local admin access.

Nate makes a good point.
While we currently set users up as admins, its a bit historical for us, and change is slow to come here. We've been looking long and hard at moving to an "elevated user" type scenario where we grant certain privileges to users through /etc/authorization modifications and some ACL changes. While it may never see the light of day for us, in the testing I've done and the scripts I've put together, its entirely possible to give users the rights they most commonly need without giving them FULL admin capabilities.
As many have said here, the moment you give users full admin rights including sudo privileges, all bets are off on controlling what they can do with their Macs. its trivial to figure out how to remove the management framework from their systems, or unlock any locked System Preferences you may be doing via MCX, unload launchd's that control things like Restricted Software titles and just about anything else.

I think it is because when you assign local admin rights in AD to a mobile AD account it doesn't retain admin rights off of campus. So, if a user is mobile and leaves your enterprise they become a normal account, and adding them to the local admin group fixes this issue.

You can also use python modules too to get the current logged in user, there is a plethora of ways.

>>> import getpass
>>> print getpass.getuser()
tlarkin
>>> import os
>>> os.getlogin()
'tlarkin'

There go two ways in Python

We have a number of working developers and have an established policy of handing off admin rights to our developers as their use case normally falls far outside our traditional support models.

As such, we normally allow them to update Xcode, download an install various frameworks etc - on their own.

We'd like to be able to ensure that we can add these users to a security group on the AD side, and then if they're in the group, allow them to either run a self service item, or scope a policy to ensure that on login they're added to the local admin group.

The rights being assigned locally would prevent them from being domain admins, and therefore admins on ALL boxes in the domain.

We have a number of working developers and have an established policy of handing off admin rights to our developers as their use case normally falls far outside our traditional support models. As such, we normally allow them to update Xcode, download an install various frameworks etc - on their own. We'd like to be able to ensure that we can add these users to a security group on the AD side, and then if they're in the group, allow them to either run a self service item, or scope a policy to ensure that on login they're added to the local admin group. The rights being assigned locally would prevent them from being domain admins, and therefore admins on ALL boxes in the domain.

Yup when I was a System Administrator I never managed any dev users at all. In fact, most of them didn't even have the Casper client installed on their machines. I'm not going to lock a developer out of any power tools they need to do their job, and I also always let developers know they need to manage their own back ups, and their own machines.

Really, for the most part it was a really good relationship. They were self sufficient and able to support themselves so I let them.