Knock Knock Knocking on LDAP's Door, PART 1
Volume Number: 21 (2005)
Issue Number: 9
Column Tag: Programming
The Source Hound
Knock Knock Knocking on LDAP's Door, PART 1
by Dean Shavit
If there is such a thing as a tradition in the relatively new IT profession, the widely held
belief that Apple Server solutions don't have an adequate, scalable, or enterprise-worthy
implementation of Directory Services is about as close as it gets. Directory Services are generally
methods of organizing and aggregating user, group, computer, and resource information, into a
logical and accessible hierarchy, along with a strategy of maintaining and enforcing access control
over those resources. Such traditions are somewhat related to assumptions and their evil cousins
known as hysterias which are similar to beliefs that Netware Sysops often held about the superiority
of eDirectory (Novell's mature and spectacular Directory Service) over Active Directory when it was
released in 2000. Those Novell Sysops are probably not quite as snooty now that Active Directory
dominates Enterprise IT.
Inside the Black Box
While Novell was polishing its Netware Directory Services into what is now called eDirectory, and
Microsoft was busy readying Active Directory, Apple was still mired in the throes of what I can only
fairly call "faking it." AppleShare IP 6 and OS X Server 1.2 combined with Macintosh Manager for OS
9 and earlier, superimposed a user and workgroup authorization model on top of a simple database
that ran on a workstation OS (AppleShare IP), or synchronized up alongside of directory service far
too advanced for it (NetInfo in OS X Server 1.2), along with policies for access control to local
and network resources that worked well in a school environment for several reasons, one of which was
the cartoonish appearance of the windows and icons. Macintosh Manager has now gone the way of other
soon-to-be extinct technologies with the release of Tiger Server (it's not included, unless you're
upgrading from a Panther Server installation).
Starting with Panther Server, Apple moved into the LDAP age of open standards and Open-Source
software with Open Directory version 2, and its successor in Tiger Server, Open Directory version 3.
LDAP, which is an acronym for Lightweight Directory Access Protocol, has, at the very least, become
an agreed-upon standard that eDirectory and Active Directory aspire to, or emulate, or at least talk
to. Apple's Open Directory, however, doesn't have to aspire, because it is LDAP, OpenLDAP (www.openldap.org) to be precise. Tiger Server's LDAP
implementation is based on OpenLDAP 2.2.19 and Berkeley DB version 4.2.52 (which is used to actually
store the directory data).
Despite the fact that many of the initial-like components of LDAP are familiar buzz words in the
ears of IT professionals "DN" for distinguished name, "CN" for common name, "O" for organization
name and "OU" for organizational unit name, and "DC" for domain component, LDAP is still often
considered a black box, something that's addressed, mapped to, queried, searched or occasionally
edited or backed up. Aside from Novell's Console One eDirectory administration application, which
has a general hierarchical view of the Directory contents, very few Directory Service tools,
including Apple's own Workgroup Manager, do much to shine a light on the contents of the black box,
or how it's organized. Luckily, there's an Open-Source tool that allows the curious admin a view of
Apple's Open Directory with a visual arrangement that follows the conceptual structure.
Set up the LDAP Server
Before you can use tools like PHPLDAPadmin to start examining the structure of an LDAP Open
Directory Master, you need to make sure that your installation of Tiger server is functioning in the
"Open Directory Master" role. You can easily examine the Open Directory data in a local NetInfo
domain using the NetInfo Manager utility in /Applications/Utilities. Open up Server Admin, and click
on the "Open Directory" service section on the left. You should see the following:
Figure 1. Open Directory
Overview in Server Admin
If the overview indicates that your server's "Connected to a Directory System," then you should
change the role to "Standalone Server," reboot for the sake of superstition, then change the role to
"Open Directory Master." If your server is a "Standalone Server," then you're good to change the
role to Open Directory Master as well. Just like an ordinary Tiger workstation, Tiger Server, when
configured as a Standalone Server, simply stores its Directory data in its local NetInfo (nidb)
database. It isn't until Tiger Server is "promoted," to borrow a Microsoft Server term, that the
OpenLDAP Server daemon (slapd) starts.
There is, however, one big gotcha to be aware of: in order for the LDAP configuration to finish
properly, the DNS service needs to be set up to a "T" so that the server can resolve its own host
name and reverse its IP address without errors, otherwise LDAP may not behave as expected, nor will
the Kerberos KDC (Key Distribution Center) process start up automatically as it should. Luckily,
setting up the DNS service properly has never been simpler than with Tiger Server; you may have
heard that some sysadmins think that the new DNS GUI in Tiger Server is a step backward from the one
in Panther, and while I agree, Apple certainly knows the needs of its users better than little 'ol
me, but somehow I keep wishing for an "expert" (look at the wording here. Needs something added for
it to make sense.) DNS editing mode that would let me easily do thing like edit reverse lookup
records without having to go back into the terminal to configure DNS, as I did in the days of Jaguar
Server.
First, open Server Admin and click on the DNS service on the left. In the window on the right,
click the "Settings" tab at the bottom. Then, under the general tab on the top, go ahead and uncheck
the "Zone Transfers" box (which is used only when there's a slave DNS server working with the
server's DNS) for extra security, so that your DNS server can't be a victim of "spoofing" whereby a
malicious process attempts to exploit the DNS replication mechanism.
Figure 2. Disabling
"Zone Transfers" for the DNS Service
Second, click on the "Zones" tab and enter the name of your domain. Notice that my default, the
DNS service GUI will repurpose the computer/Bonjour name of your server as the hostname. If at this
point you want the hostname to differ, it's your opportunity to change it. And that's really about
all there is to it; Apple has made it easy. Now, just make sure that the IP address of your server's
set as the first DNS server in the list in System Preferences > Network > Your Ethernet
Interface.
Figure 3. Zone Setting
Screen.
At this point everything should work if you save your changes and then click the big green "Start
Service" button, but I've developed a ritual that dates back to the OS X 10.1 days. It's called
"digging DNS," and consists of two simple tests to verify that the DNS is humming along. First, test
the forward lookup record like so:
mostsvr:~ mostadmin$ dig mostsvr.macworkshops.com
; <<>> DiG 9.2.2 <<>> mostsvr.macworkshops.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39577
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;mostsvr.macworkshops.com. IN A
;; ANSWER SECTION:
mostsvr.macworkshops.com. 86400 IN A 192.168.0.85
;; AUTHORITY SECTION:
macworkshops.com. 86400 IN NS mostsvr.macworkshops.com.
;; Query time: 7 msec
;; SERVER: 192.168.0.85#53(192.168.0.85)
;; WHEN: Thu Aug 18 08:13:52 2005
;; MSG SIZE rcvd: 72
DIG is shorthand for "Domain Internet Groper," which, unlike its close cousin nslookup, pulls the
actual raw DNS records from your server. Of utmost importance is the "NOERROR" message, which
indicates the DNS goodness. Otherwise, you might see a "NXDOMAIN" message, or a "SEVERFAIL" message,
in which case you should go back, check your entries, then start and stop the DNS service. Next, we
want to make sure that the reverse lookup's working well, so we do:
; <<>> DiG 9.2.2 <<>> -x 192.168.0.85
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41041
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;85.0.168.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
85.0.168.192.in-addr.arpa. 86400 IN PTR mostsvr.macworkshops.com.
;; AUTHORITY SECTION:
0.168.192.in-addr.arpa. 86400 IN NS mostsvr.macworkshops.com.
;; ADDITIONAL SECTION:
mostsvr.macworkshops.com. 86400 IN A 192.168.0.85
;; Query time: 2 msec
;; SERVER: 192.168.0.85#53(192.168.0.85)
;; WHEN: Thu Aug 18 08:19:53 2005
;; MSG SIZE rcvd: 111
to make sure that the reverse lookup record's kosher as well. If you're testing this on a machine
other than the server, and don't necessarily want to ssh into the server, you can simply add
@ipaddress [hostname] to the dig statement to query a DNS server that you're not currently
configured to use, like so: dig mostsvr.macworkshops.com @192.168.0.85.
Now, you're ready to promote your server to an Open Directory master. Go ahead and change the
role in Server Admin, Open Directory. The following configuration window will pop up with a few
fields to fill out:
Figure 4. Create New
Open Directory master.
Look at the bottom of Figure 4. Notice how important a correctly configured FQDN (Fully Qualified
Domain Name) is to both the Kerberos Process as well as the search base for the LDAP directory. DNS
and LDAP are inseparable; you cannot run LDAP "right" unless all of your DNS stars are properly
aligned. Also new is the enforcement of a former best practice--creating a separate admin account for
the new Directory. The local admin account (uid 501) you might have used to administer an Open
Directory master under Panther Server, has absolutely no rights to the OD mater in Tiger Server.
However, it's easy to authenticate once, saving the new admin's password in the keychain of the
local account you might use to log into the Server, achieving virtually the same effect, though in
reality, it's an important conceptual difference, as we'll see later on.
Installing PHPLDAPadmin
Like the SquirrelMail (squirrelmail.sourceforge.net) PHP-based web mail
solution and the PHPMyAdmin (phpmyadmin.sourceforge.net) PHP-based MySQL Management tool,
PHPLDAPadmin stands out as an analogue to these other two excellent applications. Being web-based,
(especially using 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. The first part of installing PHPLDAPadmin is a snap:
1. Download the script from phpmyadmin.sourceforge.net
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
3. Enable the php4_module in the Web (service) > settings > modules section of Server
Admin as in the figure below:
Figure 5. 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
and 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 6. Copying Config
File.
Open up your config.php file in your favorite text editor. These days, it's the free Texwrangler
2.1 that's floating my boat, along with it's commercial counterpart, BBedit. 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:
Figure 7. PHPLDAPadmin
Welcome Screen
Getting in the Back Door
OK, so now it's time to ask the Tiger Server Open Directory master to open up and 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, with 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 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 everything was configured copasetically, then you'll see the promised land, which consists of
this:
Figure 8. Successful
Login to the LDAP Server
It doesn't take a whole lot of figuring out at this point that it's the plus signs that expand or
collapse the LDAP view hierarchically, just as in Windows Explorer or Novell Console One. Now, some
of the new features of Open Directory 3 become starkly apparent, we don't even need to read the
Server Documentation (although you really, really, should for a deeper understanding of Open
Directory and exactly what its specifications are. After all, it's open, as in Open-Source, and
open, as in the sense that all of the directory data is presented in that documentation. Here's what
the first level of an OD master looks like at first glance:
Figure 9. Top Level of
an OD Master.
What immediately leaps out is the first addition to Open Directory in Tiger Server, the
"accesscontrols." Other additions include "certificateauthorities and filemakerservers." We should
know by know that the ACLs for HFS on OS X Server are a huge leap forward.
Open Directory's slapd process loads several schema files, which live at:
/etc/openldap/schema/core.schema
/etc/openldap/schema/cosine.schema
/etc/openldap/schema/nis.schema
/etc/openldap/schema/inetorgperson.schema
/etc/openldap/schema/misc.schema
/etc/openldap/schema/samba.schema
/etc/openldap/schema/fmserver.schema
/etc/openldap/schema/apple.schema
Integrating OS X into complex networks will never be the same again, as the answer to many
questions is now "Yes, OS X Server can do that," rather than "No, it doesn't support that." And just
when we were getting used to understanding the limitations of those POSIX permissions, and working
hard to transpose that understanding to the new ACLs for files and folders, now we find, squirreled
away inside the "black box," a new form of ACLs, sometimes referred to as DACs, or "directory access
controls." 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
Herein lives an attribute called apple-acl-entry, and there are four default entries which are
(please note that the backslashes indicate line breaks) numbered, much like firewall (IPFW) rules.
Like many of the enhancements in Open Directory, the accesscontrols are a standard component of
OpenLDAP:
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
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
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
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
While not a whole lot of practical lore (or documented experience) exists with regards to the
capabilities of these DACs and Tiger Server, there's always the OpenLDAP.org mailing lists and
forums, although it's not hard to imagine how they could be applied, expanded, contracted or
utilized to open up or close of certain areas of an LDAP directory. Apple's Open Directory
documentation (http://www.apple.com/server/documentation)
characterizes the DACs this way: "Open Directory provides the ability to define directory access
controls (DACs) to all parts of the LDAP directory, providing fine-grained control of who has
permission to modify what. Open Directory stores the DACs in an apple-acl record that you can edit
using the Inspector in Workgroup Manager." Although the documentation advises admins to use
Workgroup Manager to modify DACs, it is also easy to use PHPLDAPadmin as well, although the
long-term consequences of using a third-party tool to manage an Open Directory master aren't widely
known. OS X Server admins are familiar with the dialog that appears when creating a new
administrator account for a Directory Service domain, asking if the admin has right to modify users,
groups and computers lists, along with associated managed preferences. Now with DACs, there's a tool
available to limit access for admins on an attribute by attribute basis, though no GUI exists for it
in yet in Workgroup Manager.
Personally, I'd feel more comfortable using a tool with a hierarchical view, rather than the
flat-list of attributes presented by Workgroup manager, but I'm a visual person. Many of us who've
worked with Panther Server remember the dialog that appears when creating a new admin account asking
if the new admin has rights to edit user accounts and preferences, as well as the same for groups
and computer lists, but DACs allow for even finer tuning. For example, tinkering with DAC 1000 may
affect the ability of admins to access the LDAP process itself. It also appears that the DACs are
applied in ascending order from the lowest number to the highest number, suggesting that it might be
a good idea to carefully consider how any DACs you'd add to the list might interact with others, or
if it's even a good idea to modify the default list at all, and if it is modified, how and where to
modify.
The World is Not Flat
One of the highly touted features of Open Directory 3 (again from OpenLDAP) is schema
replication. An LDAP schema consists of a collection of attributes and organizational structures
within a directory. Like Novell's eDirectory and Microsoft's Active Directory, Open Directory has
the capability to scale to encompass the scope of a company, educational institution or governmental
department that might be spread out over a large geographical area, with multiple branch offices.
However, the default schema that shipped with Panther Server and now with Tiger Sever assumes a flat
directory with a single organizational unit, as if every single employee, computer, and department
existed at corporate headquarters. It's always been possible to create organizational units within
Open Directory, even with Panther Server, except for one small problem. Even with a flat directory
structure, large organizations need directory replicas to enable authentication at remote locations
or as backups of the directory, and slurpd, the replication process of OpenLDAP, didn't support
replicating customizations to the schema in Panther Server.
Replicas are attached to masters as read-only copies. The master slapd (OpenLDAP) process writes
incoming changes to the directory to a file, which is monitored on a continual basis by slurpd,
which reads the file, then updates the replicas with the ldap network protocol. The file slapd
writes is an LDIF file (LDAP information file), which is also the LDAP import/export format. It then
writes an LDIF version of the change to what is called a "replication log." So, even if you could
neatly divvy up your directory so that certain users, groups, and computers lived in a different OU
(organizational units) for different departments, your replication process wouldn't reflect that, or
might even simply fail.
With Tiger Server, that's all changed, as least as far as schema replication support is
concerned. Unfortunately, Apple's administration tools (Workgroup Manager, Server Admin) still
operate under the assumption that the directory they read and write to is one large, flat space.
Apple's directory service lookupd daemon is also painfully unaware of changes to the directory, and
only finds the attributes that the mappings of the LDAPv3 Directory Access plugin allows, making it
somewhat difficult to administer customized directories, or even create those customizations.
PHPLDAPadmin, it turns out, is a great way to do so.
Create An OU
Before testing schema replication, you'll need to have an Open Directory Master set up, and
another installation of Tiger Server to use as a replica. Keep in mind you'll also need to have two
distinct licenses, as each Server uses the serial number as part of the ssh authentication necessary
to start the replication process. Establishing a replica's a cinch, just enter the ip address of the
OD master in the Open Directory settings in Server Admin, enter the root password on the OD master,
the short name of the directory admin and its password, then wait until the process completes.
Let's say we were sysadmins for a school that wanted to create three OUs: faculty, staff, and
students. We can use PHPLDAPadmin to do so; templates for common LDAP objects like OUs are included!
After logging into PHPLDAPadmin, we can then go ahead and create our OUs by clicking on the "gold
star" at the bottom of the directory tree:
Figure 10. Create New
LDAP Entry
What an array of spiffy LDAP objects to choose from! Some, obviously, are going to be more useful
to us than others, but I already am thinking of uses for the Samba 3 User and Samba 3 Group Mapping
objects for mixed networks. Also intriguing is the "custom" template where it would be possible to
store arbitrary attributes and retrieve them at will, almost like metadata. But we're after OUs, so
create three of them: faculty, staff, and students:
Figure 11. Create LDAP
Object
Next, log into Workgroup Manger on the OD master and create a new admin account with full rights
called "facultymin." You'll notice that, like all users accounts, facultymin winds up in cn=users.
Now, we can use PHPLDAPadmin to move facultymin into the faculty OU. If we also want to store
groups, computers, and other things, we might want to consider creating copies of other LDAP
"folders" within our OU.
Figure 12.
Organizational Units
Now, we'll move the facultymin user into the faculty OU. The part that gets hairy here is that
after the move, Workgroup Manager cannot see the user account anymore! However, since faultymin is a
directory administrator, we can still log into PHPLDAPadmin using the full DN of the user
(uid=facultymin,ou=faculty,dc=nagitest,dc=macworkshops,dc=com) and we even have read/write access.
But as far as lookupd and Workgroup Manager are concerned, the facultymin user's gone.
Now it's time to see the schema replication in action, and because an LDAP replica is read-only,
simply use the anonymous bind setting with PHPLDAPadmin to log into your replica (you'll need to
install it there too) and check to see if the schema replication's working. If everything's
copasetic, your OUs and facultymin user should now appear, almost instantly, in the replica LDAP
directory.
Figure 13. After the
Move.
OU-ch
For a real-world deployment, we'd want to figure out a way that Workgroup Manager could still
edit user, group and computer accounts that had been moved into OUs, or better yet, a way to create
accounts in the proper OUs in the first place--without having to use PHPLDAPadmin or some other
script to move them around. We'd also have to carefully consider how to adjust the DACs so that the
admins like our facultymin user only could write to the objects in their own OU. Other important
considerations would be how this would affect workgroup management, and cross-platform directory
service integrations with the Active Directory or LDAPv3 plug-in, and access to directory
information by other service like Apache and FTP. With so many open questions, I can only say: stay
tuned for part deux.
In Next Month's Source Hound
Part deux of knock, knock, knocking on LDAP's door. Hopefully, we won't have to break it down,
although we're going to breakdown how many of the above Open Directory questions we can
realistically answer, and see just practical it would be to administer an Open Directory deployment
with Organizational Units (OUs) and Directory Access Controls (DACs).
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.
