Volume Number: 21 (2005)
Issue Number: 10
Column Tag: Programming

The Source Hound

Knock Knock Knocking on LDAP's Door, PART 2

by Dean Shavit

In part one of Knock, Knock, Knocking on LDAP's Door, (MacTech September, '05) I examined some of the new additions to Open Directory III such as DACs (Directory Access Controls) and Schema Replication which enabled customized LDAP directories to be replicated across networks, titillating us with the promise of an enterprise-wide structure of Organizational Units (OUs) within a single LDAP directory, which up until OS X (Tiger) Server 10.4, seemed only like a pipe dream. The benefits of OUs harkens back to the days of NetInfo directory domains in OS X Server 10.1 and 10.2 that were often deployed in hierarchies that tended to look a lot like the following diagram:

Our Own Little Corner of the Directory

It's easy to figure out why such hierarchies aren't exactly ideal; Admins at the top of the pyramid can authenticate at all levels below, but users can only authenticate to servers they log into, not to mention that having the directories linked across multiples machines only creates additional points of failure, as well as challenges when it comes to accessing resources on other servers at the same level in the hierarchy. A user in the Marketing Domain that wants to access a share in the Sales Domain wouldn't be able to without creating a cross-domain trust relationship. The advantages are on the flipside of that same coin: an Admin in the Marketing Domain would be able to manage the users accounts in that domain without the admin from the Corporate Domain having to be involved, and would only "see" user, group, and computer accounts inside that directory domain.

