Volume Number: 22 (2006)
Issue Number: 11
Column Tag: Mac In The Shell

Directory Service Recipes

More Directory Services manipulation via the Command Line

by Edward Marczak

Directory Services: used every day by users of OS X - whether they know it or not. Last month, this column covered the basics of directory services, and gave a few sample ideas. This month, I'll trot out some very practical uses of the command-line directory service tools.

As I've alluded to in the past, command-line tools and scripting - shell based or GUI based AppleScript - can be much more powerful than GUI tools. Also, while I pointed out that LDAP is not a database, people still tend to think of it as one. The confusion is understandable: Directory Services protocols allow you to retrieve information via lookups. Depending on the protocol and your access, it may allow you to be the one to store information, too. Like any database, the retrieval of information is key: it would be useless if you could put information into the store without being able to access it. Combined with scripting, not only can we access data, but we can perform actions using the results.

Let's start out with reading and reporting on values. OS X Server using Open Directory stores just about everything for a given user in a record in LDAP. Sometimes, you'll want to know which users have some attribute. I do a lot of work with OS X e-mail systems, and a common request is an easy way to report on which users have mail enabled (or, conversely, which users are not mail enabled). Here's a handy little script that will do just that - show which users are set up for OS X e-mail:

#!/bin/sh
for user in $(dscl /LDAPv3/127.0.0.1 -list /Users)
do
        me=$(dscl /LDAPv3/127.0.0.1 -read /Users/$user MailAttribute)
        if [ "$me" !=  "No such key: MailAttribute"  ]; then
                echo "$user"
        fi
done

Do notice here that we're relying on the failure to find the attribute as a way to make our determination. If you want to find users who do not have mail enabled, just change the test from not equal ("!=") to equal ("=="). If you're a Kerio Mail Server user, and are using the Open Directory extensions, rather than "MailAttribute", you want to look for "kerio-Mail-Active: 1". Run this right on your OD master or replica to get your results. This can be extended to run from cron every night and produce a report via e-mail. You could even redirect the results to a file and use diff to report on new mail users, and users that have been disabled.

Let's even go easier, but potentially more useful. Hierarchies on a network are useful. People tend to think in that manner, and like to press them into service. If you're using OD based logins, with or without network home directories, you have a handy tool at your disposal: your user list. More than once, I've been asked to create a sharepoint on the network, and then fill it with a directory for each user in the system. On a large system, this could be incredibly tedious. So, you script it. Or, in this case, you can even one-line it:

dscl /LDAPv3/127.0.0.1/ -list /Users | xargs mkdir

Of course, that will create directories at your current place in the structure. This means that you'll want to cd to the location you want them before running this command.

While handy, you probably need a little bit more, like setting the correct permissions, or even copying some default information into each folder. An easy framework for that is:

#!/bin/bash
dscl /LDAPv3/127.0.0.1/ -list /Users | while read user
do
  #Do your work here
done

Quick results from little work!

Another really handy scenario crops up with OS X 10.4 in an all OD network. Using a tool like Apple Remote Desktop, you can certainly create local admin users on all machines in your network very easily. However, that can become a small management headache: If you want to change the password for the admin user, then you have to remember to get every box. It also doesn't allow for any fine-grained control. One great solution to this is to create admin groups in OpenDirectory. You can then nest these groups inside of the local NetInfo admin group. From there, simply moving users in and out of the OD admin groups will give them the correct permissions on a given machine. Let's look at an example.

Imagine that a company (or school) has two open labs: one for word processing/presentation development, and another for 3-D graphics. Each lab has a local support team that need admin rights to the Macs. You would create three groups in OpenDirectory: WPLabAdmins, 3DLabAdmins, and UberAdmins - the final group being able to administer both labs. Assign users to the appropriate groups. You'll then need the OD group's UUID, which of course can be scripted. Create the script as update-admin-group.sh:

#!/bin/bash
theUUID=$(dscl /Search -read /Groups/$1 apple-generateduid | sed 's/apple-generateduid: //g')
dscl /NetInfo/root -create /Groups/admin NestedGroups $theUUID

