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 (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
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,
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 (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.
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:
Figure 3. Activate
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
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
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
$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:
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/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.
Figure 7. Create the
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/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:
Figure 9. OU with Admins
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/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
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
Figure 12. Adding
Custom Mapping for Containers in the OU.
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:
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/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
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
Figure 15. No
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
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
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
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
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\
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
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.
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 http://afp548.com to learn how you can secure your LDAP
Directory from anonymous and unauthenticated access.
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: firstname.lastname@example.org.