Manage Groups In Mavericks Server

There are a number of ways to create groups in OS X Mavericks Server (Server 3). The first is using the Server app, the second is using Workgroup Manager (which could be running on an older operating system and connecting to the Mavericks Server in question), the third is using the Users & Groups System Preference pane and the fourth is using the command line. In this article we will look at creating groups in the Server app. Once a server has been an Open Directory Master all user and group accounts created will be in the Local Network Group when created in Server app. Before that, all user and group objects are stored locally when created in Server app. Once promoted to an Open Directory server, local groups must be created in Workgroup Manager, the Users & Groups System Preference pane or using a command line tool appropriate for group management.
 To create a new group, open the Server app and then click on Groups in the ACCOUNTS list of the Server app sidebar. From here, you can switch between the various directory domains accessible to the server using the drop-down list available. Click on the plus sign to create a local network group.
Screen Shot 2013-10-05 at 8.40.26 PM
At the New Group screen, provide a name for the group in the Full Name field. This can have spaces. Then create a short name for the group in the Group Name field. This should not have spaces.
Screen Shot 2013-10-05 at 8.41.54 PM
Click Done when you have supplied the appropriate information and the group is created. Once done, double-click on the group to see more options.
Screen Shot 2013-10-05 at 8.47.05 PM
Here, use the plus sign (“+”) to add members to the group or highlight members and use the minus sign (“-“) to remove users from the group. You can also choose to use the following options:
  • Give this group a shared folder: Creates a shared directory for the group, or a group with an ACL that grants all group members access.
  • Make group members Messages buddies: Adds each group member to each other group members buddy list in the Messages client.
  • Enable group mailing list: Enables a list using the short name of the group where all members receive emails to that address.
  • Create Group Wiki: Opens the Wiki interface for creating a wiki for the group.
  • Keywords: Keywords/tags to help locate users.
  • Notes: Notes about users.
Once changes have been made, click Done to commit the changes.

Making Every User an Admin

If you deploy a large number of computers to users who are somewhat likely to play practical jokes on each other then you will run into some interesting issues. If you are deploying one computer to every user and you want each user to be an administrator of their computer then you might be tempted to allow all users to be administrators of all computers. If you do then prepare for an infinite number of sometimes amusing practical jokes. But really, being proactive about this brings up an interesting point: how do you deploy a computer and make only the user who you want to be an administrator an administrator. In a large deployment of Mac OS X, you are going to likely have a map somewhere between what user has each computer. You may even go so far as to name the computers the same name that you name the user associated with the computer. If you do this, then you have a pretty straight-forward task ahead of you. Basically, you’ll add the user who you are handing the computer to an administrator by adding them to the admin group. In order to do so, can check the “Allow user to administer this computer” as you can see in the following figure. If you have a sizable deployment you’ll want to automate this task rather than log in as each user and set the setting. You can automate the task using the dscl command along with the append verb. For example to place the user cedge into the admin group:
sudo dscl . append /Groups/admin GroupMembership cedge
That works as a one-off operation but not in bulk. If your computer name is the same as the user who will be using the system you can then use the scutil command and “–get” the ComputerName:
scutil –get ComputerName
NOTE: The –get options in this article are two hyphens rather than one, WordPress just merges them for some reason… You can then use this as the variable to use for augmenting the GroupMembership for admin:
sudo dscl . append /Groups/admin GroupMembership `scutil —get ComputerName`
Pop that into a post-flight package and you’ve got yourself a solution where you make the primary user of a system the admin of the local box and then make the subsequent users standard accounts. If your ComputerName doesn’t match your user name then all is not lost. One way to grab what admin user you’d like for each host would be to populate something on the client with that information. Another would be to put it in a csv and read the line for the csv that is associated to the computer in to obtain it. If you populate something on the client it could be the Text1 field from Apple Remote Desktop. This can be done using the Remote Management option in the Sharing System Preference, clicking on Computer Settings and then typing the data into the Info 1: field. To insert the information at image time (or at least programmatically), you could use defaults to write it into, located in /Library/Preferences:
defaults write /Library/Preferences/ Text1 “cedge”
To then read that variable:
defaults read /Library/Preferences/ Text1
The command to set the admin user based on the Text1 field would then be:
sudo dscl . append /Groups/admin GroupMembership `defaults read /Library/Preferences/ Text1`
There are probably about as many other ways to go about this as there are Mac OS X mass deployments. For example, instead of inserting data into Text1 from a defaults command, you could use kickstart with the -computerinfo option to write data into -set1 -1 or something like that (which is likely safer than defaults, albeit more difficult if you decide to do it to your non-booted volume). But hopefully these options, somewhere down the road, will help someone (after all, that’s why we post this kind of thing, right?!?!).

More Group Management with dseditgroup

