Troubleshooting

Open Directory makes a fairly complex set of systems user-friendly. The goal of this lesson is to provide you with enough architectural knowledge that you will be able to successfully troubleshoot this environment.

One of the first steps in the analysis of any network infrastructure should be to employ a packet sniffer such as Ethereal or tcpdump. Both Password Server and Kerberos leave noncritical portions of their traffic unencrypted, and this data can be highly useful. Sniffing the network will often reveal error codes that are useful when debugging issues.

Log files are another useful tool. Logs are particularly useful in conjunction with a filter such as grep. For instance, to look for all KDC activity, you could execute the following:

more /var/log/system.log | grep krb5kdc

You can also use kdcsetup with a -v n flag to enable verbose logging when manually setting up a KDC. The higher the number after the -v flag, the more verbose the logging.

For a Kerberos system to communicate securely, the KDC, the client, and all kerberized services must decide on a common encryption type. Because different vendors make different choices about Kerberos deployments, this is a common issue when building or maintaining kerberized infrastructures. A system administrator can tell what encryption is used by running klist -ke, which will show the encryption used to generate the keytab files.

Many of the pieces of the Kerberos protocol have a finite life span. For this reason, problems will occur in a Kerberos environment if various systems within the Kerberos infrastructure are not time-synchronized. Also, the clocks of all hosts involved (the KDC, the clients, and any service servers) must be synchronized. Typically, clock skews beyond 300 seconds (5 minutes) will prevent authentication from occurring using an otherwise valid ticket. The clock skew threshold is configurable on the KDC but should not be adjusted, as other issues may occur.

On occasion, Password Server and the KDC might become out of sync. Changing the user's password generally resyncs the authentication records. If this doesn't work, examine the system log for error conditions or processes quitting abruptly, as you may want to use the Kerberos application to change the Kerberos password and pwpolicy to change the Password Server password. If the lack of synchronization persists, checking the logs for both Kerberos and Password Server is in order.

Other common issues revolve around the promotion of standalone servers to Open Directory masters. If the domain name server (DNS) environment is not consistent with forward and reverse records that match, the KDC might not be created. The slapconfig process log should show useful information for tracking down this problem.

Tip

Unless DNS can be verified using the hostname and host commands to ensure that the Open Directory server resolves forward and reverse DNS names and addresses, you should not promote the server to an Open Directory master.

If an administrator cannot authenticate, create Password Server users, or change passwords, you can use NeST with its -NOpassworserver and -hostpasswordserver flags to re-create a Password Server administrator or promote an existing directory-service account to be a Password Server administrator.

To remove the Password Server entry from directory services, execute the command

sudo NeST -NOpasswordserver

To create a Password Server administrator, execute the command

sudo NeST -hostpasswordserver adminname password IPaddress_of_server

Finally, changing the IP address or hostname of an Open Directory master is not a trivial task. The changeip command does a complete, thorough, and safe job of updating every record that needs to be updated. Read the man pages for changeip for complete instructions on how to use this tool.

SSO is intended to make user authentication simple and secure. However, SSO, as implemented by Kerberos, is not as widespread as it could be. This is due in part to the slowness of various services becoming kerberized and the difficulty of integrating Kerberos realms at large. Apple has taken a significant step toward improving the adoption rate of Kerberos by combining the power and security of Kerberos with Mac OS X Server's ease of configuration and administration.

Where Kerberos is not supported, Mac OS X Server provides Password Servera robust, multifeatured, Kerberos-integrated password service that provides SASL support, encryption, and password policies.

These two technologies, along with OpenLDAP, provide a robust, secure, and seamless identification and authentication architecture upon which all other services can be built.