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


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.

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:


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'] = '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:


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


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


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


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


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

 
AAPL
$111.78
Apple Inc.
-0.87
MSFT
$47.66
Microsoft Corpora
+0.14
GOOG
$516.35
Google Inc.
+5.25

MacTech Search:
Community Search:

Software Updates via MacUpdate

LibreOffice 4.3.5.2 - Free Open Source o...
LibreOffice is an office suite (word processor, spreadsheet, presentations, drawing tool) compatible with other major office suites. The Document Foundation is coordinating development and... Read more
CleanApp 5.0.0 Beta 5 - Application dein...
CleanApp is an application deinstaller and archiver.... Your hard drive gets fuller day by day, but do you know why? CleanApp 5 provides you with insights how to reclaim disk space. There are... Read more
Monolingual 1.6.2 - Remove unwanted OS X...
Monolingual is a program for removing unnecesary language resources from OS X, in order to reclaim several hundred megabytes of disk space. It requires a 64-bit capable Intel-based Mac and at least... Read more
NetShade 6.1 - Browse privately using an...
NetShade is an Internet security tool that conceals your IP address on the web. NetShade routes your Web connection through either a public anonymous proxy server, or one of NetShade's own dedicated... Read more
calibre 2.13 - Complete e-library manage...
Calibre is a complete e-book library manager. Organize your collection, convert your books to multiple formats, and sync with all of your devices. Let Calibre be your multi-tasking digital librarian... Read more
Mellel 3.3.7 - Powerful word processor w...
Mellel is the leading word processor for OS X and has been widely considered the industry standard since its inception. Mellel focuses on writers and scholars for technical writing and multilingual... Read more
ScreenFlow 5.0.1 - Create screen recordi...
Save 10% with the exclusive MacUpdate coupon code: AFMacUpdate10 Buy now! ScreenFlow is powerful, easy-to-use screencasting software for the Mac. With ScreenFlow you can record the contents of your... Read more
Simon 4.0 - Monitor changes and crashes...
Simon monitors websites and alerts you of crashes and changes. Select pages to monitor, choose your alert options, and customize your settings. Simon does the rest. Keep a watchful eye on your... Read more
BBEdit 11.0.2 - Powerful text and HTML e...
BBEdit is the leading professional HTML and text editor for the Mac. Specifically crafted in response to the needs of Web authors and software developers, this award-winning product provides a... Read more
ExpanDrive 4.2.1 - Access cloud storage...
ExpanDrive builds cloud storage in every application, acts just like a USB drive plugged into your Mac. With ExpanDrive, you can securely access any remote file server directly from the Finder or... Read more

Latest Forum Discussions

See All

Make your own Tribez Figures (and More)...
Make your own Tribez Figures (and More) with Toyze Posted by Jessica Fisher on December 19th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
So Many Holiday iOS Sales Oh My Goodness...
The holiday season is in full-swing, which means a whole lot of iOS apps and games are going on sale. A bunch already have, in fact. Naturally this means we’re putting together a hand-picked list of the best discounts and sales we can find in order... | Read more »
It’s Bird vs. Bird in the New PvP Mode f...
It’s Bird vs. Bird in the New PvP Mode for Angry Birds Epic Posted by Jessica Fisher on December 19th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »
Telltale Games and Mojang Announce Minec...
Telltale Games and Mojang Announce Minecraft: Story Mode – A Telltale Games Series Posted by Jessica Fisher on December 19th, 2014 [ permalink ] | Read more »
WarChest and Splash Damage Annouce Their...
WarChest and Splash Damage Annouce Their New Game: Tempo Posted by Jessica Fisher on December 19th, 2014 [ permalink ] WarChest Ltd and Splash Damage Ltd are teaming up again to work | Read more »
BulkyPix Celebrates its 6th Anniversary...
BulkyPix Celebrates its 6th Anniversary with a Bunch of Free Games Posted by Jessica Fisher on December 19th, 2014 [ permalink ] BulkyPix has | Read more »
Indulge in Japanese cuisine in Cooking F...
Indulge in Japanese cuisine in Cooking Fever’s new sushi-themed update Posted by Simon Reed on December 19th, 2014 [ permalink ] Lithuanian developer Nordcurrent has yet again updated its restaurant simulat | Read more »
Badland Daydream Level Pack Arrives to C...
Badland Daydream Level Pack Arrives to Celebrate 20 Million Downloads Posted by Ellis Spice on December 19th, 2014 [ permalink ] | Read more »
Far Cry 4, Assassin’s Creed Unity, Desti...
Far Cry 4, Assassin’s Creed Unity, Destiny, and Beyond – AppSpy Takes a Look at AAA Companion Apps Posted by Rob Rich on December 19th, 2014 [ permalink ] These day | Read more »
A Bunch of Halfbrick Games Are Going Fre...
A Bunch of Halfbrick Games Are Going Free for the Holidays Posted by Ellis Spice on December 19th, 2014 [ permalink ] Universal App - Designed for iPhone and iPad | Read more »

