“If you don’t find it in the index, look very carefully through the entire catalogue.” | ||
| --Unknown, Sears, Roebuck, and Co. Consumer’s Guide, 1897 | ||
As we have repeatedly stated throughout this book, Mac OS X has a great many features and capabilities that its predecessors only dreamed of. In the previous chapter, we spoke about several security configuration issues surrounding a Mac OS X host in a corporate or enterprise network. Most of these aspects have always existed in such networks, but were largely set aside or overlooked when dealing with Macintosh computers because the operating system (and its accompanying tools) were unable to provide an appropriate infrastructure. Mac OS X, of course, changed this. One of the places in which this is most evident in the enterprise is Mac OS X’s support for various directory services. Not only can Mac OS X now host its own directory, it can participate in existing directories within the enterprise.
In this chapter, we will discuss some basics of directory services (including why they are used and general security issues) and then move on to much more specific discussions of Mac OS X’s primary directory services: NetInfo and Open Directory. Finally, we will discuss some of the alternatives to the built-in directory services.
A directory in this context is a hierarchical data structure, which attempts to catalog all the available resources on a network, much like a phone book tries to catalog a city’s phone numbers. Directories can store a variety of data: user credentials, supplementary user data, machine configurations, software configurations, and others.
There are several reasons why an organization might want to deploy an enterprise directory, most of which are related directly to the centralization of the data contained therein. First, with a properly deployed directory, users have access to all the resources their network has to offer and that they have permission to access. Just as it is easier to have everyone’s phone numbers in a single book rather than in a million individual phone books (at one per person), it is easier to deal with an enterprise’s resources when they can be found in one place. Second, administrators can often leverage the directory as a way to limit the number of management points required to control their networks, which can increase the stability of the network and decrease the stress of those same administrators. Another common use for directories is as a datastore for a single-sign-on (SSO) solution, often involving PKI (public key infrastructure).
As with most information systems, using a directory has security implications. Some aspects stem from the benefits of using a directory. This includes reduced human error from users and administrators because data is entered in fewer locations, reducing the chance that someone will fat-finger an important piece of data. Another benefit is that directories often make it much easier to deploy an organization’s security policy; a single set of controls can rarely be deployed for an entire organization, but a directory’s hierarchical nature makes it possible to get the most out of a single deployment.
The other aspects of directory services security pertain to the way in which the directory and its protocols are deployed. Among these are authentication, authorization, and data privacy. Authentication includes both the authentication of the user when reading or modifying objects in the directory and the client’s ability to ensure that it is communicating with the proper server. Ensuring that users can modify only the things they are authorized to is also important. Finally, there should be concern for the privacy of the data that flows between the client and the directory server(s), especially sensitive information such as user credentials. As we shall see shortly, not all Directories are created equal in these respects.
Inherited from its NeXTStep roots, NetInfo is Mac OS X’s default and primary directory service. A NetInfo directory (called a domain) is a hierarchical assemblage of individual databases. Each host (client or server) is a NetInfo domain unto itself and maintains at least one NetInfo database, called “local,” which is the default NetInfo configuration for Mac OS X and Mac OS X Server.
Minimally, a NetInfo domain consists of a root domain (/) and any number of subdomains. In the default configuration, the root domain for each host is synonymous with its local domain. Other than the default configuration, there are two other common scenarios for NetInfo domains: a two-level hierarchy with a single root domain and multiple hosts beneath it, and a three-tier hierarchy with a single root domain with a number of “network” subdomains beneath it—each with a collection of hosts beneath it (see Figure 10.1).
Each domain and subdomain in the hierarchy is given a “tag,” or a name that can be used by clients to explicitly query a domain. There are three special tags: root, network, and local. As we have stated previously, on a single standalone host, the root and local domains are synonymous. In a two-tier hierarchy, both the root and network domains are synonymous. In addition, when a computer is configured to serve a domain via subnet broadcasts, it must use the “network” tag for the served domain. A host may bind to a parent domain (a domain that is one step higher in the hierarchy) by one of three methods: explicit IP address and tag, subnet broadcast, and DHCP assignment (see Figure 10.2). To configure a host to be a child of an existing domain is a relatively simple procedure:
Open Directory Access.app (
/Applications/Utilities/Directory Access.app).Authenticate the application by clicking the lock icon in the lower-left corner.
Select the Services tab.
Select the NetInfo line item and click the Configure button below.
Select the binding method required by the parent domain.
Click the OK button.
Check the check box next to the NetInfo line item.
Click the Apply button.
For management of more complicated NetInfo domains, one must use NetInfo Manager (/Applications/Utilities/NetInfo Manager.app). By authenticating the application, an administrator has access to a number of different NetInfo management options from the Management menu. To modify the hierarchy itself, select the Manage NetInfo Hierarchy item from the Management menu. A dialog box displays (see Figure 10.3) that allows an administrator to create child and parent domains as well as clones of existing domains (used for load balancing and fault tolerance).
NetInfo data is stored in the hierarchy as a series of attributes (or properties) that are organized into directories (much like files are organized in a filesystem). Table 10.1 describes the major NetInfo directories in a database and their functions. These attributes can be viewed or modified via the GUI (with NetInfo Manager) or through several command-line applications (commonly known as the ni* applications). A number of other applications and preference panes also indirectly modify the database. Administrators should always beware when modifying any of the NetInfo attributes directly because none of the applications that directly modify them perform any real sanity-checking on the data entered. This makes it horribly easy to mess up the database to the point the system no longer functions properly.
Table 10.1. Major NetInfo Directories and Their Functions
DIRECTORY NAME | DESCRIPTION |
|---|---|
Aliases | Corollary to Sendmail’s |
Config | Contains configuration data for a variety of Apple’s services and daemons. |
Groups | Corollary to the UNIX |
Machines | Contains directories for each defined machine on the network; used for NetBoot and NetInfo integration. |
Mounts | Similar to |
Networks | Corollary to the UNIX |
Printers | Corollary to the UNIX |
Users | Loose corollary to the UNIX |
When a machine looks up information in the NetInfo hierarchy, it first searches the local database for the data, then the parent domain, then the parent’s parent domain, and so on. This feature can cause some interesting issues, particularly with regard to user accounts. User logins are queried from the hierarchy by usernames, which can cause unexpected issues when the hierarchy contains duplicate usernames or UIDs. In the former situation, the local user takes precedence, which can cause issues when users such as root attempt to log in to a workstation with the parent domain’s root account password. The latter situation, with duplicated UIDs, is the most problematic situation because permissions to files are assigned by UID, not by name. This means that unless UIDs are carefully managed, two users with different names may end up with access to the same files with the same permissions, which is generally a bad thing.
This discussion is a basic overview of the way NetInfo works. Successfully deploying a functional NetInfo hierarchy demands attention and planning, as well as knowledge of a few topics we did not discuss here. Suggested readings for more in-depth knowledge can be found in Appendix C, “Further Reading.”
Now that readers hopefully have a reasonable idea of what NetInfo is and does, we will dive into its security aspects. We will focus on the three major components discussed in the introduction to this chapter: authentication, authorization, and data privacy.
Any discussion of NetInfo and authentication to its datastore is necessarily short. From any security standpoint it is lacking. The server performs no real authentication of a user prior to the user querying the hierarchy for any information, save for a sort of passive authentication using the _trusted_networks attributes at the root of each domain (we will discuss _trusted_networks in the next section, “Authorization”). No authentication of the server by the client is attempted either, except passively, by configuring the client to connect to a specific IP address and NetInfo tag.
This lack of authentication makes local network attacks against the NetInfo domain relatively easy. Besides clients being able to query for any data from the NetInfo without authenticating, it also means that it would be relatively trivial for malfeasants to set up a rogue NetInfo server for their devious purposes. Neither of these scenarios should make administrators very happy. It is for these reasons (and for general sanity) that access to NetInfo hierarchies should never be allowed from the Internet or any other untrusted network.
As with authentication, the story of NetInfo and authorization is not very long or complicated. From previous discussions in Chapter 4, “What is this UNIX Thing?,” we already know that localhost access to the NetInfo database allows any user to read any information, including password hashes. Other aspects of NetInfo’s access control for a given domain or a directory therein are governed by two sets of attributes: the _writers* and _trusted_networks properties.
By default, only the root user can modify a NetInfo database. For various reasons, such as password management, it is necessary to allow non-root users to modify properties in the NetInfo hierarchy, which is accomplished with the _writers* property (see Figure 10.4).
The _writers* property comes in two varieties: _writers and _writers_propertyname (for example, _writers_passwd). Both properties, which can be found anywhere in a domain’s directory structure, specify a list of users allowed to write to a particular property or properties. Thus, setting the value of _writers_passwd to bob in bob’s NetInfo directory (/users/bob) would let the user bob modify his password. If a directory contains the bare _writers property, listed users can modify all properties in that particular directory. Either form of the property can also accept an asterisk (*), which is equivalent to specifying “all users.”
In general, administrators should not modify Mac OS X’s defaults regarding these properties. The operating system’s defaults are very sane; tightening them further will likely cause functionality issues, and relaxing them further will likely only introduce additional unnecessary risks to the system. Also, if an administrator finds herself seriously considering setting the _writers property (indicating that all properties in the containing directory) with a value of ’*’ (indicating all users), she should rethink things and possibly check herself into the local loony bin.
The trusted_networks property, if it exists at all, is located at the root of a domain and sets the hosts that are allowed to query the domain database. If the property does not exist for a domain, then any host may query the domain’s database. If the property exists but has no values set, only the localhost address may access the database. When set, the values can be specified as the network parts of classful addresses or individual host addresses (that is, 192, 192.168, 192.168.0, or 192.168.0.1).
Local domains in Mac OS X have their trusted_networks property blank, allowing only the local host to query the database (see Figure 10.5). If configured to provided configuration and authentication data for other systems on the network, Mac OS X Server does not include the trusted_networks attribute for its “network” domain.
To modify this default behavior, run the NetInfo Manager application; then select the root (/) of the domain to modify (parent domains can be selected by clicking the Open Parent globe icon in the toolbar). Next, authenticate the application and then select Add from the Edit menu; a new property will be added and highlighted in the lower pane. Change the new property’s name to be trusted_networks; then set the value to the classful network address of the local network. Once done, save the changes, and then restart the NetInfo database using the Restart Local NetInfo Domains item from the Management menu.
The trusted_networks property provides only a small amount of additional security. Configuring the trusted_networks property should be of secondary concern to ensuring that no one can access anything on the local network from an untrusted network. But still, it does add some small bit of security with minimal pain and should be configured.
Keeping data private as it bounces down the wire between the client and server is difficult with NetInfo. All traffic that transits the network is in the clear. Unfortunately, there is little one can do to secure this data; standard tunneling techniques with Stunnel or SSH do not function because of their reliance upon UDP and RPC in addition to TCP. Other than using IPSec to encrypt all traffic between the hosts (a jackhammer solution for a clawhammer problem), there is little an administrator can do to combat this.
Fortunately for us, Apple has transitioned (or is beginning a transition) away from NetInfo as a network directory service and protocol toward an implementation of OpenLDAP, which brings a myriad of potential improvements, not the least of which is security. This transition comes to us in the form of Apple’s Open Directory.
One of the biggest things to understand about Apple’s Open Directory is that it is not a directory service itself; in fact, there is, strictly speaking, no “it.” Open Directory is instead an assembly of applications and daemons that together provide the features and functionality of a directory service. There is no single opendirectoryd (although in some respects lookupd comes near), or opendirectory.conf configuration file. Among the components of Open Directory are a framework (an API and libraries) for client access to data, a pluggable framework for discovering network resources (based on Apple’s NSL API), a directory server (based on NetInfo and LDAP), and an authentication server. Another important thing to note is that some aspects of Open Directory (notably, the authentication server and the directory server) are only supported by Apple on Mac OS X Server, though intrepid users may enable the latter on the desktop version of the operating system as well.
Open Directory’s provisions for client access to directory are embodied in DirectoryService.framework, and this framework’s physical manifestation, Directory Access (/Applications/Utilities/Directory Access.app), an application we have already seen elsewhere in this chapter. The DirectoryService API allows developers to write clients that make use of the various datastores without needing to be cognizant of the underlying protocols. Datastores can be added to a system via an extensible pluggable architecture. DirectoryService.framework is open source and included with the Darwin project.
Network resource discovery is provided via Apple’s Network Service Location (NSL) API. This API provides developers with a supple framework for accessing, cataloging, and displaying network resources, including both low-level raw data access and high-level GUI representation. Similar to the DirectoryService framework, NSL sports a pluggable architecture for locating resources in directories and on a network. The most accessible example of the use of the NSL API is the Connect to Server menu item in the Finder’s Go menu.
Outwardly, Open Directory’s directory server is an implementation of OpenLDAP (version 2.1.0). LDAP (Lightweight Directory Access Protocol) is perhaps the most common directory service in the industry, and OpenLDAP is an open-source implementation of this standard. Like NetInfo, LDAP is a hierarchical database that contains a variety of information, including user data and network resources. LDAP, however, far exceeds NetInfo’s native capability to scale in breadth and depth of the hierarchy. It is also much more common on the non-NeXT, non-Apple networks of the world.
Despite its pretty LDAP exterior, the core of Open Directory’s directory server is still NetInfo. A company named PADL Software (http://www.padl.com) created an LDAP wrapper for NetInfo (or a LDAP/NetInfo bridge), which supports LDAP-based (version 2 and 3) access to the NetInfo database. This wrapper permits a host of standard LDAP-based applications and tools to interact and utilize the underlying NetInfo database without having to port those same tools to a different protocol. This mapping of the LDAP protocol to the NetInfo architecture allows Mac OS X to integrate into enterprise networks in ways Mac OS never could, while leveraging the venerable NetInfo for support of legacy networks. By default, all (and only) non-“local” NetInfo domains are accessible via the LDAP protocol.
The remaining major component of Open Directory is its authentication server: Password Server. Password Server is a SASL-based (Simple Authentication and Security Layer) authentication server, which provides for encrypted network authentications (using several different protocols) as well as rudimentary password policies that include password expiration, forced password changes, minimum password lengths, and account disablement (see Figure 10.6).
In addition to these features, using Password Server also has the side effect of eliminating password hashes from NetInfo queries (the nidump passwd . / issue). One exception to this is the server’s local root account, which is not stored in the Password Server. For this reason, no non-administrative shell or console access should be allowed to the server in a secure environment.
A full discussion of the theory and practice of LDAP is beyond the scope of this chapter and book, so we will assume that readers are familiar with its concepts and terminology. For those readers lacking this knowledge, we suggest checking Appendix C for additional material.
Like connecting Mac OS X to a NetInfo server, connecting to an Open Directory is relatively easy and done through the Directory Access application. To add Mac OS X to an existing Open Directory server, carry out the following steps:
Open the Directory Access application.
Select the Services tab.
Authenticate the application.
Select the LDAPv3 line item.
Ensure that LDAPv3 is enabled via the associated check box.
Click the Configure button.
If necessary, click the down arrow next to the Show Option label.
Click the New button.
Click the Edit button.
Fill in the Configuration Name text box appropriately.
Fill in the Server Name or IP Address text box appropriately.
If the server requires authentication (not the default) enable the Use Authentication When Connecting check box and enter the appropriate information.
If the server can use SSL encryption (not the default), enable the Encrypt Using SSL check box.
Select the Search & Mappings tab.
Select Open Directory Server from the pull-down menu labeled Access This LDAPv3 Server Using.
In the Search Base Suffix, enter the appropriate search suffix (for instance,
"cn=users,dc=example,dc=com"for a server for the example.com domain).Click the OK button.
Click the other OK button.
Click the Authentication tab.
Select Custom Path from the Search: drop-down menu.
Click the Add button.
Select the newly added LDAPv3 configuration (that is,
/LDAPv3/server.example.com).Click the Add button.
Click the Apply button.
Restart DirectoryServices (lookupd) by entering sudo SystemStarter restart DirectoryServices in a terminal window.
This process completes the configuration, and the host should be able to authenticate to the configured Open Directory server.
Open Directory’s LDAP/NetInfo bridge adds the capability to require users to be authenticated when querying the directory server, although not by default. Configuring slapd (Mac OS X’s LDAP server, which carries the physical incarnation of the LDAP/NetInfo bridge) to require authentication, is a part of the access control mechanisms, so we will discuss this aspect more in the next section (“Authorization”). Users can authenticate against any one of three different services: simple, SASL (Password Server), or Kerberos. Simple authentication sends the user’s distinguished name and clear-text password to the server. Apple’s SASL-based server supports all the SASL standard authentication methods (CRAM-MD5, crypt, Digest-MD5, and so on), as well as a few additional methods added by Apple (such as NTLM, AFP, WebDAV digest, and others).
It should be noted that although the server’s default configuration allows anonymous connections, password hashes are not available as they are with NetInfo access.
Open Directory’s LDAP implementation provides its access control through standard OpenLDAP ACLs, although in its default configuration, NetInfo authorization rules (via the _writers* and trusted_networks properties) take precedence.
To disable NetInfo authorization semantics, you can download an updated version of mkslapdconf (the tool that builds an appropriate slapd.conf file for the LDAP/NetInfo Bridge) from PADL Software (ftp://ftp.padl.com/private/mkslapdconf-PR-2984309.tar.gz). After the file has been downloaded, decompress the tarball, back up the existing files, and copy the files from the package in place, as follows (as the root user):
bash-2.05a# tar xzf mkslapdconf-PR-2984309.tar.gz bash-2.05a# cp /usr/sbin/mkslapdconf /usr/sbin/mkslapdconf.orig bash-2.05a# cp usr/sbin/mkslapdconf /usr/sbin/mkslapdconf bash-2.05a# cp /usr/share/man/man8/mkslapdconf.8 /usr/share/man/man8/mkslapdconf.8.orig bash-2.05a# cp usr/share/man/man8/mkslapdconf.8 /usr/share/man/man8/mkslapdconf.8
After the files are in place, back up the existing configuration file, create a new configuration file without the NetInfo semantics, and restart the LDAP server.
bash-2.05a# cp /etc/openldap/slapd.conf /etc/openldap/slapd.conf.orig bash-2.05a# mkslapdconf -a -s -n > /etc/openldap/slapd.conf bash-2.05a# SystemStarter stop LDAP Welcome to Macintosh. Stopping LDAP server Startup complete. Hangup bash-2.05a# SystemStarter start LDAP Welcome to Macintosh. Configuring network Initializing network Setting host identifier kern.hostid: 3232235745 -> 3232235745 Starting port mapper Starting NetInfo Starting LDAP server Startup complete. Hangup bash-2.05a#
Further access control is managed via standard OpenLDAP semantics in the slapd.conf file. A simple general form of an ACL is
access to <something>
by <who1> <access-level1>
by <who2> <access-level2>
...
by <whoN> <access-levelN>
Here, <something> is the Distinguished Name (DN) to which access is being controlled, <who> is the user(s) or group(s) that the rule applies to, and <access-level> is the permissions to grant to the indicated <who>.
For example, to implement the OpenLDAP Project’s recommended base ACLs, one would add the following to the end of slapd.conf after disabling the NetInfo authorization rules (as indicated previously):
access to attr=userPassword
by self write
by anonymous auth
access to *
by self write
by users read
The first ACL allows users to modify their own passwords and anonymous users to use the passwords for authentication. The second ACL allows users to write to their own user entry and authenticated users read-only access to anything. This also implicitly denies access by unauthenticated (anonymous) users.
This is just a simple example of OpenLDAP’s ACLs. The access control syntax provides for much more complex and fine-grained control, but it is too complicated to adequately describe and demonstrate here. As usual, we suggest reviewing the additional documentation indicated in Appendix C.
Like authentication and authorization, Open Directory’s OpenLDAP front-end improves greatly upon the security of directory data as it transits the network. It begins with the SASL-based authentication mechanism, which can keep user credentials from being sent in the clear. The other major improvement is the capability to encrypt all traffic using SSL.
Enabling SSL encryption is an easy process for both a Mac OS X Client and a machine running Mac OS X Server. The client side of things, which we already discussed in the previous subsection, consists of checking a box in Directory Access, saving changes, and restarting DirectoryServices. Mac OS X Server is only a little more involved because it involves requesting and installing an SSL certificate. The process to create a certificate for the server follows the general process described in more detail in the section of Chapter 6, “Internet Services,” named “Enabling SSL with Apache.”
The first step is to create the certificate request:
bash-2.05a$ sudo mkdir /etc/openldap/cert.req bash-2.05a$ sudo openssl req -new -nodes -keyout /etc/openldap/ cert.req/ldapreq.pem -out/etc/openldap/cert.req/ldapreq.pem
Of note here is the -nodes flag, which indicates that private keys be stored in clear text, which is a requirement for OpenLDAP. After a certificate has been granted, the public and private keys, as well as a copy of the CA’s signing key, should be placed in a securable location.
bash-2.05a$ sudo mkdir /etc/openldap/ca.key bash-2.05a$ sudo cp ca.key /etc/openldap/ca.key bash-2.05a$ sudo mkdir /etc/openldap/ldappub.key bash-2.05a$ sudo cp ldappub.key /etc/openldap/ldappub.key bash-2.05a$ sudo mkdir /etc/openldap/ldappriv.key bash-2.05a$ sudo cp ldappriv.key /etc/openldap/ldappriv.key bash-2.05a$ sudo chmod 0700 /etc/openldap/ldappriv.key bash-2.05a$ sudo chmod 0600 /etc/openldap/ldappriv.key/ldappriv.key
Next, lines must be added to slapd.conf configuration file. Add the following lines to /etc/openldap/slapd.conf:
TLSCACertificateFile /etc/openldap/ca.key/ca.key TLSCertificateFile /etc/openldap/ldappub.key/ldappub.key TLSCertificateKeyFile /etc/openldap/ldappriv.key/ldappriv.key
After the additions are made, restarting the LDAP server enables SSL/TLS encryption.
bash-2.05a$ sudo SystemStarter stop LDAP bash-2.05a$ sudo SystemStarter start LDAP
Some clients other than Mac OS X will additionally need a copy of the CA’s signing certificate.
Mac OS X’s capabilities extend beyond just integrating with Apple’s own directory services, though. With the DirectoryServices framework and the Directory Access application, Apple provides a way to integrate Mac OS X with a host of different service locators and directory services. This section will briefly describe each of these components and some of the benefits and drawbacks of each of the eight default protocols.
This is a non-configurable component of Directory Access that provides access to the most common legacy protocol on Macintosh networks: AppleTalk. This support for a legacy protocol is its chief upside. This component includes support for locating network resources as well as authenticating (encrypted or not) to the hosts containing those resources. AppleTalk is not a directory service in the typical sense, but a network protocol that provides built-in subprotocols for resource location. AppleTalk’s drawbacks, other than not being a real directory service, are that it is a non-IP protocol (in its pure mode, although the component also supports Apple File Protocol over IP) and that it does not scale in large or busy networks.
Another non-directory component, this selection allows Mac OS X to utilize the standard UNIX files (such as /etc/master.passwd, /etc/hosts, and so on) for user authentication and resource naming and location. The advantages of using BSD configuration files are mostly compatibility as well as a measure of increased security over NetInfo because user credentials cannot be enumerated if the files are adequately protected. The downside is that the files are useful only to the box on which they reside, and thus there is no real way to leverage them as a single point of configuration or management. Also, the built-in tools will not write information to any of the configuration files, so it must be done manually, an occasionally harrowing process.
This is the first of the configurable components and is also the first that can integrate Mac OS X with a real directory service. LDAPv2 is a commonly deployed (though older and less capable than LDAPv3) directory service within the enterprise. True to its nature, LDAPv2 is a scaleable directory capable of handling a large number of objects in a deep hierarchy. It has a number of drawbacks, however, especially when compared to its descendant LDAPv3. One of the bigger drawbacks is only indirectly security-related: LDAPv2 implementations often vary considerably from the established standard, making it occasionally difficult to integrate directories from different vendors. More security-related is LDAPv2’s lack of support for modern authentication methods or transport encryption. Mac OS X cannot write information to an LDAPv2 directory.
Like most directory services, proper deployment of an LDAPv2-based directory requires adequate education and planning prior to implementation; this learning curve is often steep enough to cause some administrators to flee in terror. Apple’s current documentation for integration with Microsoft’s Active Directory (one of the more common directory services in active deployment) is via this component (more information on this is in Appendix C). Novell also has information on integrating Mac OS X with its eDirectory (NDS writ large) product, which also utilizes the LDAPv2 plug-in (see Figure 10.7).
The LDAPv3 component is one of the great leaps forward for Mac OS X in business and enterprise networks. Like LDAPv2, it is a highly scalable directory service, but unlike LDAPv2, it supports both modern authentication mechanisms as well as transport encryption. Current LDAPv3 implementations also seem to be more reliant on the standards than are those of LDAPv2. LDAPv3 has few drawbacks, but it is currently less commonly used than LDAPv2. Beyond this, there also seem to be issues with different implementations of the transport layer security as well. Also, just like LDAPv2, there is a reasonably steep learning curve involved.
Yes, we have already talked about this beast, so a really brief overview is in order. The pluses: supported by a largish number of legacy NeXT and Mac OS X systems and is relatively easy to learn and deploy compared to other directory services. The minuses: no authentication mechanism for database queries, über simplistic access control, password hashes are available to any user unless an external authentication server is used, and no transport encryption.
Like AppleTalk, Rendezvous is not really a directory service, but a resource and service location protocol, which we spoke about in much more detail in Chapter 9, “Enterprise Host Configuration,”.
SLP (Service Location Protocol) is like an ancestor to Rendezvous. It also is a service location protocol (go figure), but lacks some of the niftier features of its younger cousin. Prior to Mac OS X v10.2, SLP was the primary IP-based service discovery protocol for the Mac OS.
Our final entry from Directory Access is SMB (Server Message Block), probably one of the most ubiquitous protocols on business networks, due largely to the popularity of Microsoft’s Windows operating system. Like AppleTalk, Rendezvous, and SLP, SMB is a resource discovery protocol (AppleTalk and SMB are also network protocols). This component supports minimal configuration via the GUI (see Figure 10.8), allowing you to specify only the workgroup for the computer and the location of a WINS server (a type of name server). Additional parameters may be configured via configuration files. We spoke at more length about this protocol as Windows File Services (an open-source implementation of the protocol) in Chapter 7, “File Sharing.”
Not only does Mac OS X allow administrators to share information with other systems on their networks in unprecedented ways; now administrators can search for and access the data from those same systems as well. This chapter has described the security aspects of the core components of this new infrastructure, including NetInfo and Open Directory. Although NetInfo provides support for a protocol that has been with Mac OS X since it was still a strange port of the NeXT OS to the PowerPC platform, PADL Software’s LDAP/NetInfo bridge extends this venerable directory to new heights and capabilities. Open Directory provides a wealth of authentication, authorization, and data privacy improvements that security-minded NetInfo administrators have long had on their wish lists.
This spirit of new horizons in capabilities, usability, and power are an ongoing theme in Apple’s new operating system. We can only hope there is even more in store.
With the close of this chapter comes the close of our look at the security mechanisms in Mac OS X’s core subsystems. The rest of the book focuses on auditing and forensics, which encompass day-to-day monitoring of logs, what to do when bad people happen to a system, and how to prepare for the eventuality before it happens.