TweetFollow Us on Twitter

Knock Knock Knocking on LDAP's Door, PART 2

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

Figure 1. Darwin Ports' PortBase Graphical installer and Updater

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 (, 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.

Figure 2. Delegation of Privileges to Sub-Admins in Workgroup Manager.

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.


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 (, 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 ( or its right-hand helper, the Open-Source ClamAV virus scanner (, 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-- 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 and unpack it

2. If you have multiple sites set up on your server already, create a new virtual domain along the lines of "" 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:

Figure 3. Activate php4_module

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.

Figure 4. Copying Config File.

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'] = '';  /*  Examples:

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:


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:

Figure 5. Successful Login to the LDAP Server

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."

Figure 6. Create LDAP object from template.

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/ 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.

Figure 7. Create the sub-Admins.

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:

Figure 8. Copy Users to OU (with children).

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/ 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:

Figure 9. OU with Admins and containers.

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

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:

Figure 10. Added Aliases to the DNS Configuration.

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/ 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/ for the alumnimin user Directory Services comes up empty, it'll check the next node, which in our example will be /LDAPv3/

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.

Figure 11. Adding an LDAP Node Using an Alias.

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:

Figure 12. Adding Custom Mapping for Containers in the OU.




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 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:

Figure 13. Custom Search Path with "Phony" LDAP Directory Nodes.

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.

Figure 14. Popup List of Available Directory Nodes.

Next, you'll have to authenticate so you can modify the contents of the OU. These show up as /LDAPv3/ 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:

Figure 15. No Duplicates Allowed!

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:

Figure 16. Doing Just About "The Worst Possible Thing."

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 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, 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 
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.

Figure 17. Editing the DACs with the Inspector.

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\
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 
by\ sockurl="ldapi://%2Fvar%2Frun%2Fldapi" write by\ 
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=\
write read by group/posixGroup/memberUid=\
read by group/posixGroup/memberUid=\
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 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, Recently, he became the surprised father of an application: Mac HelpMate, available at If you have questions or comments you can contact him:


Community Search:
MacTech Search:

Software Updates via MacUpdate

MacFamilyTree 8.2.7 - Create and explore...
MacFamilyTree gives genealogy a facelift: modern, interactive, convenient and fast. Explore your family tree and your family history in a way generations of chroniclers before you would have loved.... Read more
WhatsApp 0.2.8000 - Desktop client for W...
WhatsApp is the desktop client for WhatsApp Messenger, a cross-platform mobile messaging app which allows you to exchange messages without having to pay for SMS. WhatsApp Messenger is available for... Read more
TotalFinder 1.10.7 - Adds tabs, hotkeys,...
TotalFinder is a universally acclaimed navigational companion for your Mac. Enhance your Mac's Finder with features so smart and convenient, you won't believe you ever lived without them. Features... Read more
Box Sync 4.0.7886 - Online synchronizati...
Box Sync gives you a hard-drive in the Cloud for online storage. Note: You must first sign up to use Box. What if the files you need are on your laptop -- but you're on the road with your iPhone? No... Read more
Espresso 5.1 - Powerful HTML, XML, CSS,...
Note from the developer: For the new Espresso, we changed our versioning and licensing approach with more consistent pricing and a simpler development timeline: "X+1". Each new update would increase... Read more
VueScan 9.6.04 - Scanner software with a...
VueScan is a scanning program that works with most high-quality flatbed and film scanners to produce scans that have excellent color fidelity and color balance. VueScan is easy to use, and has... Read more
Slack 3.0.5 - Collaborative communicatio...
Slack is a collaborative communication app that simplifies real-time messaging, archiving, and search for modern working teams. Version 3.0.5: Bug Fixes: An important security update. Security... Read more
VirtualBox 5.2.6 - x86 virtualization so...
VirtualBox is a family of powerful x86 virtualization products for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers... Read more
Vivaldi 1.13.1008.40 - An advanced brows...
Vivaldi is a browser for our friends. In 1994, two programmers started working on a web browser. Our idea was to make a really fast browser, capable of running on limited hardware, keeping in mind... Read more
WhatRoute 2.1.1 - Geographically trace o...
WhatRoute is designed to find the names of all the routers an IP packet passes through on its way from your Mac to a destination host. It also measures the round-trip time from your Mac to the router... Read more

Latest Forum Discussions

See All

JYDGE (Games)
JYDGE 1.0.0 Device: iOS Universal Category: Games Price: $4.99, Version: 1.0.0 (iTunes) Description: Build your JYDGE. Enter Edenbyrg. Get out alive. JYDGE is a lawful but awful roguehate top-down shooter where you get to build your... | Read more »
Tako Bubble guide - Tips and Tricks to S...
Tako Bubble is a pretty simple and fun puzzler, but the game can get downright devious with its puzzle design. If you insist on not paying for the game and want to manage your lives appropriately, check out these tips so you can avoid getting... | Read more »
Everything about Hero Academy 2 - The co...
It's fair to say we've spent a good deal of time on Hero Academy 2. So much so, that we think we're probably in a really good place to give you some advice about how to get the most out of the game. And in this guide, that's exactly what you're... | Read more »
Everything about Hero Academy 2: Part 3...
In the third part of our Hero Academy 2 guide we're going to take a look at the different modes you can play in the game. We'll explain what you need to do in each of them, and tell you why it's important that you do. [Read more] | Read more »
Everything about Hero Academy 2: Part 2...
In this second part of our guide to Hero Academy 2, we're going to have a look at the different card types that you're going to be using in the game. We'll split them up into different sections too, to make sure you're getting the most information... | Read more »
Everything about Hero Academy 2: Part 1...
So you've started playing Hero Academy 2, and you're feeling a little bit lost. Don't worry, we've got your back. So we've come up with a series of guides that are going to help you get to grips with everything that's going on in the game. [Read... | Read more »
What mobile gaming can learn from the Ni...
While Nintendo might not have had things all its own way since it began developing for mobile, one thing it has got right is the release of the Switch. After the disappointment of the WiiU, which I still can't really explain, the Switch felt a... | Read more »
Programmer of Sonic The Hedgehog launche...
Japanese programmer Yuji Naka is best known for leading the team that created the original Sonic The Hedgehog. He’s moved on from the speedy blue hero since then, launching his own company based in Tokyo – Prope Games. Legend of Coin is the... | Read more »
Why doesn't mobile gaming have its...
The Overwatch League is a pretty big deal. It's an attempt to really push eSports into the mainstream, by turning them into, well, regular sports. But slightly less sweaty. It's a lavish affair with teams from all around the world, and more... | Read more »
Give Webzen’s new billiard game PoolTime...
Best known for producing hugely popular MMO titles, South Korean publisher Webzen is now taking aim at a different genre altogether. PoolTime is a realistic eight ball pool simulator, allowing you to compete in real-time matches against players... | Read more »

Price Scanner via

9.7-inch 2017 WiFi iPads on sale starting at...
B&H Photo has 9.7″ 2017 WiFi #Apple #iPads on sale for $30 off MSRP for a limited time. Shipping is free, and pay sales tax in NY & NJ only: – 32GB iPad WiFi: $299, $30 off – 128GB iPad WiFi... Read more
Wednesday deal: 13″ MacBook Pros for $100-$15...
B&H Photo has 13″ #Apple #MacBook Pros on sale for up to $100-$150 off MSRP. Shipping is free, and B&H charges sales tax for NY & NJ residents only: – 13-inch 2.3GHz/128GB Space Gray... Read more
Apple now offering Certified Refurbished 2017...
Apple has Certified Refurbished 9.7″ WiFi iPads available for $50-$80 off the cost of new models. An Apple one-year warranty is included with each iPad, and shipping is free: – 9″ 32GB WiFi iPad: $... Read more
10″ iPad Pros on sale for $50-$75 off MSRP, n...
B&H Photo has 10″ and #Apple #iPad Pros on sale for up to $75 off MSRP. Shipping is free, and B&H charges sales tax in NY & NJ only. Note that some sale prices are restricted to certain... Read more
Apple refurbished Mac minis available startin...
Apple has restocked Certified Refurbished Mac minis starting at $419. Apple’s one-year warranty is included with each mini, and shipping is free: – 1.4GHz Mac mini: $419 $80 off MSRP – 2.6GHz Mac... Read more
Amazon offers Silver 13″ Apple MacBook Pros f...
Amazon has new Silver 2017 13″ #Apple #MacBook Pros on sale today for up to $150 off MSRP, each including free shipping: – 13″ 2.3GHz/128GB Silver MacBook Pro (MPXR2LL/A): $1199.99 $100 off MSRP – 13... Read more
Sale: 12″ 1.3GHz MacBooks on sale for $1499,...
B&H Photo has Space Gray and Rose Gold 12″ 1.3GHz #Apple MacBooks on sale for $100 off MSRP. Shipping is free, and B&H charges sales tax for NY & NJ residents only: – 12″ 1.3GHz Space... Read more
Apple offers Certified Refurbished 2017 iMacs...
Apple has a full line of Certified Refurbished iMacs available for up to $350 off original MSRP. Apple’s one-year warranty is standard, and shipping is free. The following models are available: – 27... Read more
13″ MacBook Airs on sale for $120-$100 off MS...
B&H Photo has 2017 13″ 128GB MacBook Airs on sale for $120 off MSRP. Shipping is free, and B&H charges sales tax for NY & NJ residents only: – 13″ 1.8GHz/128GB MacBook Air (MQD32LL/A): $... Read more
15″ Touch Bar MacBook Pros on sale for up to...
Adorama has Space Gray 15″ MacBook Pros on sale for $200 off MSRP. Shipping is free, and Adorama charges sales tax in NJ and NY only: – 15″ 2.8GHz MacBook Pro Space Gray (MPTR2LL/A): $2199, $200 off... Read more

Jobs Board

*Apple* Solutions Consultant - Apple (United...
# Apple Solutions Consultant Job Number: 113384559 Brandon, Florida, United States Posted: 10-Jan-2018 Weekly Hours: 40.00 **Job Summary** Are you passionate about Read more
Art Director, *Apple* Music + Beats1 Market...
# Art Director, Apple Music + Beats1 Marketing Design Job Number: 113258081 Santa Clara Valley, California, United States Posted: 05-Jan-2018 Weekly Hours: 40.00 Read more
*Apple* Pay & Wallet Engineering Manager...
# Apple Pay & Wallet Engineering Manager, Apple Watch Job Number: 83769531 Santa Clara Valley, California, United States Posted: 06-Nov-2017 Weekly Hours: 40.00 Read more
UI Tools and Automation Engineer, *Apple* M...
# UI Tools and Automation Engineer, Apple Media Products Job Number: 113136387 Santa Clara Valley, California, United States Posted: 11-Jan-2018 Weekly Hours: 40.00 Read more
Senior Product Architect, *Apple* Pay - App...
# Senior Product Architect, Apple Pay Job Number: 58046427 Santa Clara Valley, California, United States Posted: 04-Jan-2018 Weekly Hours: **Job Summary** Apple , Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.