A few tips here:

1 - $1 will only return the current user, as a log in hook ran by the Apple tools, ie the loginwindow.plist

2 - If you have Casper run the script as a login script, use $3, this only works for self service and login policies. Scripts that run while in the user environment or at the login window itself, cannot use this method.

Try changing the one to a $3 and then test, test, test before you deploy.

Hi there,

I had a similar dilemma with Xcode. The high school is running an iOS programming class in one of the general use computer labs, so we only wanted to give developer access to students in that class. What we're doing is running the following script as a login hook scoped to that lab's smart group. We decided to use AD groups to manage this access so that all we needed to do was add a student who joined the class to that group to let them build software in Xcode.

Might not be exactly what you're looking for, but hopefully it helps!

#!/bin/sh



# Who is the currently logged in user?

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



# Do this only if the user is a member of StudentDevelopers_grp in AD. If so, nest AD group in local _developer group if not already done.



if [[ `id "$user" | grep -c "StudentDevelopers_grp"` == 1 ]]

then



    # Check if AD dev group is nested in local dev group.

    if [[ `id "$user" | grep -c "_developer"` == 1 ]]

    then

    echo "The StudentDevelopers_grp AD group is already nested in the local _developer group."

    else

    dseditgroup -o edit -a "DOMAINStudentDevelopers_grp" -t group -n . _developer

    fi



fi

We run this script with casper policy scoped to the computers that are used for programming to run once per user at login. We used to run it ongoing which was fine as well.

#! /bin/sh

loginUsername="$3"

dseditgroup -o edit -a $3 -t user _developer

exit 0

This is what I ended up using,

#!/bin/bash

#### This script will add the current user to the _developer group.

#### Only needed with users using xcode.

#### Wi11 Pierce 

#### January 9, 2012



username=$3



dscl . append /Groups/_developer GroupMembership $username



exit 0

I think I still need to test it.
W-

You really should be using dseditgroup for this sort of thing:

/usr/sbin/dseditgroup -o edit -a $username -t user _developer

or

/usr/sbin/dseditgroup -o edit -a everyone -t group _developer

Which just punts and effectively makes all users members of the _developer group.

Hey Everyone,

I was just browsing through JAMF Nation just now and saw this thread. I thought I would just chime in and add a tid-bit of information. If you add the "everyone" group it will mean any user account that connects to your system, even a remote one that doesn't have a physical account on your computer. If you grant access to the "staff" group that will include all users that have actual accounts on that computer. So, there is a slight difference as far as I know.

Does this matter in the grand scale of security? I would probably defer to security experts on that. However, if your computers have the guest account enabled, the guest account is in the everyone group if I recall. Been a while since I got down into the security side of Unix groups so I could be a bit off, but if memory serves I think that is what you need to consider.

If you add the "everyone" group it will mean any user account that connects to your system, even a remote one that doesn't have a physical account on your computer.

If by this you mean a Network account, yes, you are right. In my case, that is exactly want since all of our users have network accounts.

If you grant access to the "staff" group that will include all users that have actual accounts on that computer.

Only if they are members of the staff group. This is the normal default, but it is possible to have "local" users who are not members of staff. In my org, mobile accounts (which are cached copies of network accounts) have "actual" accounts on a computer, but are not members of the "staff" group.

Of course you must always understand what you are doing and make choices appropriate to your organization. Typing commands at the command line without understanding what they do can often later bite you in the rear.

Yeah I just checked

my test AD account, which is mobile, and cached to my Mac

id testad

uid=1191215538(testad) gid=578301937 groups=578301937,402(com.apple.sharepoint.group.1),403(com.apple.sharepoint.group.2),12(everyone),62(netaccounts)

my local account I use on my work machine (which is admin):

$ id tlarkin

uid=501(tlarkin) gid=20(staff) groups=20(staff),402(com.apple.sharepoint.group.1),403(com.apple.sharepoint.group.2),401(com.apple.access_screensharing),104(com.apple.access_ssh),12(everyone),33(_appstore),61(localaccounts),79(_appserverusr),80(admin),81(_appserveradm),98(_lpadmin),100(_lpoperator),204(_developer)

If I enable the guest account:

$ id guest

uid=201(Guest) gid=201(_guest) groups=201(_guest),402(com.apple.sharepoint.group.1),403(com.apple.sharepoint.group.2),12(everyone),61(localaccounts)

For some reason I thought cached AD/OD/Network accounts also were members of the staff group. Though the guest account is a member of everyone. I did notice since Lion came out some under the hood directory services stuff did change.

FYI - adding people to the _developer group won't do anything unless you enable devtoolssecurity;

DevToolsSecurity -enable

You'll be able to launch the Simulators etc. but you won't be able to launch them from a project build - it will throw a message asking you to enable developer mode and request admin rights (pointless if you're a student).