Now that we’ve covered using dscl to create a group, let’s look at using dseditgroup to do the same thing. In the previous example we created a group called Local Admins or ladmins for short. First let’s read that group’s information. To do so, run dseditgroup followed by the operation, which can be read, create, delete, edit or checkmember as the operations (verbs). The -o is optional, so :
dseditgroup -o read ladmins
Or the following has the same output:
dseditgroup read ladmins
In the case of a namespace collision between two ladmins in two directory services then the one listed highest in the Search Policy would be displayed. The
dseditgroup create -n /Local/Default -r “Local Admins2” ladmins2
Now read the group you just created and you’ll notice that it has a GeneratedUID and a PrimaryGroupID even though one was not specified. Let’s say you wanted to manually assign the PrimaryGroupID so you could hide a group; you could do so with a -i parameter and not that many want to you could also use the -g option to manually provide a GeneratedUID. Other parameters include -u and -P for placing the username and password into the command (ie – if you’re creating groups in LDAP), -a if you want to use the group name as a parameter rather than just trail the command with it, -n to define the Directory Domain node (ie – /LDAPv3/MYDOMAIN vs. /Local/Default vs. /var/Hidden), if you wanted to place keywords or comments then use the -k or -c respectively and encase them in doublequotes (“). I’m not in love with how you edit memberships, but here goes:
dseditgroup -o edit -n /Local/Default -a cedge -t user ladmins
In the above command we defined the node we were editing with the -n followed by the user we were adding to the group with the -a and then the -t for the type of object we’re adding into the group, which is listed last. The reason that you have to put the -t with user in there is because we could just as easily have said:
dseditgroup -o edit -n /Local/Default -a staff -t group ladmins
Which would have put a group called staff into the ladmins group (noted by the NestedGroups attribute). To verify membership, use the checkmember verb (insert witty Beavis and Butthead remark here;). If su’d the following command is likely to report back with the fact that no, root has not been added to the group; otherwise it will look at your currently logged in account:
dseditgroup -o checkmember ladmins
But you can check and see whether my account is a member of your ladmins group with the -m parameter on the command:
dseditgroup -o checkmember -m cedge ladmins
Now finally, since no one likes a messy Marvin, to delete our test group:
dseditgroup -o delete -n /LDAPv3/ -u myusername -P
mypassword extragroup
dseditgroup -o delete -n /Local/Default ladmins2

Create Groups Using dscl

The directory services command line (dscl) command can be used to create a group. Here we’re going to use dscl to create a group called Local Admins (or ldadmins for short).  First up, create the group:
dscl . create /Groups/ladmins
Now give our ladmins group the full name by creating the name key:
dscl . create /Groups/ladmins RealName “Local Admins”
Now to give the group a password:
dscl . create /Groups/ladmins passwd “*”
Now let’s give the group a Group ID:
dscl . create /Groups/ladmins gid 400
That wasn’t so hard, but our group doesn’t have any users.
dscl . create /Groups/ladmins GroupMembership localadmin
Why create a group with just one member though… We can’t use the create verb again, with dscl or we’ll overwrite the existing contents of the GroupMembership field, so we’re going to use append instead:
dscl . append /Groups/ladmins GroupMembership 2ndlocaladmin
If you use dscl to read the group:
dscl . read /Groups/ladmins
You’ll notice that because it was created through dscl it has a Generated ID of its own.  You can easily nest other groups into this one using their Generated IDs as well:
dscl . create /Groups/ladmins GroupMembers 94B6B550-5369-4028-87A8-0ABAB01AE396
The “.” that we’ve been using has been interchangeable (in this case) with /Local/Default. Now let’s look at making a little shell script to do a few of the steps to use with imaging, touch a file called createladmins.bash and then give it the following contents:
dscl . create /Groups/ladmins dscl . create /Groups/ladmins RealName “Local Admins” dscl . create /Groups/ladmins passwd “*” dscl . create /Groups/ladmins gid 400 dscl . create /Groups/ladmins GroupMembership localadmin dscl . append /Groups/ladmins GroupMembership 2ndlocaladmin
If you then want to hide these admins, check out my cheat sheet here:

Snow Leopard Eats dirt (7 ate 9)

Once upon a time there was a very nice little application called dirt. Snow Leopard ate him. Or maybe more to the point it was dscl who ate him… Either way he’s gone. Now, use the -authonly option in dscl if you’d like to test password validity. Goodbye dirt, we will remember ya’ fondly!

Mac OS X: Managed Preferences without Open Directory

Yes, you can apply an MCX against a local account easily using the -mcximport and -mcxexport dscl extensions.  Simply setup the MCX like you want it for a managed account using Workgroup Manager and then from the interactive dscl environment do a -mcxexport <Path to account> -o <filename> and then copy the file to a target system.  Then, on the target system, do a -mcximport <path to account> -o <path to same filename>. Then test!  Happy policy making!