By arfore | Published: October 21, 2009
One of the standard methods of configuring Mac OS X in the enterprise has become known as the magic triangle or golden triangle. This is generally described as a setup involving Active Directory (AD) for authentication of the clients and services and Open Directory (OD) for managing the client preferences. The triangle comes from the fact that you have the Mac clients talking to AD, the clients also talking to OD, and the Mac server talking to AD. (Apple officially calls this the magic triangle setup in the Snow Leopard Server Open Directory Administration documentation.)
One of the issues I ran into was granting a non-admin in AD the ability to perform administrative functions on the clients bound to AD. The way this is handled with the Windows clients is for the particular AD user to be a member of a group that grants local administrator privileges.
Unfortunately there is no simple equivalent on the OD side of the equation to allow this for the technicians working on the Mac OS X clients. If you add an AD user to the system level group Open Directory Administrators using Workgroup Manager (WGM) this has no effect on whether a user is granted local administrator privileges to a connected client machine.
The solution to this involves:
- creating a group in OD to hold the members of AD that should have local administrative privileges,
- adding this OD group to the requisite local workstation groups to mimic the standard administrative privileges, and
- adding the OD group to the sudoers file
Step 1: Creating the OD group
Anyone who uses WGM to manager OD users and groups will have no trouble with this step at all. It is a simple matter of creating the new group in WGM and assigning the appropriate membership. Make sure that you are editing the correct directory in WGM, it should be something similar to
/LDAPv3/127.0.0.1
The only real decision to make during this step is whether to include individual AD users or to nest an AD group inside the OD group. Nested groups can sometimes be tricky to handle correctly, but with some care this shouldn’t be an issue. I chose to use a nested AD group, since I am not the AD Group Policy manager, and I didn’t want to be constantly updating the OD group memberships.
Step 2: Adding the OD group to local admins
This is where the fun part begins. It might seem fairly straightforward to handle this step, however without some investigation you may find your work incomplete and your technicians (as well as yourself) frustrated. If your think about this logically you would come to the conclusion that you just need to add the OD group as a member of the local admin group. While this is correct, it is only partially correct.
The first thing you should do is to use the id command to determine the default memberships of a local admin on the client. When I ran this command on my workstation I got the following result:
it04984:~ arfore$ id support
uid=501(support) gid=20(staff) groups=20(staff),98(_lpadmin) 81(_appserveradm),79(_appserverusr),80(admin)
As you can see from the text above, I was logged in as the user arfore but I was investigating the membership of the local administrative account named support. What is interesting about the result is that a standard administrative level account is a member of four groups that perform administrative functions.
The basic administrative functions, such as installing applications and changing most of the systems level preferences can be performed by any member of the group admin. There are other functions that require membership in the other three groups, however, such as:
- adding or removing a printer
- pausing or deleting a print job
- configuring WebObjects directories and apps for deployment
If you don’t use WebObjects or develop WebObjects applications using XCode, then you are safe to ignore the following two group memberships:
- appserveradm
- appserverusr
In order to add your OD group to the admin and lpadmin groups, you need to execute the following two commands:
dseditgroup -u LOCAL_ADMIN_SHORT -p -o edit -a OD_GROUP_SHORT -t group -n /Local/Default admin
dseditgroup -u LOCAL_ADMIN_SHORT -p -o edit -a OD_GROUP_SHORT -t group -n /Local/Default lpadmin
When using these command replace LOCAL_ADMIN_SHORT with the shortname of the local administrator account and OD_GROUP_SHORT with the shortname of the OD group. You will be prompted for the password of the local administrator account when running the commands.
What these commands are doing is to edit the group membership of the admin or lpadmin groups in the local directory node to add the membership of the OD group. If you only want to add a single OD user to the local administrator groups, say for instance an augmented user, then do the following commands:
dseditgroup -u LOCAL_ADMIN_SHORT -p -o edit -a OD_USER_SHORT -t user -n /Local/Default admin
dseditgroup -u LOCAL_ADMIN_SHORT -p -o edit -a OD_USER_SHORT -t user -n /Local/Default lpadmin
The only changes made were to substitute the shortname of the OD user and to change the type of record being added to be a user instead of a group.
One of the side effects of this process is that the local groups will be converted to GUID format.
Step 3: Adding the OD group to the sudoers file
If you work with the command line on a regular basis, or even a semi-frequent basis, you will have no doubt run into an occasion to use the sudo or su commands. The sudo command lets you execute operations as the super-user, or root. In Mac OS X the root user account is not enabled for login by default, however there are many times that it is useful to have super-user privileges, such as when you need to create an nsmb.conf file to get around the problem with smb connections to a Windows-DFS share. The su command allows to become another user, or to substitute their identity for yours. This can be useful when working as the root user for any extended period of time.
While adding your OD group to the local administrator groups will suffice for almost anything that is executed through the Finder or the other various GUI applications, the command line utilities of sudo and su don’t understand nested groups.
This is easily fixable by using an existing local administrator account and editing the file
/etc/sudoers
There are two methods for editing this file:
- using the visudo command, which is expressly design for this purporse
- using a standard text editor and the sudo command
Regardless of which method you use, the necessary change is as follows
- open the file in the editor
- find the section labeled
# Uncomment to allow people in group wheel to run all commands - add a line similar to the following underneath it
%stafflocaladmins ALL=(ALL) ALL - save the file
What this does is to allow any user of the client that is a member of the group “stafflocaladmins” to perform operations requiring the sudo or su commands.
Afterword
The end result of these operations will be a setup that allows for the technicians to perform the necessary administrative functions when on-site without opening up the local users permissions beyond an acceptable point.
These techniques can also be combined with changes to the /etc/authorization file to allow a user to change the timezone or the screensaver, even add a printer or change the region code on the DVD drive. For more on the authorization file check out the article at AFP548.com for more on this file and how to use it.