Configuring the Open Directory Password Server
| As we have seen, Kerberos handles authentication in Mac OS X and Mac OS X Server. But what if a service cannot utilize Kerberos? What if another authentication method must be used? Should Mac OS X Server revert to older clear-text passwords? That would be very insecure. This section explains the fundamentals behind the use of and management surrounding Password Server. Mac OS X Server includes Password Server, which provides authentication for services that cannot use Kerberos. Password Server FundamentalsIn a perfect world, every service would be kerberized. However, adopting Kerberos is a fairly complex and time-consuming process, and unfortunately, some widely adopted services such as Point-to-Point Tunneling Protocol (PPTP) are not easily kerberized. To support these legacy services, Apple includes a standards-based password server. The PasswordService process offers the following, all of which will be explained later in this section:
Password Server stores passwords in "slots" in an encrypted database separate from the user record. Because Password Server is available across the network, it can serve as a centralized authentication server when part of an Open Directory master. Password Server is always enabled when an Open Directory master is created, giving you the added benefit of protecting user credentials from a local attack and of supporting protocols like MS-CHAPv2 and CRAM-MD5, which are required by some Mac OS X Server services. Password policies, in addition to being per-user policies, are represented in the graphical user interface and can be enforced on a global scale. (Policies will be discussed later in this lesson.) Furthermore, Password Server synchronizes with the Apple KDC to simplify user management and secure multimaster replication has been added to support improved redundancy in distributed organizations. In a nutshell, these two authentication services, Password Server and Kerberos, can use known command-line tools to stay synchronized with respect to users' passwords. The user policies however, do not synchronize. Password Server ArchitecturePassword Server's daemon, PasswordService, is located in /usr/sbin and is started by launchd as specified by /System/Library/LaunchDaemons, which also monitors the process in case it needs to be restarted. Its primary database is located in /var/db/authserver/authservermain. This is a sensitive file, because it contains user secrets in their respective slots in that file. The authserverfree file, which resides in the same folder, contains a list of free slots in the database, and the authserverreplicas file, in the same folder, keeps track of all replicas. (Replicas are covered in Lesson 10, "Replication.") The following figure shows how the PasswordService process reads from its main files, including com.apple.passwrodserver.plist. It shows the log files to which PasswordService writes, as well as two command-line tools, mkpassdb and pwpolicy, that can be used to work with PasswordService.  The PasswordService daemon logs fairly verbosely, mostly to the ApplePasswordServer. Error.log, ApplePasswordServer.Server.log, and ApplePasswordServer.Replication.log, all located in /Library/Logs/PasswordService. In some cases, it also logs to syslog. By default, Password Server listens on ports 106 (3com-tsmux) and 3659 (apple-sasl). Pure Mac OS X v10.3 and later deployments should consider disabling port 106 for Password Server, because this port is generally used by other services. However, doing so will lock out Mac OS X v10.2 clients. You may disable Password Server from listening on port 106 by removing the 106 value from the ListenerPorts array in /Library/Preferences/ com.apple.passwordserver.plist. Like many other text-based services, it is feasible to use the telnet command to issue commands on the Password Server's ports and gather a large amount of data. It's not necessarily a security risk, but a system administrator should be aware of what data is available. Password Server uses a 128-bit hex ID to keep track of users in its database. The first administrator always has a value of 0x00000000000000000000000000000001, but if an administrator's short name is known, his or her ID can be obtained by issuing the GETIDBYNAME command to the Password Server port: mainserver:~ diradmin$ telnet 127.0.0.1 apple-sasl Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK ApplePasswordServer 10.1.0.1 password server at mainserver.pretendco.com ready GETIDBYNAME diradmin +OK 0x403087be17ede7a50000000c0000000c The Password Server ID is also part of the user's record in the authAuthority attribute. In a default configuration, a list of Password Server IDs can also be obtained by anonymously querying the Open Directory master with the following command: ldapsearch -x -h serverhostname -b "dc=searchbase,dc=tld" objectclass=apple-user authAuthority Simple Authentication and Security Layer (SASL)SASL is a method for adding authentication support to connection-based protocols, such as LDAP. SASL provides a "pluggable authentication" architecture to Password Server. Pluggable authentication means that the client and server may be configured to negotiate and use a variety of mechanisms for authentication (CRAM-MD5, Digest-MD5, NTLMv1, and so on). Clients can use different methods of authentication if Password Server is configured to support the desired protocols. In addition to CRAM-MD5 and NTLMv1, which ship with the standard Carnegie-Mellon SASL distribution, Apple has added a number of other plug-ins to support applications:
SASL methods are classified as strong or weak. Weak methods may be used only for authentication, while strong methods can be used to write data to the Password Server database. The mechanisms SMB-NT, SMB-LAN-MANAGER, and APOP are always considered weak. Data regarding available authentication methods can be gathered by using the telnet command on the Password Server port and issuing the LIST command: mainserver:~ diradmin$ telnet mainserver.pretendco.com apple-sasl Trying 10.1.17.1... Connected to mainserver.pretendco.com. Escape character is '^]'. +OK ApplePasswordServer 10.1.0.0 password server at 0.0.0.0 ready LIST +OK (SASL "SMB-NTLMv2" "SMB-NT" "SMB-LAN-MANAGER" "MS-CHAPv2" "OTP" "NTLM" "GSSAPI" "DIGEST-MD5" "CRAM-MD5" "WEBDAV-DIGEST" "DHX" "APOP") Password Server PoliciesBecause Password Server acts as a central authentication authority, it is a convenient place to enforce password policies on a per-user basis. One way to do this is in the Advanced pane of the user's record in Workgroup Manager. The Policy pane of Open Directory Settings in Server Admin lets you enforce global policies ranging from character restrictions to password aging. Although many policies can be configured on both a per-user and a global basis, some are limited to one or the other. The following figure shows the global possibilities that exist when managing password policies with user accounts located on Mac OS X Server. Global policy options are as follows:
Per-user policy options are:
Global and per-user policy options are:
When a global and a per-user policy have been set for the same parameter, the per-user policy takes precedence. To ensure that it has been recorded correctly, you can view the policy by using the telnet command to connect to Password Server and issuing the GETPOLICY and GETGLOBALPOLICY commands. GETPOLICY requires a user's Password Server ID as an argument: mainserver:~ diradmin$ telnet 127.0.0.1 apple-sasl Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. +OK ApplePasswordServer 10.1.0.0 password server at mainserver.pretendco.com ready getpolicy 0x4284e8af3700c23a0000000200000002 +OK isDisabled=0 isAdminUser=1 newPasswordRequired=0 usingHistory=0 canModifyPassword forSelf=1 usingExpirationDate=0 usingHardExpirationDate=0 requiresAlpha=0 requiresNumeric=0 expirationDateGMT=4294967295 hardExpireDateGMT=4294967295 maxMinutesUntilChangeP assword=0 maxMinutesUntilDisabled=0 maxMinutesOfNonUse=0 maxFailedLoginAttempts=0 minChars=0 maxChars=0 passwordCannotBeName=0 requiresMixedCase=0 notGuessablePattern=0 isSessionKeyAgent=0 GETGLOBALPOLICY +OK usingHistory=0 canModifyPasswordforSelf=1 usingExpirationDate=0 usingHardE xpirationDate=0 requiresAlpha=0 requiresNumeric=0 expirationDateGMT=4294967295 hardExpireDateGMT=4294967295 maxMinutesUntilChangePassword=0 maxMinutesUntilD isabled=0 maxMinutesOfNonUse=0 maxFailedLoginAttempts=3 minChars=0 maxChars=0 passwordCannotBeName=0 requiresMixedCase=0 newPasswordRequired=0 minutesUntilFailedLogin Reset=0 notGuessablePattern=0 More Info For an explanation of the output from GETPOLICY and GETGLOBALPOLICY, see the man page for pwpolicy. Password Server UtilitiesApple provides several command-line utilities for managing Password Server data and configuration. Chief among them are pwpolicy, mkpassdb, and NeST. The pwpolicy command, among other things, can set either global or per-user policies in Password Server. The following table lists various flags for pwpolicy.
Note pwpolicy can also be used on Mac OS X and Mac OS X Server, although not all policies will be effective.
Password Server and KDC SynchronizationAs you have seen, Mac OS X Server manages two authentication authorities: Kerberos and Password Server. These authentication authorities store their user secrets in different databases and different formats, making it necessary for the two authentication authorities to be transparent to the user. But when a user changes his or her password with the Kerberos utility, how does the Password Server know? If the user changes the password in the Password Server database, how does the KDC know? To provide a seamless experience for the user, Apple has instituted a two-way password synchronization process, so that passwords may be safely changed either in Password Server or in Kerberos. Passwords and some policies changed in Password Server are written to the KDC automatically with the kadmin.local command. PasswordService executes kadmin.local, sending the modifications to the KDC using native Kerberos protocols securely so that user passwords cannot be seen in the process listing. Note While some password policies initiated in Password Server are synchronized with the KDC, password policies initiated in the KDC are not synchronized with Password Server. When passwords are changed in Kerberos via the kpasswd command, kadmin, kadmin.local, or the Kerberos application, they are always sent to the kadmind process. In Mac OS X, kadmind is started, like krb5kdc and PasswordService, by launchd, with an Apple-specific passwordserver flag. When run with the -passwordserver flag, kadmind knows to call the mkpassdb utility to update Password Server, similar to Password Server's use of kadmin. local except that the password policy and expiration data set with Kerberos tools are not propagated to Password Server. Configuring the KDC and Password ServerAt the center of Open Directory's authentication capabilities is Apple's automated configuration architecture, which is responsible for setting up the LDAP, Password Server, and Kerberos functions for the server. In the previous lesson, you saw how changing the directory role of your Mac OS X Server to an Open Directory Master utilized a process called slapconfig to create the LDAP database, tweak a few configuration files, and create an LDAP administrator with the -createldapmasterdomain flag. slapconfig was not finished completing the process of changing the role of the server. After it finishes setting up the LDAP server, it sets up the KDC and configures it to work with Password Server. The following is a detailed description of the Password Server and KDC configuration process:
Open Directory Configuration RecordsThe KDC and Password portion of the Open Directory master creation process results in a number of configuration records stored in the /config directory:
These records are useful in understanding the way Open Directory coordinates Kerberos and Password Server configuration and replication. In the following figure showing the Workgroup Manager, click the bullseye on the All Records tab to display the Inspector tab and view all config records, including the KerberosClient, KerberosKDC, and passwordserver records.  apple-user authAuthority Attribute ContentsThe authAuthority attribute defined by the apple-user object class tells Mac OS X how to authenticate Open Directory users. Users in an Open Directory master should have at least two authAuthority values: one for the KDC and one for Password Server. The loginwindow process has been modified to key off a Kerberos authentication authority in the user record. If Mac OS X sees a Kerberos authentication authority, it will attempt to autoconfigure (with the kerberosautoconfig utility) based on data in the /config/ KerberosClient record in that user's domain. Password Server authAuthority values include the key ;ApplePasswordServer;, the user's Password Server ID, the RSA public key used to encrypt data sent to Password Server, and Password Server's IP address. A Kerberos authAuthority value also contains password server data. Additionally, it uses a ;Kerberosv5; key and includes the Kerberos principal and realm. An example of a user's two authAuthority attribute values are as follows:
Note The bold part of the Kerberos authAuthority attribute value is the Kerberos portion, and the italicized part is the Password Server portion, even though both of these exist in the Kerberos attribute value. |
expiration DateGMT=12/01/2005"
EAN: 2147483647
Pages: 258