| LDAP services in Mac OS X Server are provided by the slapd daemonpart of the OpenLDAP LDAP implementation. Certain aspects of slapd's behavior are configurable in the Protocols and Policy tabs of the Open Directory module's Settings section within Server Admin. To set shared (LDAP) domain configuration 1. | Within the Settings section of the Open Directory module, click the Protocols tab and make sure that LDAP Settings is chosen from the Configure pop-down menu (Figure 3.13).
These are basic settings that control the behavior of slapd. More advanced configurations are feasible by manually editing the slapd.conf and slapd_macosxserver.conf files in /private/etc/openldap. See the slapd.conf man page for more details.
Figure 3.13. Viewing LDAP settings after becoming an Open Directory master. 
| | | 2. | From the following list of options, choose the ones you want to change:
- Search Base You can't really change the search base graphically, but it appears here.
- Database The location of the database used by slapd, the actual LDAP server process. You can locate the data store on higher-performing or more redundant file servers, such as a RAID array, if you choose. You might also want to segregate it on a non-system volume, in case the system volume is filled by log files or user files.
- Return a maximum of n search results Assign a maximum number of records returned from any search. This is useful in preventing denial-of-service attacks that try to review large directories.
- Search times out in n Setting to discourage loss of service centered around exhausting available TCP sockets. By timing out searches we can ensure that no extraneous sockets are in use.
- Enable Secure Sockets Layer Enable ldaps:// connections, and choose among available SSL certificates. This is only marginally useful since out-of-box Open Directory clients do not verify the authenticity of ldaps:// certificates, and since certificates produced by Mac OS X Server's Certificate interface are, by default, not signed by a certificate authority.
|
Using SSL with LDAP and Open Directory When you click the Enable Secure Sockets Layer (SSL) check box and choose a certificate (the default certificate is the one that can be chosen prior to creating any customized certificates), you must immediately also inform the Directory Service infrastructure on your Mac OS X Server that you are requiring a certificate. You do this by using the Directory Access application to use SSL for the shared (LDAP) domain. Once you select this check box and save, anyone using Workgroup Manager to manage shared (LDAP) accounts will be denied. That's because you must first use Directory Access to tell the server to use SSL to see its own shared domain. To do that, open Directory Access on the server (or choose Server > Connect on any Mac OS X computer from Directory Access). Double-click the LDAPv3 service from the Services list and select the SSL check box on the right of the window. Click OK to accept the changes. You may need to deselect and then select the LDAPv3 service in order to access the Apply button. Then click Apply to notify the DirectoryService daemon to reread the LDAPv3 configuration. |
Managing LDAP binding policies in an Open Directory domain The following LDAP binding and security policies are entirely optional and affect only Open Directory clients. Other LDAP clients are totally unaware of them and may continue to connect anonymously or using clear-text, unsecure credentials regardless of what you do here. In other words, these settings do nothing to secure your Open Directory master. The first set of LDAP policies are "Enable directory binding" and "Require clients to bind to directory." These revolve around authenticated binding, wherein the Open Directory client uses a Computer account to perform authenticated LDAP queries on the Open Directory master. This behavior is new in Mac OS X Server 10.4. Although authenticated queries could be performed in previous releases, there was no system or standard to provision machine accounts. Again, note that these are client-side policies obeyed only by Open Directory clients, and that these settings do not affect the LDAP server's configuration in any way. The next set of LDAP policies, discussed in the following task, deal with the security characteristics of the LDAP connection performed by Open Directory clients. Selection of all is required to mark a directory domain as trusted, which is required in order to enforce certain client management policies such as MCX login scripts. What all of these options really boil down to is that in a default state the entire LDAP component of your Open Directory is available anonymously anyway. So encrypting anything but passwords is a little redundant at this point unless you've implemented a fairly rigorous set of directory ACLs. Therefore, ensuring that passwords are protected is probably enough for most people. To set bind options on an Open Directory Master 1. | Within the Settings section of the Open Directory module, select the Security tab and then the Security tab (Figure 3.14).
Figure 3.14. Options to securely bind Mac OS X computers to an Open Directory master. 
| | | 2. | Click the appropriate check boxes:
- Enable Directory Binding Permits Open Directory clients to perform authenticated LDAP operations, and alerts them that during initial directory discovery they should permit the creation of a machine account.
- Require clients to bind to directory Requires Open Directory clients to use authenticated binding. Note that nonOpen Directory, generic LDAP clients may still make unauthenticated queries.
- Disable clear text passwords Ensures that Open Directory clients do not send LDAP passwords in clear text. Clients will select the most secure SASL authentication method available to them: Generic Security Service Application Program Interface (GSSAPI and, in this case, Kerberos) or Challenge Response Authentication Method (CRAM-MD5), but will not fall back to clear-text authentication unless the connection is encrypted by SSL.
- Digitally sign all packets Cryptographically ensures that every packet is legitimate. Requires Kerberos to work.
- Encrypt all packets Ensures that no LDAP traffic whatsoever is sent over the network in clear text. Requires either Kerberos or SSL.
- Block man-in-the-middle attacks Very similar to "Digitally sign all packets," this option informs the client that it should prevent man-in-the-middle attacks by ensuring the cryptographic signature of the Kerberos authentication operations.
| 3. | Click Save.
|
Using Kerberos Kerberos is an open source initiative from MIT and complements the other two pieces of an Open Directory master quite nicely. To put it simply, there are three players in the Kerberos game: a client computer; a computer running a service, such as mail, file sharing, Web, or otherwise; and a computer running as a Key Distribution Center (KDC). All of these interact with each other to provide extremely secure authentication. System administrators like Kerberos because it offers a feature called Single Sign-On (SSO). When a user logs into a computer that is bound to a KDC, the very act of logging in gets them a ticket from the KDC, which they can then use to prove their identity to that server or other computers running "Kerberized" services without entering a password. Mac OS X Server running as an Open Directory master is also a KDC. Every time a user is created in the shared domain, a user principal is created for that user. This is the Kerberos way of saying that user can take part in the authentication process. Most services running on a Mac OS X Server can be Kerberized; that is, they can accept Kerberos authentication for their services. SSL vs. Authenticated Binding Authenticated binding, which is handled by Kerberos connection on OS X, also encrypts the LDAP communications using the Kerberos service ticket. As such there is no reason to both require authenticated binding and SSL as you're double encrypting the LDAP connections. |
The following services can leverage Kerberos in their structure: Secure Shell (ssh) Apple File Sharing protocol (AFP) Sending and receiving email (POP, IMAP, SMTP) Windows sharing (SMB) File Transfer Protocol (FTP) Virtual private networking (VPN) Web (HTTP) Xgrid (Xgrid)
Kerberos is set up for you when you promote to an Open Directory Master. Once a KDC has been established, you can choose any of the above services from the Server Admin tool (except ssh, which is already tuned for Kerberos) and force Kerberos from the authentication methods of these services. Typically all services are already configured to use Kerberos authentication in addition to standard methods in their default state. Forcing Kerberos authentication will not allow Mac OS X computers to connect unless they have previously bound to the server via the LDAPv3 plug-in inside Directory Access, or they have manually edited the edu.mit.Kerberos file located in /Library/Preferences on their Mac OS X computers. Problem is, unless they have bound to a server before, this file may not exist, so there is no template for how to edit the contents. That's why a simple bind to the server is easier; it retrieves the information from the server and creates the file on the Mac OS X computer for you. If you have already set up an Open Directory master and the Mac OS X computer is properly configured to know the DNS information, you can bind the Mac OS X computer to the server and get your edu.mit.Kerberos file, so that you can use Kerberized services. Kerberos Application The Kerberos application, located in /System/Library/CoreServices/, is used to obtain, check on, and destroy tickets. One facet of this application that is not initially useful is that it permits the creation of additional realms via which the user can authenticate. The Edit Realms option is located under the Edit menu. If you are not sure how to add a realm, simply copy what you see in the existing realm and change the domain information. |
To bind Mac OS X to a Mac OS X Server Open Directory master 1. | Make sure your Mac OS X computer's Network preference pane has the correct information to see the domain name information for the Mac OS X Server by checking the DNS and domain name fields.
| 2. | Launch Directory Access and authenticate using the lock in the lower-left corner of the screen to unlock the icon and permit editing (Figure 3.15).
Figure 3.15. Opening Directory Access on a Mac OS X computer. 
| 3. | Click the LDAPv3 check box (if it isn't selected already) and double-click LDAPv3 to open a plug-in configuration dialog (Figure 3.16).
Figure 3.16. The LDAPv3 Plug-in's initial configuration dialog before clicking the Show Options triangle. 
| 4. | Click the Show Options disclosure triangle.
| 5. | Make sure the "Add DHCP-supplied LDAP servers to automatic search policies" check box is deselected (Figure 3.17).
Figure 3.17. The LDAPv3 Plug-in's initial configuration dialog after clicking the Show Options triangle. 
| 6. | Click New to open the New LDAP Connection dialog.
| | | 7. | Enter the fully qualified domain name of the server and click Continue (Figure 3.18).
There is no need to change the computer name.
Figure 3.18. Enter the name of your Mac OS X Server and click Continue. 
| 8. | If you choose authenticated binding, enter a username and password from the shared (LDAP) domain and click Continue (Figure 3.19).
Figure 3.19. You only need to enter a username and password if authentication is enabled on the server. 
| 9. | When a text message near the bottom of the dialog indicates that configuration (binding) is complete, click OK to close this dialog (Figure 3.20).
Figure 3.20. The Continue button changes to an OK button as all options are now dimmed and your configuration is complete. 
| 10. | In the plug-in configuration dialog, review your LDAP entry and change the configuration name, if necessary.
| | | 11. | Click the SSL check box if the server is using SSL with LDAP (ldaps://) and click OK to close this dialog (Figure 3.21).
Figure 3.21. Clicking OK returns you to the LDAP plug-ins main dialog. 
| 12. | In the Directory Access window, click the Authentication tab to make sure your server is part of the authentication path and then click Apply (Figure 3.22).
Figure 3.22. Checking to ensure the Open Directory master was added to the authentication search path. 
| 13. | Open a Terminal window and type id patrick and press the Return key on your keyboard.
Use the short name of a user in your shared (LDAP) domain instead of patrick. If successful, you are now bound to your LDAP domain and have an edu.mit.Kerberos file.
|
Not the Whole Story This is just the tip of the Kerberos iceberg. Please refer to one of several Web sites that deal with a more granular level of Kerberos management: www.afp548.com is one of the best. Also, keep in mind that the LDAP database, the Password Server, and the KDC are all part of an Open Directory master. There are other roles that a Mac OS X Server can become. |
|