Price Scanner via MacPrices.net

Kodak Returns to CES With New Consumer Produ...
Former photography colossus Kodak is returning to CES for the first time in three years where the Kodak booth (#21818 South Hall 1) will showcase a wide range of innovative, imaging-related products... Read more
Invaluable Launches New Eponymously -Named A...
Invaluable, the world’s largest online live auction marketplace, hhas announced the official launch of the Invaluable app for iPad, now available for download in the iTunes App Store. Invaluable... Read more
IDC Reveals Worldwide Mobile Enterprise Appli...
International Data Corporation (IDC) last week hosted the IDC FutureScape: Worldwide Mobile Enterprise Applications and Solutions 2015 Predictions Web conference. The session provided organizations... Read more
Hello Vino Wine App Launches “Safe Ride Home”...
Hello Vino has announced addition of a new “Get a Safe Ride Home” feature in its Food & Drink app with a direct connection to Uber, the technology platform that connects users with rides. The... Read more
DEVON-technologies Releases DEVONthink To Go...
Coeur d’Alene, Idaho based DEVON-technologies, LLC has updated DEVONthink To Go, its mobile companion to DEVONthink, to version 1.5. The update includes an iOS 8 extension, compatibility with the... Read more
The Apple Store offering free next-day shippi...
The Apple Store is now offering free next-day shipping on all in stock items if ordered before 12/23/14 at 10:00am PT. Local store pickup is also available within an hour of ordering for any in stock... Read more
It’s 1992 Again At Sony Pictures, Except For...
Techcrunch’s John Biggs interviewed a Sony Pictures Entertainment (SPE) employee, who quite understandably wished to remain anonymous, regarding post-hack conditions in SPE’s L.A office, explaining “... Read more
Holiday sales this weekend: MacBook Pros for...
 B&H Photo has new MacBook Pros on sale for up to $300 off MSRP as part of their Holiday pricing. Shipping is free, and B&H charges NY sales tax only: - 15″ 2.2GHz Retina MacBook Pro: $1699... Read more
Holiday sales this weekend: MacBook Airs for...
B&H Photo has 2014 MacBook Airs on sale for up to $120 off MSRP, for a limited time, for the Thanksgiving/Christmas Holiday shopping season. Shipping is free, and B&H charges NY sales tax... Read more
Holiday sales this weekend: iMacs for up to $...
B&H Photo has 21″ and 27″ iMacs on sale for up to $200 off MSRP including free shipping plus NY sales tax only. B&H will also include a free copy of Parallels Desktop software: - 21″ 1.4GHz... Read more

Jobs Board

*Apple* Store Leader Program (US) - Apple, I...
…Summary Learn and grow as you explore the art of leadership at the Apple Store. You'll master our retail business inside and out through training, hands-on experience, Read more
Project Manager, *Apple* Financial Services...
**Job Summary** Apple Financial Services (AFS) offers consumers, businesses and educational institutions ways to finance Apple purchases. We work with national and Read more
*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
*Apple* Retail - Multiple Positions (US) - A...
Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, you're also the Read more
*Apple* Retail - Multiple Positions (US) - A...
Job Description: Sales Specialist - Retail Customer Service and Sales Transform Apple Store visitors into loyal Apple customers. When customers enter the store, Read more
All contents are Copyright 1984-2011 by Xplain Corporation. All rights reserved. Theme designed by Icreon.