Then, run it on each group of machines as appropriate:

On all machines:

update-admin-group.sh UberAdmins

On the word processing machines:

update-admin-group.sh WPLabAdmins

Finally, on the 3D machines:

update-admin-group.sh 3DLabAdmins

Now, as people need admin access to a given machine, they can simply use their own OD ID. Very, very cool. Once this is set, you can just move people in and out of OD groups, rather than futz with anything on any local machine. Much better, right?

dscl: incredibly useful. However, I'd be remiss if I didn't mention its counterpart that appeared in 10.4: dseditgroup. dseditgroup appeared to make it easier to work with groups, especially with the new ability to have nested groups.

By default, dseditgroup operates on NetInfo data, but, as the 'ds' suggests, will work with any Directory Service plug-in. This includes anything you can set up in Directory Utility, such as LDAP and Active Directory. So, while we're speaking about admin accounts, let's see examples of dseditgroup in action.

To read all information about a NetInfo group, simply use dseditgroup groupname. So, to see your admin group:

# dseditgroup admin
Recordname <admin>
10 attribute(s) found
Attribute[1] is <dsAttrTypeStandard:AppleMetaNodeLocation>
        Value[1] is </NetInfo/DefaultLocalNode>
Attribute[2] is <dsAttrTypeStandard:RecordType>
        Value[1] is <dsRecTypeStandard:Groups>
Attribute[3] is <dsAttrTypeStandard:RecordName>
        Value[1] is <admin>
Attribute[4] is <dsAttrTypeStandard:PrimaryGroupID>
        Value[1] is <80>
Attribute[5] is <dsAttrTypeStandard:Password>
        Value[1] is <*>
Attribute[6] is <dsAttrTypeStandard:GroupMembership>
        Value[1] is <root>
        Value[2] is <localadmin>
Attribute[7] is <dsAttrTypeStandard:GeneratedUID>
        Value[1] is <ABCEEFAB-CDEF-ABCD-ECAB-CDEF00000050>
Attribute[8] is <dsAttrTypeStandard:SMBSID>
        Value[1] is <S-1-5-32-544>
Attribute[9] is <dsAttrTypeStandard:RealName>
        Value[1] is <Administrators>
Attribute[10] is <dsAttrTypeStandard:GroupMembers>
        Value[1] is <43C93B6A-CFB9-4C24-A464-EA51320B62D2>
        Value[2] is <F047F2F1-F5A9-4B73-BBB4-454550B09CB4>

The same thing can be accomplished for an OD group, using the -n switch:

# dseditgroup -n /LDAPv3/127.0.0.1 admin

dseditgroup also has operations to manipulate groups, either local (NetInfo), or other datastore. To remove a user from an OD admin group, you could handle it this way:

dseditgroup -o edit -n /LDAPv3/127.0.0.1 -u admin-user -p -d user-to-delete -t user admin

Note that sensitive operations against Directory Services will require authentication, as seen here with the -u and -p flag.

Directory services in general are an incredibly powerful way to maintain a central store for objects on a network, easing administration. The usefulness of these services wouldn't be diminished if only GUI tools were available. I do hope, though, that I've illustrated how powerful scripting and command-line tools can be, and what they bring to the process.

Media of the month: Michael Bartosh's posthumously released Mac OS X Tiger Administration. A surprise follow-up to his Panther Server Administration after being told that the Tiger version was cancelled. This PDF-only version of the book was started by Michael, and completed by several of his good friends after Michael passed away. It's available from <http://www.orielly.com>.

Again, it's time to make your plans for MacWorld! Hope to see people on the show floor, or at either of the sessions I'll be presenting (old news to long-time readers of my column, though!). In any case, I'll see you in print next month.

dscl man page

dseditgroup man page

Ed Marczak owns and operates Radiotope, a technology consulting practice with a focus on business process enhancement, network and system integration, and, more generally, all things Mac.