Create Script to have the first AD user to become local admin on Mac 10.8.4 with Casper.

[deezkidz]

We current have a Windows script that will be placed on a re-image and it will be the last script we run. This script then will create a local admin account for the next AD user who logs in first. I have found several options to create AD local admins, but my fear is that when these laptops are off-site they will no longer have local admin privileges. I have looked at the following forums/discussions and each script I found has not been successful. My goal is to have a similar script to do the same for Mountain Lion.

https://jamfnation.jamfsoftware.com/discussion.html?id=4338

https://jamfnation.jamfsoftware.com/discussion.html?id=1528

Would appropriate any help you can give!

Thanks in advance!

[Matt]

I have a script posted that uses AD groups. First login though, I could probably fool around with something but it won't be until this weekend.

[deezkidz]

Thanks for the Fast response. And at this point anything would help. Groups in AD would not be ideal because we do not want everyone in a particular AD group to be able to log on and have admin rights. Something along the lines of running a script for one user, one time, to create local admin rights for that user.

[milesleacy]

I haven't used this one in a while, but try this in a script run by a policy triggered at login...

dseditgroup -o edit -n /Local/Default -a $3 -t user admin

I hope this helps!

[tlarkin]

Hey Everyone,

I marked this page last week to respond to it, and am just now getting around to it. So, sorry for my delayed response. This is what I have done in the past however to accomplish something similar.

Scope a script to run on desired machines, trigger is login, frequency is once per a computer. I used dscl to detect if the UID was greater than 1,000, which by default in OS X, any LDAP account will have a UID of greater than 1,000.

So, I used this mechanism with awk

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

From this I could build a list or array of users, and then do a for loop and use the same code Miles posted above to add the user to the group. I also used Self Service to have users promote themselves, and only scope that policy to users who were in a proper security group in AD that allowed them to be local admins. So, there are many ways to do it.

I hope this helps.

Thanks,
Tom

[deezkidz]

Thank you very much for the feed back Everyone!

tlarkin,

So what you are suggesting is to give admin rights through AD and then have the user promote themselves to a local admins? This way if they were off the domain "say at home" they would still retain local admin rights?

Thanks,

Pete

[tlarkin]

Hi Deezkidz,

Yes, that is correct. However, the first time they log in and promote themselves they would have to be connected to your LDAP server. Basically, it worked like this:

1) User logs in with their AD account and is connected to LDAP
2) User launches self service, and authenticates with AD credentials
3) A policy that runs a script to permanently add their AD account to the local admin group can be triggered, scoped to an AD group that is allowed to be local admins
4) Script runs, adds them to the local admin group, and now they can have admin rights when off site.

The caveat is, if they are all remote workers, they would have to at some point in time hit your LDAP server for this to work. Then you can let the right users on demand, just promote themselves to local admin, and once it is added to the local admin group they are admins off site.

I hope this helps,
Tom

[mm2270]

@deezkids, if this part of your post above still holds true:

Something along the lines of running a script for one user, one time, to create local admin rights for that user.

There are many ways to accomplish this, and the above solutions are all good ones, but here's how I would do it personally.
Since, as Tom Larkin mentions, all Active Directory accounts use a UID in the 1000 and up range, you can use a script set to login that can detect the just logged in accounts UID and, if its an AD account, next check the admin status of that account, If its not an admin, it can make it one.
Using a line in the script to touch a file (essentially similar to a dummy receipt) in conjunction with an Extension Attribute you can ensure that the policy would continue to stay active at every login until it runs once successfully, then not run again.

The script to run with a login trigger, set to Ongoing:

#!/bin/sh

##  Promote the first (and ONLY first) Active Directory user that logs in to local admin status

loggedInUID=$( id -u "$3" )

if [[ "$loggedInUID" -ge 1000 ]]; then
    echo "User $3 is an Active Directory account. Checking admin status..."
    isAdmin=$( /usr/sbin/dseditgroup -o checkmember -m $3 admin 1> /dev/null; echo $? )
    if [[ "$isAdmin" -gt 0 ]]; then
        echo "$3 is not an admin. Promoting to local admin..."
        /usr/sbin/dseditgroup -o edit -a $3 -t user admin
        if [[ "$?" == 0 ]]; then
            echo "$3" > /private/var/ADlocalAdminSet
            exit 0
        else
            echo "Operation not successful"
            exit 1
        fi
    else
        echo "$3 is already an admin. Exiting..."
        exit 0
    fi
else
    echo "$3 is not an Active Directory account. Exiting..."
    exit 0
fi

Create an Extension Attribute with this script. Call it something like "AD Local Admin Account Set"

#!/bin/sh

if [ -e /private/var/ADlocalAdminSet ]; then
    echo "<result>Yes</result>"
else
    echo "<result>No</result>"
fi

With the above in place, you can build a Smart Group for any Macs that don't have this EA reporting as Yes. So in other words,criteria would be:

AD Local Admin Account Set  |   Is   |   No

With that group in place, assign that to the Scope of a policy that runs the first script above with a login trigger set to an Ongoing frequency. Once a Mac runs it successfully, the script should be creating the "ADlocalAdminSet" file that the Extension Attribute is looking for, which will drop the Mac out of the above Smart Group, ensuring it won't run again at next login.
An important aspect of the policy will be to do an Inventory Collection at the end so the EA gets updated.

For bonus points, you can create another EA that cats the ADlocalAdminSet file into the result so you can see which user account got set as a local admin account at first login. That might be useful if you start to see machines with more than one local admin account on them and need to know which one was set that way by your policy as opposed to the user promoting one manually.

Hope the above helps. I should note I didn't really test any of the above, so you'll need to verify that I set everything up correctly.