Granting one-off admin rights via LDAP group membership

[Mbentley777]

Folks,

I was thinking that it might be interesting to try to assign admin rights to directory users via Self Service if the SSI item availability was controlled via an LDAP group.

It would let us apply an external process to control a local provisioning of admin access.

Assuming that the LDAP group was visible and I scoped the policy, that just leaves me with the small matter of adding the user to the group.

Would I just be best off using the scripts for dsgroupedit? http://managingosx.wordpress.com/2010/01/14/add-a-user-to-the-admin-group-via-command-line-3-0/ and then simply set the script as a login script using the $3 variable for the user name?

I guess where I'm confused is that I just want to be sure that I only enable as an admin the user that installed the self service admin item.

I'd appreciate any and all feedback on this!

[mm2270]

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?

[Mbentley777]

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.

[mm2270]

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?

[tlarkin · Accepted solution]

Hey Matt,

There are many ways to detect the current user that is logged in from the command line, here are some examples I have used in the past.

If you run the policy as a login trigger in Casper and you have login hooks enabled, the $3 will return the current user. This only works for login and logout scripts.

If you use Apple's built in login hooks $1 will return the current user, if you use Casper's login hooks it will overwrite the Apple ones.

You can detect ownership of /dev/console

ls -l /dev/console | awk '{ print $3 }'

You can use directory services to build a list of local users or AD mobile accounts by getting a list based on UID range. Examples:

all local and network user accounts (ie actual user accounts that are visible)

dscl . list /Users UniqueID | awk '$2 > 500 { print $1 }'

local user accounts only that are actual users

dscl . list /Users UniqueID | awk '$2 > 500 && $2 < 1000 { print $1}

List of Network/AD/OD accounts only

dscl . list /Users UniqueID | awk '$2 > 1000 { print $1 }'

Many of these methods can be used to pass the current user, or a list of users in a command to the dseditgroup to add group membership.

I hope this helps,
Tom

[rockpapergoat]

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

[rockpapergoat]

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.

[mm2270]

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.

[tlarkin]

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

[Mbentley777]

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.

[tlarkin]

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.