With Open Directory II moving to a standard based on OpenLDAP (http://www.openldap.org), what was formerly the shared NetInfo Directory Domain became the Open Directory LDAP Master, which centralized the pyramid into a large, flat Directory space with extremely limited capabilities for delegating rights to what I would call sub-Admins (but others like to call helper-monkeys), that would only have the ability to manage preferences for certain users, groups, or computer lists, not necessarily the ability to create or delete user, group and computer accounts. The unified, flat directory space of an Open Directory LDAP Master presents some challenges. First, with the potential to hold approximately 100,000 user accounts, all in one container (cn=users) at the LDAP root, simply viewing groups of users with similar attributes requires the use of keyword fields, though a large improvement over NetInfo, where ranges of UID numbers were often used to "tag" accounts with similar properties, like students all in a single graduating class. However, even with LDAP in Panther Server, a school district with an Open Directory Infrastructure could not separate out user, group, and computer accounts into different departments such as alumni, employees, or faculty, nor divide up the directory space to include any other arbitrary Organizational Units, or even separate Organizations, such as separate schools within a district that might be in different buildings, yet still connected via fiber or point-to-point T1s to a centralized Directory.

Starting with Panther Server, and persisting with Tiger Server, creating an Admin account allows for the delegation of some rights, such as the right to edit the user account preferences of specified users. Oddly enough, this arrangement allows the sub-Admin to create new accounts, but not to specify any of the attributes for those accounts (they sit in the directory with names like Untitled 1, Untitled 2, while at the same time allowing the sub-Admin to edit any of the attributes of the specified users, while also allowing sub-Admins to delete those specified accounts, which is hardly ideal or even consistent with the type of behavior an IT manager would expect from Directory Service.

The same limitations hold true for defining privileges for Groups and Computer Lists as well. As long as the sub-Admin can live with whichever methodology the super-Admin provides for identifying which accounts, groups, or computer lists they can edit (such as keywords, a naming convention, or computer lists named for a location or department), they might not mind fishing for what they have the rights to edit or modify in a heavily populated Directory. Wouldn't it be nice if the sub-Admin didn't have to wade through a morass of accounts to find what they had the rights to edit? That's where the promise of OUs makes the mouths of Mac Admins everywhere water. If each sub-Admin could only see accounts in their own OU, and have rights to create, delete and modify those accounts, and only those accounts, then essentially what they see and access is a "pocket" of the entire Directory. At the same time, if all servers in the organization are bound to that same LDAP directory, other issues, such as assigning rights to shares on servers that aren't the LDAP Master, simply disappear.

While the unified LDAP Directory has limits, it also has some big benefits like the ability to replicate the entire Directory from server to server, the ability to back up and restore the Directory in one fell swoop (made much, much easier by Tiger Server's Directory backup/restore tool). However, carving up that single, flat Directory space into OUs isn't as easy and straightforward as the theory behind it.

OU-Ouchies

The biggest stumbling block, or "OU-ouchie," as I like to call it, is the fact that Apple's Directory Services process is simply unaware of OUs or anything other than the flat, default Directory space created by promoting an OS X Server installation to the Open Directory Master role. That means that even if accounts existed in OUs within the LDAP Directory, the Directory Services process would be unaware of them. While tools like PHPLDAPAdmin (http://phpldapadmin.sourceforge.net, which I explored in part one of this series) can access and browse the entire Directory hierarchically, including OUs, Apple's Directory Services process is hard-wired into a flat way of looking at the LDAP world. Likewise, Apple's account management tool, Workgroup Manager, is also unaware of OUs, and actually loses track of accounts once they're moved out of the root of the LDAP Master. Clients accessing the LDAP directory as well would also have to be made aware of those OUs, which might interfere with some auto configuration processes, such as passing out LDAP server addresses over DHCP.

The second OU-ouchie is that even if OUs can be made to work with Directory Services and Workgroup Manager, what happens to LDAP Security? Will sub-Admins (or helper-monkeys) be restricted to the lower branches of the Directory tree, or will they be given free reign to swing wildly from branch to branch, pelting the rest of the Admins with nuts? Would the super-Admins still have control of the sub-Admins? How would LDAP Directory Access Controls (DACs) work to keep such chaos at bay? There isn't much documentation at this point in time, but maybe, if we look hard enough in the right places, we might just find enough to go on. . .

The third hurdle is that while the super-Admin might save time in the long run by turning administration of an OU over to a sub-Admin, the process of creating the OUs and the sub-Admins, as well as configuring the server and Workgroup Manager to be aware of the OUs takes a lot of extra up-front work, planning, and the implementation of other LDAP administration tools such as the (Open-Source, of course) PHPLDAPAdmin, which means that only the largest organizations, with a lot of division within the organization, would benefit from OUs.

The fourth ouchie might be a biggie, but it's one many people might want to overlook, or wish would go away: will Apple support Open Directory with OUs? It's highly unlikely, but in reality, how many server admins installed the Open-Source Spamassassin junk mail filter (http://spamassassin.apache.org) or its right-hand helper, the Open-Source ClamAV virus scanner (http://www.clamav.net), before they became supported components of Tiger Server? Or, for that matter, any other Open-Source "unofficial" component like ispell for SquirrelMail or a tricked-out PHP build with every possible option? When an IT Manager starts to talk about whether Apple supports a certain configuration, it means that they don't really have the resources, knowledge (or sometimes simply the kohones-- http://kohones.com) to do anything beyond the default Tiger Server install. The fact of the matter is that it might be a consultant like myself, or even an Apple System Engineer that will either implement the OUs or assist in their implementation, but that still doesn't mean that the person on the other end of the phone will understand when someone makes that phone call to Apple's server support line. That's the reality of the situation. Unsupported modifications aren't just enhancements or hacks, for many they are flat-out necessities for running OS X Server. Sometimes stock just isn't good enough.

Installing PHPLDAPadmin

Before creating and working with OUs, it's important to have the requisite LDAP administration tools in place. For working with OUs, I like PHPLDAPadmin, which is web-based and, because it uses PHP, virtually guarantees that any OS with a somewhat current browser would be able to use it without compatibility headaches, as all of the data preprocessing happens on the web server. This will also require a Tiger Server installation with properly functioning DNS configured as an Open Directory Master. The first part of installing PHPLDAPadmin is a snap (for those of you who read part one, this will be a repeat):

1. Download the script from phpmyadmin.sourceforge.net and unpack it

2. If you have multiple sites set up on your server already, create a new virtual domain along the lines of "ldap.mydomain.com" and install the files there, or simply place it as a subfolder of the default site like this: /Library/WebServer/Documents/LDAP/

3. Enable the php4_module in the Web (service) > settings > modules section of Server Admin as in the figure below:

4. Next, it's time to edit the config.php file for the PHPLDAPadmin. But first, it's important to make a mental note--it's OK to use an unencrypted web connection when the web-based form is running on the server it's going to be connecting to. But if you want install PHPLDAPadmin on a server then connect to an LDAP directory on a different server, then SSL needs to be configured to make sure that the administrator credentials aren't sent in clear text form over the "wire." For simplicity, we're going to use the configuration where PHPLDAPadmin is installed on the Open Directory Master itself.

5. First, navigate to the directory where you've unzipped or unpacked the PHPLDAPadmin script, locate the file called config.php.example, and make a copy, renaming it to config.php. This is the file you'll use to configure the connection and authentication to your Open Directory Server.

Open up your config.php file in your favorite text editor. These days, it's BBedit that's floating my boat. First, we have to give our configuration a name, so change the following default setting:

$servers[$i]['name'] = 'My LDAP Server'; /*  A convenient name that will appear in
                                    the tree viewer and  throughout PHPLDAPadmin to
                                    identify this LDAP server to users. */

Go ahead and enter a name between the single quotes, it's not a DNS name, just a label.

Next, we need to change the "host" setting so that the script can connect to the server:

$servers[$i]['host'] = 'mostsvr.macworkshops.com';  /*  Examples:
                                      'ldap.example.com',

Now, configure the base DN (Distinguished Name), sometimes referred to as the "Search Base." Because were going to be working with full DNs, we'll make this a blank value.

$servers[$i]['base'] = ''; /*  The base DN of your LDAP server. Leave this
                                  blank to have PHPLDAPadmin auto-detect it for you. */

Next we have to tell PHPLDAPadmin now we're gong to handle authentication. The most expedient way is to use the "session" method which relies on Apache:

$servers[$i]['auth_type'] = 'session';       /*  Three options for auth_type:

Like we did with the clearing out the base DN value, let's do the same with 'login_dn' and 'login_pass.' Go ahead and save your edits.

Now, we're ready to look at our Open Directory Master from the inside-out. Go to a web browser and type http://yourwebsiteURL/ldap. If your website was configured correctly, you should see the home page of PHPLDAPadmin.

Getting in the Back Door

OK, so now it's time to ask the Tiger Server Open Directory master to open up, say "aaaaah," and let us inside. However, you can just go to the door and say knock knock, and when the voice inside says "who's there?" answer with "admin uid=501." In Tiger Server the local admin that installed the OS has no rights to the Open Directory master. So you'll need to use the name "ldapmin uid=1000." But even that's not enough. You have to announce yourself using your full distinguished name, not just your short name and password. A DN or "Distinguished Name," is basically your "long" LDAP identity. It contains the full path to where that identity lives in the LDAP Directory, along with, of course, the password necessary to authenticate so that you may do the business admins do.

Your distinguished name (DN) would be something like:

uid=ldapmin,cn=users,dc=nagitest,dc=macworkshops,dc=com

And your password, would be, of course, your password:

******

If that seems too long, just wait, it's going to get even longer! You can, of course, choose the "Anonymous bind" option. This will let you in straightaway, but with read only access. We'll look at closing that loophole a little later on. If everything was configured copasetically, you'll see the promised land, which consists of this:

Create the OUs

Now, it's time to put in the up-front work needed to get the OUs set up, along with the proper containers for user, group and computer accounts, as well as the sub-admin accounts for each OU. For the purposes of this article, the organization in question will be a generic university with three OUs: alumni, faculty and employees. Obviously, there would be many other OUs such as undergraduates, grad students, or maybe even subdivisions within those two groups based on major: liberal arts or sciences. At any rate, this is simply for the purposes of an example. To create an OU, simply click the "gold star" at the bottom of the list of containers that says: create new record here, meaning at the root of the LDAP Directory. A window will appear with many LDAP record templates. Choose "OU," and when prompted, name the OU "alumni." Repeat the process for "faculty" and "employees."

Create the Admins

Now that the OUs are present at the root level of the Open Directory Master, we can go ahead and start planning for the next step: getting the proper container and Admin accounts into the OUs. Now it's necessary to switch back to an Apple tool: Workgroup Manager (WGM). Open up WGM and connect to the Open Directory Master, and authenticate to the /LDAPv3/127.0.0.1 directory node (click on the little blue globe) as the directory administrator account created during the process of creating the Open Directory Master. For this article, I've named the account "ldapmin," which incidentally, is the same account we just used to create our OUs in PHPLDAPadmin. I've named the accounts "facultymin," "alumnimin," and "employmin," and given them full rights to administer the LDAP Directory Domain (make a mental note of this, it's important for later. . . ), as well as rights to administer the server.

Copy the Containers

The next step is copying the sub-Admins and requisite structural containers into the OUs. PHPLDAPadmin has two ways to copy items: with children or without children. For the super-Admin (ldapmin) and the sub-Admins, we're going to use the copy with child entries option. Log into PHPLDAPadmin as the Directory Administrator, and select the "Users" container in the list on the left. In the right-hand pane, choose "copy or move this entry." In the resulting window, make sure to check the box to the right of "Recursive copy." Note that you can browse for the destination DN, but I find it much quicker just to manually insert the ou=alumni between the cn=users and dc=nagitest portions of the DN, as it saves several clicks and a couple minutes of waiting:

Repeat the process so that each of the OUs has the "Users" container and all the users inside of it. When done, go back and delete the extra sub-Admins from the OUs so that the only two users are ldapmin and the sub-Admin named for the OU. Then make sure to leave the sub-Admins (and the super-Admin of course) in the /LDAPv3/127.0.0.1 node in Workgroup Manager. Next, copy the "Computers," "Groups," and "Computer Lists" containers into the alumi OU, without the children of the object. After a while, it'll become obvious that this could get a little bit repetitive, with, say, fifty sub-Admins and OUs. Once populated with the correct containers, the alumni OU should closely resemble this:

Fake Out Directory Services and Workgroup Manager

Each OU should now contain a copy of the super-Admin as well as the proper sub-Admin. Though it might seem strange and problematic to have multiple super-Admins in the LDAP Directory, don't worry about it. If you now look in Workgroup Manager, the sub-Admins simply don't exist anymore, and queries to Directory Services don't reveal the existence of the user. An interactive query with lookupd -d should reveal if the user account is accessible:

nagitest:~/ mostadmin$ lookupd -d
lookupd version 324.9 (root 2004.11.30 01:57:54 UTC)
Enter command name, "help", or "quit" to exit
> userWithName: alumnimin
nil

Using a different tool like ldapsearch clearly reveals the existence of the alumimin account, and other LDAP tools, like PHPLDAPadmin can see it as well. However, before the account is useful, and before any user can authenticate using that account, it has to be visible to the OS X Directory Services process, which also means it'll show up in Workgroup Manager.

Fortunately, I've had some experience with LDAP integrations with foreign Directory Services like Active Directory and Netware's eDirectory. Both require custom LDAP mappings and often are implemented with multiple OUs or even O's (organizations). Therefore, it wasn't much of a stretch for me to figure that with a little tweaking and faking, it would be easy to fool Apple's Directory Services process into seeing the OUs. As a matter of fact, it's the goal to get the sub-Admin to see only the OUs, as well as the connected OS X clients that the sub-Admins manage as well.

Step One: Create Aliases for a single Directory Node

In part one, I stressed how important it was to have the DNS "Stars" aligned properly for an Open Directory Master to function properly with LDAP. Now in order to bend Directory Services to our will, it's going to be necessary to be able to have our server look at the LDAP directory as if it had multiple personality disorder. That's right, we're going to cause our Open Directory Master to have an identity crisis. Of course, it all starts with DNS. On a side note, many issues with Open Directory stem from an identity crisis caused by DNS mis-configuration, where the server doesn't know its proper FQDN (fully qualified domain name) in relation to its IP address. However, we're going to cause a controlled breakdown for a purpose. At this point it might be a good time for a gut check and to remind you, if necessary, that this probably isn't supported by Apple.

First, open up the Server Admin application on Open Directory Master or connect to it from another computer with the Server Admin tools installed. Go to the "DNS" service settings, select the DNS zone for the Server, then on the actual machine record for the server and edit it. Underneath the host name of the server there's a field called "aliases." Go ahead and add three aliases: alumni, employees, and faculty:

After saving the aliases, each should be able to resolve to the address (A) record of the server or the IP address without errors, either using the Network Utility or the dig or the host command. If all's working as it should, it's then time to complete the deception.

Step 2: Add the Multiple Personalities to Directory Access

When most Admins change the role of their server to Open Directory Master, few check the Directory Access application to see what changes were wrought. However, it should be none too surprising to find out that the LDAP Domain is connected to /LDAP/127.0.0.1 and that the authentication search path's been modified to include that directory node along with the local NetInfo domain that every OS X Server (and every OS X Client as well) has. An unlimited number of directory nodes are possible, but we're going to add the same directory node again, with a different name, and a different set of mappings. It's the nature of the "search path" that the Directory Services process uses to search through the listed directory nodes in order from top to bottom, always starting with the local NetInfo node. So, if in searching /LDAPv3/127.0.0.1 for the alumnimin user Directory Services comes up empty, it'll check the next node, which in our example will be /LDAPv3/alumni.macworkshops.com.

In the Directory Access application, (located in /Applications/Utilities), authenticate, choose the LDAPv3 service and edit it by clicking the configure button. Create a new LDAP instance using the "manual" settings, (trusted binding isn't necessary when connecting to the same machine), and choose the "Open Directory Server" set of mappings. When prompted to add a search base, enter the default search base of dc=nagitest,dc=macworkshops,dc=com, in other words, the three "Domain Components" that make up the FQDN of our LDAP Master. You might be tempted to add ou=alumni beforehand, but don't succumb. You'll see why in a moment.

Next, we need to tweak the LDAP mappings a little so they are aware of our OU. Even though the vast majority of the mappings can't be changed, especially those relating to "config" container in the LDAP Directory that contains the links to things like the Password Server and the Kerberos auto configuration property list. We do want make sure to point to those containers we moved into the OU earlier:

cn=users,ou=alumni,dc=nagitest,dc=macworkshops,dc=com

cn=groups,ou=alumni,dc=nagitest,dc=macworkshops,dc=com

cn=computers,ou=alumni,dc=nagitest,dc=macworkshops,dc=com

cn=computer lists,ou=alumni,dc=nagitest,dc=macworkshops,dc=com

Just adjusting those mappings is all we need to fool Directory Services and Workgroup Manager into thinking that alumni.macworkshops.com is a completely separate LDAP Directory, which, for all intents and purposes, it is. Notice how, after saving the changes, the type of LDAP mapping listed changes form "Open Directory Server" to "Custom." All that's left is to configure the custom search path to include the alias:

Swing from Trees, Throw Nuts

It's sub-Admin (a.k.a. helper-monkey) time! Time to find out if Workgroup Manager will, indeed, accommodate our desire to pretend to be a sub-Admin with less rights and be able to switch back and forth between these faux LDAP Directory nodes with impunity. Simply choose them from the popup menu underneath the tiny blue globe in Workgroup Manager. If the faux node doesn't appear, choose "other" and go find it in the LDAP category.

Next, you'll have to authenticate so you can modify the contents of the OU. These show up as /LDAPv3/alumni.macworkshops.com. You can do it either as the ldapmin or as one the sub-Admin (helper monkey) named for the OU that contains them. I say be the monkey, after all, that's the true test of whether OUs will be a tenable solution for delegating administrative control to certain portions of Open Directory. Go ahead, create a few users, a group, a computer list, add some computer accounts to the computer list. It all just works, right? Switch to the Alumni OU in Workgroup Manager and try to authenticate as the Faculty or Employee OU sub-Admin: you can't. Authenticate as the super-Admin to all the OUs: you can. At this point, it's tempting to crack open a beer and celebrate, but not-so-fast.

It Just "Does the Right Thing"

Network admins say this with a big something-eating grin on their face, when a task that they think would take a whole heck of a lot of work to make work, surprises them with acting just the way they would have dreamed. Remember, when I mentioned earlier on to make a mental note of the fact that there had to be a copy of the super-Admin in each OU? Well, what if you wanted to change the password of the super-Admin? In my worst fears, this would have resulted in having to touch each instance of the super-Admin account in each OU. But guess what? Open Directory just does the right thing. Because of Apple's Open Directory Password Server, where only the password ID is stored in the user account, changing the password for the super-Admin also changes it for all instances of the super Admin! Nice. Although having copies of the super-Admin in each faux-LDAP Directory is a bit of a kludge, it works well because each copy's tied to the entry in the Password Server database.

Another instance of "doing the right" thing is when you attempt to create another user account with the same UID or short name as one that exists already, is the server's refusal to comply. For example, attempting to create a duplicate user named "alum2" in the "alumni" OU results in the following error:

In this case, Workgroup Manager does "the right thing" because it has all of the OUs in its search path in Directory Access. It checks them, in order, and refuses to create a duplicate. However, sometimes, if you don't do the right thing. . .

It Just "Does the Wrong Thing"

At this point, we might think about reaching for that celebratory beer again, but not-so-fast. In the above example, the server's necessarily aware of all of the OUs and has them all in its search path. However, on a client that a sub-Admin will use to run Workgroup Manager to add/delete/modify accounts in their own OU, if they only have their own OU in the search path, creating duplicate accounts is easy. As you can imagine, having accounts with duplicate short names is not "The right thing." It is tempting to "hide" the rest of the OUs from a sub-Admin, but that is really just tempting fate: sooner or later, a duplicate short name will surface, as evidenced by the following screenshot where a sub-Admin has created an account with the same short name as another sub-admin in a different OU that's not in the search path of the sub-Admin's computer:

Likewise, it's just as easy to create an account with a duplicate UID number if WorkGroup Manager can't search all "corners" of the LDAP space. So the best (and only practice) is to make sure that all OUs are in the search path of any Mac on which you plan to run Workgroup Manager, Xserve, PowerBook, or any other. One other instance where Open Directory does the wrong thing: an LDAP configuration with OUs will not work with trusted Directory Binding, something large organizations that could leverage OUs aren't dying to implement anyway.

Remember the question about the sub-Admin being able to climb the LDAP tree and pelt other Admins, including the super-Admin with nuts? Well, that's unfortunately the case. Just because Workgroup Manager doesn't let sub-Admin authenticate to other OUs doesn't mean that other tools which are aware of LDAP OUs won't let that happen. For example, the Alumnimin sub-Admin has no problem deleting any of the super-Admin accounts or even the root account in PHPLDAPadmin. This is not the right thing. We need to keep our sub-Admins from cannibalizing each other and bumping off their super-admins. We need to control access to the OUs in our Directory. We need DACs (Directory Access Controls).

SLAPed Upside the Head

DACs aren't Digital to Analog converters, but Directory Access Controls, something Apple's Open Directory borrows from OpenLDAP a.k.a slapd. In part one, I looked that the default access controls which live at cn=Accesscontrols in the LDAP root, and which used to live in the slapd.conf file. As I mentioned in part one, there's little documentation of the new application of DACs within the LDAP directory itself. However, Joel Rennich at http://afp548.com wrote a great quick start to enhancing LDAP security with DACs and along with a few pithy example configurations of OpenLDAP DACs on Solaris 9, as well as the OpenLDAP Faq-O-Matic at http://www.openldap.org/faq, it was fairly painless to come up with a few DACs to make our helper monkey accounts behave like they should. The DACs we need to implement OUs successfully have to accomplish the following:

1. Stopping sub-Admins from deleting or modifying the contents of other OUs.

2. Preventing sub-Admins from deleting or modifying the super-Admin accounts.

3. Make sure everything else can work.

Let's take a look at the default access controls, which live at the following distinguished name: "cn=default,cn=accesscontrols,dc=nagitest,dc=macworkshops,dc=com." . Like many of the enhancements in Open Directory, the access controls are a standard component of, but have been relocated to the interior of the LDAP space in an attribute called apple-acl-entry. There are four default entries which are (please note that the backslashes indicate line breaks) numbered, much like firewall (IPFW) rules:

1000:access to attr=userPassword by self write by 
sockurl="ldapi://%2Fvar%2Frun%2Fldapi"\
write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=nagitest,dc=macworkshops,dc=com"\
 write by * read

This DAC allows a user to change their password when it's stored inside the user record, also referred to as a "Crypt" or "Basic" password depending on the version of OS X Server. It's not recommended that anyone use such a password, as it's less secure. However, network users running OS X 10.0 through 10.1.5 must use Crypt passwords. I'd rather upgrade those clients that allow Crypt passwords.

1100:access to attr=apple-user-authenticationhint by self write by sockurl=\
"ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,\
dc=nagitest,dc=macworkshops,dc=com" write by * read

DAC 1100 allows users to change their password hint, but it's not a good idea to implement this, as password hints help hackers guess the password. After all, if you're forgetful to the point you need a password hint, it'll probably be enough to help someone else remember as well!

1200:access to attr=apple-user-picture by self write by sockurl=\
"ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid="cn=admin,cn=groups,\
dc=nagitest,dc=macworkshops,dc=com" write by * read

Users can change their picture. OS X has no facility to do so anyway, so it requires a customized solution. On an interesting side note, the pictures are actually stored as binary jpeg data in OpenLDAP, so if you use 'em, stick with low res.

1999:access to * by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by\
group/posixGroup/memberUid="cn=admin,cn=groups,dc=nagitest,dc=macworkshops,dc=com" write by * read

DAC 1999 is very important: this is the rule that allows members of the admin group to be able to add/modify/delete any object across the entire LDAP Directory, including all of the OUs. This is the rule (or loophole) that the sub-Admins are using to rain terror on other admins from the high and low-hanging branches of the LDAP tree. After many hours of experimentation with DACs, I've come to several conclusions:

1. Backup everything before you start, DACs take effect immediately, and locking yourself out of LDAP isn't hard at all.

2. Realize that cooking up DACs is an art form not many people have mastered, and that there's certainly a better or more efficient way to implement them. For example, DACs support regular expressions, but it's not completely obvious how they work, as many of the folks attempting to document them have noted.

3. The DACs take effect from the "top down," from lowest number to highest, and can easily cancel each other out, so you might need to formulate them in "matched yin=and-yang pairs."

4. Don't edit DACs with PHPLDAPadmin, the text fields aren't big enough, use the "Inspector" feature of Workgroup Manager, enabled in the Preferences menu which can stretch to fill the screen, and try not to save until everything's "just" right. Once false move will have you starting from scratch. Remove entries by highlighting them and tapping the "delete" key.

5. When adding entries to the default list of access controls, choose the "add new value" option, not the "add new attribute" option.

Before I reveal the access controls that kept the sub and super Admins from tearing each other limb from limb, I should also mention that I needed to create a special group in cn=users,dc=nagitest,dc=macworkshops,dc=com called "superadmin," in which I put ldapmin, my uid 1000 Directory Administrator and root account and a facultymins, alumins, and employmins group for each of the sub-admins in the OUs so that I could apply the access controls. However, I will admit that I think there's probably a more efficient way, I just couldn't figure one out. So, with no further adieu, here' my list of access controls for Open Directory with OUs and sub-Admins:

Controls 1000-1200 are unchanged.

1992:access to dn.subtree="uid=ldapmin,cn=users,dc=nagitest,dc=macworkshops,dc=com" by\
sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by\
group/posixGroup/memberUid="cn=superadmin,cn=groups,dc=nagitest,\
dc=macworkshops,dc=com" write by * read

This DAC basically allows the members of the "superadmin" group to modify the ldapmin (Directory Administrator UID 1000) account. Ldapmin is the only member of that group, and everyone else has read access to everything else.

1993:access to dn.subtree="uid=ldapmin,cn=users,dc=nagitest,dc=macworkshops,dc=com" by\
sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write 
by\ group/posixGroup/memberUid="cn=admin,cn=groups,dc=nagitest,\
dc=macworkshops,dc=com" read by * read

Conversely, this DAC restricts members of the admin group (which all the sub-admins are necessarily members of) from editing the ldapmin account, and everyone else has read access to everything else.

1994:access to 
dn.subtree="uid=ldapmin,cn=users,ou=alumni,dc=nagitest,dc=macworkshops,dc=com" 
by\ sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by\ 
group/posixGroup/memberUid="cn=superadmin,cn=groups,ou=alumni,dc=nagitest,\
dc=macworkshops,dc=com" write by * read

This DAC basically allows the members of the "superadmin" group to modify the ldapmin (Directory Administrator UID 1000) account for each instance of it appearing alongside the sub-admins in the OUs. Modify and duplicate this DAC for each OU in your LDAP Directory, and, of course, everyone else has read access to everything else.

1996:access to 
dn.subtree="ou=alumni,dc=nagitest,dc=macworkshops,dc=com" by\ 
sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by group/posixGroup/memberUid=\
"cn=alumins,cn=groups,ou=alumni,dc=nagitest,dc=macworkshops,dc=com" 
write read by group/posixGroup/memberUid=\
"cn=facultymins,cn=groups,ou=faculty,dc=nagitest,dc=macworkshops,dc=com" 
read by group/posixGroup/memberUid=\
"cn=alumins,cn=groups,ou=alumni,dc=nagitest,dc=macworkshops,dc=com" 
write by group/posixGroup/memberUid=\
"cn=employmins,cn=groups,ou=employees,dc=nagitest,dc=macworkshops,dc=com" read by * read

This DAC should be created for each OU and for each sub-admins group that resides in side of it to allow them to write to that OU. All other groups have read only access, and everyone has read access to everything else.

1999:access to * by sockurl="ldapi://%2Fvar%2Frun%2Fldapi" 
write by group/posixGroup/memberUid="cn=admin,cn=groups,dc=nagitest,dc=macworkshops,dc=com" 
write by * read

This DAC is unchanged from the default set. It allows the admin group to write to anything in the Directory that wasn't specifically made read-only by a previous DAC. And, of course, everyone has read access to everything else. Just a quick note on that--everyone else includes the right to read data anonymously, so if you're security-conscious, do take a moment to check out Joel Rennich's article at http://afp548.com to learn how you can secure your LDAP Directory from anonymous and unauthenticated access.

Tiger Balm

While Tiger Server seems to be somewhat ready for an LDAP Directory with a few wrinkles (or stripes), our OU-ouchies aren't completely healed, just scabbed over. Implementing OUs takes a lot of up-front work, duplicate admin accounts, DACs, and a fair of amount of planning and testing before such a configuration can see the light of a production deployment, and though I remained titillated by the possibility of more complex LDAP hierarchies and delegation of account maintenance, it seems that Apple Directory Services and authentication infrastructure require a bit of wrangling to do what other UNIX systems already can do with OpenLDAP, but that's really a by-product of Apple's overriding goal of making a complex and powerful Directory Service as easy as pie. Some times ease of use is at odds with versatility. Such is life.

In Next Month's Source Hound

Bonjour is fun fun fun. . .except for the name. Every time I say it I have visions of Pepe LePew sticking his head out of a doorway and exclaiming, "Bonjour, mon amour, embrasse-moi." Of course it's great to be able to tap into our iTunes libraries without having to remember an IP address around the office, or even ssh into our web server. . .but what happens when we leave the office? I am going to take a look at running multicast DNS (a.k.a Bonjour) over the Internet; I hope I don't go .local on everyone!

Dean Shavit is an ACSA (Apple Certified System Administrator) who loves to use a Mac, but hates paying for software. So each month he's on the hunt for the best Open-Source and freeware solutions for OS X. Besides surfing for hours, following the scent of great source code, he's a partner at MOST Training & Consulting in Chicago, where he trains system administrators in OS X and OS X Server, facilitates Mac upgrade projects for customers, and writes for his own website, www.themachelpdesk.com. Recently, he became the surprised father of an application: Mac HelpMate, available at www.machelpmate.com. If you have questions or comments you can contact him: dean@macworkshops.com.