Mac OS X and Mac OS X Server have built-in support for public key certificates, referred to as simply "certificates." More Info Apple documentation for certificates is published as an appendix to the "Mail Service Administration" document available at www.apple.com/server/documentation. This system relies on trusting one or more CAs, such as VeriSign. CAs sign other certificates, vouching for the identity of the certificate holders. Apple distributes the OS with a list of CAs (in /System/Library/Keychains/X509Anchors), which Apple asserts you should trust. In the following illustration, the Keychain Access application displays the partial contents of the X509Anchors keychain. The bottom of the window indicates "98 items," indicating that there are 98 CAs in this X509Anchors keychain preloaded by Apple. Any application using the Mac OS X certificate infrastructure will automatically trust and use a certificate if it is issued or signed by a CA in X509Anchors. Likewise, the application should notify the user if the application encounters a certificate that is not issued or signed by a trusted CA. Different applications have various ways of signaling that a certificate is in use. Safari will display a lock in the upper-right corner of the browser window. Mail will indicate if a message is signed or encrypted with a small icon and text right in the message header. To view a secure website certificate from within Safari, click the lock in the upper-right corner of the Safari window. According the to the following figure, the certificate for the Apple training site (https://train.apple.com) is issued by the VeriSign CA. Even though Mail uses certificates for signing and encrypting messages, you cannot directly examine the certificate from within Mail. When Mail processes a message signed or encrypted with a certificate, Mail automatically imports the certificate into the default keychain, as well as the intermediate issuing CA if necessary. You can view a certificate used for email with Keychain Access. In the following figure, the top part of the window shows that the certificate for ldennison@apple.com was issued by the Thawte Personal Freemail Issuing CA. Tip New to Keychain Access in Tiger is the search feature; you can enter an email address in the search field to highlight its certificate. This search is case-sensitive, which matters if you're searching for something with capital letters like "VeriSign" or "Thawte." You can get a free email certificate at www.thawte.com/email/index.html. Remember, it is up to the application to notify the user if it encounters a certificate that is not signed by a trusted CA. You may run into self-signed certificates like the one shown in the following figure. You have the option to go ahead and trust the certificate anyway, or to stop browsing that site. The default in this dialog is Continue, and unfortunately, some users just go with whatever the default is whenever a window pops up. Train your users to not exchange sensitive information, such as credit card information, with a site that does not have a trusted certificate. If you are using internal sites with certificates signed by an internal CA, prevent the verification hassle by importing the internal CA certificate into the X509Anchors keychain. One way to import a certificate is to double-click the certificate file. Keychain Access will launch and ask if you want to import the certificate into a keychain. Be sure to select the X509Anchors keychain. Because this affects all users on a computer, you will be challenged to authenticate as an administrator before the item will be added to X509Anchors.
Using Certificates to Offer Secure ServicesIf you want to use SSL to protect the services you offer, you first need a certificate for each service. To obtain a certificate, you have some flexibility:
Although the command-line openssl tools are still available to create CAs, certificates, and certificate requests, Mac OS X Server comes with several GUI tools to help you manage certificates. With Certificate Assistant, you can:
Note Apple documentation claims that Certificate Assistant resides in /Applications/Utilities, but it is actually in /System/Library/CoreServices. Apple documentation refers to Server Admin's Certificate Manager. To get to the Certificate Manager, open Server Admin, select the computer (as opposed to any of its services), click the Settings button, then click the Certificates button. This interface displays a list of certificates in /etc/certificates. From this interface, you can:
Note Each fresh installation of Mac OS X Server will come with a default certificate, which is used to enable SSL communications for tools such as Server Admin. This certificate, the private key, and the public key are all in the System keychain. Do not use the default certificate for services like Web services, because it is just a self-signed certificate, and your users should be trained to not trust self-signed certificates. Although you can ask outsiders to download and trust your self-signed CA, they really have no assurance that you are who you say you are and that your CA is trustworthy. Getting a CA to Sign Your CertificateThere are a number of certificate authorities that you can work with to get your CA on the "chain of authorities" so that when users access your site, they are not warned that OS X cannot verify your certificate. The largest of these is VeriSign, at www.verisign.com. Services such as VeriSign will work with you to get your CA added to the various chains of authorities that Web browsers use by default, although not for free, and the cost is based on your needs. Strong AuthenticationTo help overcome some of the weaknesses of authenticating with only a user name and password, Mac OS X and Mac OS X Server support strong multifactor authentication. Typical sources of multifactor authentication are the following:
Mac OS X also ships with support for smart cards you can use to make your login more secure. With a smart card, you need the physical card and a password or PIN to log into your Mac. There are many different types and manufacturers of smart cards, including:
Biometrics are automated methods of recognizing a person based on a physiological or behavioral characteristic, such as the following:
With biometrics, you have no password to lose or forgetyou have a single sign-on without need for Kerberos or PKI infrastructure, and they are difficult to duplicate. The challenges, however, are that they're not yet widely implemented, people have been able to duplicate supposedly unique features, and they have a relatively high cost. Open Directory SecurityIn the first part of this lesson, you learned about the password methods and hash files for local users. Now you'll examine the situation after you promote a server to be an Open Directory master and the LDAP, Password Server, and Kerberos services are all running. This section examines Password Server security before moving on to the new Directory ACLs. Password ServerAs noted before, the Password Server in Mac OS X Server supports a larger group of authentication methods than Mac OS X client does. The following tables note these: Hashes, Authentication Methods, and Services for Local Node and ShadowHash
Hashes, Authentication Methods, and Services for Password Server
Authentication Methods Available with Password Server
The Password Server is turned on only after you configure a server to be an Open Directory master. When you create network users in the Open Directory domain, those users will have the password type of Open Directory. When you inspect the user record, this user should have two values for the AuthenticationAuthority attribute: one for Password Server, and one for Kerberos. In the following figure, the Workgroup Manager inspector is used to examine the AuthenticationAuthority attribute of a network user (in the shared domain), and there are two values. One starts with ;ApplePasswordServer;, and the other starts with ;Kerberosv5;. Here is what Workgroup Manager has in the Advanced sheet for an Open Directory network user. Note The Password Server and Kerberos services do not have a GUI tool; for the most part, they just work. /Library/Logs/slapconfig.log is a good place to look if you run into problems when you promote a server to become an Open Directory master. The mkpassdb and kadmin.local commands are not designed to be used on a daily basis, but can be useful for troubleshooting. Before trying them out for the first time on a production system, practice using these tools on a test system. sudo mkpassdb dump will display each Password Server slot with its corresponding Password ID and short name. With the kadmin.local command, you can examine and manipulate Kerberos principals, policies (which are not normally used), keytabs, and privileges. These tools are not normally used directly. New in Mac OS X v10.4 is LDAP trusted binding, in which the client authenticates itself to the server, and the server authenticates itself to the client. Trusted binding does not by itself provide encryptionsimply mutual authentication. This is critical to prevent a client from authenticating and binding to a rogue directory server that happens to have the same name as the proper one. Setting up a trusted bind from the client is fairly straightforward: Open Directory Access, configure LDAPv3, click the New button, and enter the server name. (It is best practice to use the FQDN, not the IP address.) After you click Continue, Directory Access will attempt to discover information about that LDAP server. If the discovery is successful, the dialog box will change, and you can set up trusted binding. To continue with setting up trusted binding, you must specify the computer name of the client (which should be auto-populated) and an LDAP domain administrator and password.
After you successfully configure trusted binding, the client computer now has a Kerberos principal, a Password Server entry, and a computer record in Open Directory's LDAP database. The computer record has two AuthenticationAuthority values, for the Kerberos and Password Server services. This allows the client and the Open Directory master or replica to mutually authenticate each other. You cannot use DHCP-supplied LDAP server information when you implement trusted binding. Note Because there are now entries for this client, if you need to change the computer name, or replace the client, you may need to manually remove the entries from LDAP in order to bind another client with that computer name. It is best practice to use Directory Access to unbind a client computer before removing it from service. In Directory Access, configure LDAPv3, select the configuration for the LDAP server, and click Delete. You will be prompted to unbind with a domain administrator user name and password. Trusted binding is available only to Mac OS X 10.4 clients and Mac OS X 10.4 servers. In fact, the binding options in Server Admin are advisory only to the directory services of other Tiger clients. The "Require clients to bind to directory" option will not disallow access by clients who have not bound. It does not affect Panther clients, Windows clients, or command-line or third-party LDAP search tools. It does not prevent a Tiger client from manually specifying an LDAP connection. You would set this option to help ensure that client computers are bound correctly, not only to ensure a good user experience, but also to add a degree of security because client and server will mutually authenticate each other. Note If a client is not running Mac OS X 10.4, these options are essentially ignored; all the Security checkboxes and those for requiring trusted binding are advisory only to directory services of Tiger clients. Here are the Open Directory > Policy > Binding options in Server Admin. Note that the checkbox to "Require clients to bind to directory" is selected.
Once that option is enabled, a Tiger client using Directory Access to set up a new LDAP server hosted by a Tiger Open Directory master will be prompted to supply a directory administrator user name and password. Notice that the Manual button is dimmed (but the Cancel button is not). After successfully authenticating, the computer will now bind to the directory using the distinguished name of the computer record that was created in the LDAP directory during the process of setting up the trusted bind. Note that all of the Security Policy options are left unselected by default. These options are useful only if the server supports them. Keeping Your Backed-Up Information SecureMac OS X Tiger makes it easy to back up your Open Directory master with Server Admin. You specify the location, and Server Admin creates a disk image with all the files necessary to back up your Open Directory master information. It is best practice to specify a password for the archive to keep it secret.
This archive contains hashes of passwords from the Password Server and Kerberos, and it contains the hashed password of the rootdn for the LDAP database (in slapd_macosxserver.conf). Treat these files with care. Multiple backups of these files are probably a good idea.
Prevent Anonymous Access to Your DirectoryBy default, the LDAP server will answer all queries it sees. This can be a security concern in some environments; In general, you might not want to allow everyone to harvest information from your shared domain. Although neither passwords nor even hashes of passwords are stored in the LDAP directory, other information is there, such as short names, group membership, and possibly email addresses. Furthermore, new to Tiger is the ability to use Workgroup Manager to store information such as phone number and addressinformation that can be used for social engineering. In previous versions of Mac OS X Server, one way to increase directory security was to add the line disallow bind_anon to /etc/openldap/slapd.conf, use Directory Access at the client to specify a user name for LDAP requests, and enable LDAP over SSL. The disallow bind_anon line is not recommended for use with Mac OS X Server 10.4, because trusted binding requires an initial anonymous access to the LDAP directory. Though it is not supported in the GUI, a better approach is to implement directory access control lists (DACLs). DACLs are a new feature in Tiger server. The implementation of DACLs introduces the ability to store ACLs right in the LDAP directory itself. One big advantage of this method is that the ACLs can easily be replicated to Open Directory replicas; previously, you would have had to edit config files at each server if you wanted to make any change in access. Another advantage is that since the information is in the LDAP directory, it's easy to export and import DACLs via LDIF files. More Info For more info on access control lists with OpenLDAP, see www.openldap.org/doc/admin22/slapdconfig.html#Access%20Control. Note Tiger's implementation of OpenLDAP is 2.2; make sure you consult the correct documentation. This section of /etc/openldap/slapd_macosxserver.conf points to the location of the default DACL: # This file should NOT be world readable. # This file is maintained by Server Admin. # # Access Controls access specified-in-directory apple-acl "cn=default,cn=accesscontrols,dc=mainserver, dc=pretendco,dc=com" Note Though we can't show it properly on the printed page, you should type the last part of the previous command as one line without a paragraph break. Here is an Inspector view in Workgroup Manager of the default DACL. The AcessControlEntry attribute in this example has four entries. Each entry consists of a number, a colon, and the rule itself. This example controls access to userPassword, apple-user-authenticationhint, apple-user-picture, and * for everything else not specified. In order to better view an attribute's entry, you can highlight that entry and click the Edit button. Here are the general steps to disable anonymous binding and queries to your LDAP server, yet allow enough access for regular operation:
To disable most anonymous queries to the LDAP database, here are some suggested AccessControlEntry values to add to enable anonymous access where necessary: Note Again, for each command shown here, type one line of text without paragraph breaks.
After you update an AccessControlEntry, the LDAP server will automatically use the new settings. To test whether or not your updated DACLs prevent anonymous access to your LDAP Directory, use ldapsearch with the x flag: ldapsearch -x -h mainserver.pretendco.com -b cn=users,dc=www,dc=ssh22,dc=com uid=diradmin Update Directory Access on the Open Directory MasterThe Open Directory master must be updated to no longer access itself anonymously:
Note The distinguished name should be in the form of uid=diradmin,cn=users,dc=mainserver,dc=pretendco,dc=com. |