LDAP in the Solaris Operating Environment[c] Deploying Secure Directory Services
| This section discusses the GSSAPI mechanism, in particular, Kerberos v5 and how this works in conjunction with the Sun ONE Directory Server 5.2 software and what is involved in implementing such a solution. Please be aware that this is not a trivial task. It's worth taking a brief look at the relationship between the Generic Security Services Application Program Interface (GSSAPI) and Kerberos v5. The GSSAPI does not actually provide security services itself. Rather, it is a framework that provides security services to callers in a generic fashion, with a range of underlying mechanisms and technologies such as Kerberos v5. The current implementation of the GSSAPI only works with the Kerberos v5 security mechanism. The best way to think about the relationship between GSSAPI and Kerberos is in the following manner: GSSAPI is a network authentication protocol abstraction that allows Kerberos credentials to be used in an authentication exchange. Kerberos v5 must be installed and running on any system on which GSSAPI-aware programs are running. The support for the GSSAPI is made possible in the directory server through the introduction of a new SASL library, which is based on the Cyrus CMU implementation. Through this SASL framework, DIGEST-MD5 is supported as explained previously, and GSSAPI which implements Kerberos v5. Additional GSSAPI mechanisms do exist. For example, GSSAPI with SPNEGO support would be GSS-SPNEGO. Other GSS mechanism names are based on the GSS mechanisms OID.
Note The Sun ONE Directory Server 5.2 software only supports the use of GSSAPI on Solaris OE. There are implementations of GSSAPI for other operating systems (for example, Linux), but the Sun ONE Directory Server 5.2 software does not use them on platforms other than the Solaris OE.
Understanding GSSAPI
The Generic Security Services Application Program Interface (GSSAPI) is a standard interface, defined by RFC 2743, that provides a generic authentication and secure messaging interface, whereby these security mechanisms can be plugged in. The most commonly referred to GSSAPI mechanism is the Kerberos mechanism that is based on secret key cryptography. One of the main aspects of GSSAPI is that it allows developers to add secure authentication and privacy (encryption and or integrity checking) protection to data being passed over the wire by writing to a single programming interface. This is shown in FIGURE 3-2. Figure 3-2. GSSAPI Layers
The underlying security mechanisms are loaded at the time the programs are executed, as opposed to when they are compiled and built. In practice, the most commonly used GSSAPI mechanism is Kerberos v5. The Solaris OE provides a few different flavors of Diffie - Hellman GSSAPI mechanisms, which are only useful to NIS+ applications. What can be confusing is that developers might write applications that write directly to the Kerberos API, or they might write GSSAPI applications that request the Kerberos mechanism. There is a big difference, and applications that talk Kerberos directly cannot communicate with those that talk GSSAPI. The wire protocols are not compatible, even though the underlying Kerberos protocol is in use. An example is telnet with Kerberos is a secure telnet program that authenticates a telnet user and encrypts data, including passwords exchanged over the network during the telnet session. The authentication and message protection features are provided using Kerberos. The telnet application with Kerberos only uses Kerberos, which is based on secret-key technology. However, a telnet program written to the GSSAPI interface can use Kerberos as well as other security mechanisms supported by GSSAPI. The Solaris OE does not deliver any libraries that provide support for third-party companies to program directly to the Kerberos API. The goal is to encourage developers to use the GSSAPI. Many open -source Kerberos implementations (MIT, Heimdal) allow users to write Kerberos applications directly.
Note On the wire , the GSSAPI is compatible with Microsoft's SSPI and thus GSSAPI applications can communicate with Microsoft applications that use SSPI and Kerberos.
The GSSAPI is preferred because it is a standardized API, whereas Kerberos is not. This means that the MIT Kerberos development team might change the programming interface anytime , and any applications that exist today might not work in the future without some code modifications. Using GSSAPI avoids this problem. Another benefit of GSSAPI is its pluggable feature, which is a big benefit, especially if a developer later decides that there is a better authentication method than Kerberos, because it can easily be plugged into the system and the existing GSSAPI applications should be able to use it without being recompiled or patched in any way. Understanding Kerberos v5
Kerberos is a network authentication protocol designed to provide strong authentication for client/server applications by using secret-key cryptography. Originally developed at the Massachusetts Institute of Technology, it is included in the Solaris OE to provide strong authentication for Solaris OE network applications. In addition to providing a secure authentication protocol, Kerberos also offers the ability to add privacy support (encrypted data streams) for remote applications such as telnet , ftp , rsh , rlogin , and other common UNIX network applications. In the Solaris OE, Kerberos can also be used to provide strong authentication and privacy support for Network File Systems (NFS), allowing secure and private file sharing across the network. Because of its widespread acceptance and implementation in other operating systems, including Windows 2000, HP-UX, and Linux, the Kerberos authentication protocol can interoperate in a heterogeneous environment, allowing users on machines running one OS to securely authenticate themselves on hosts of a different OS. The Kerberos software is available for Solaris OE versions 2.6, 7, 8, and 9 in a separate package called the Sun Enterprise Authentication Mechanism (SEAM) software. For Solaris 2.6 and Solaris 7 OE, Sun Enterprise Authentication Mechanism software is included as part of the Solaris Easy Access Server 3.0 (Solaris SEAS) package. For Solaris 8 OE, the Sun Enterprise Authentication Mechanism software package is available with the Solaris 8 OE Admin Pack. For Solaris 2.6 and Solaris 7 OE, the Sun Enterprise Authentication Mechanism software is freely available as part of the Solaris Easy Access Server 3.0 package available for download from: http://www.sun.com/software/solaris/7/ds/ds-seas. For Solaris 8 OE systems, Sun Enterprise Authentication Mechanism software is available in the Solaris 8 OE Admin Pack, available for download from: http://www.sun.com/ bigadmin /content/adminPack/index.html. For Solaris 9 OE systems, Sun Enterprise Authentication Mechanism software is already installed by default and contains the following packages listed in TABLE 3-1. Table 3-1. Solaris 9 OE Kerberos v5 Packages
All of these Sun Enterprise Authentication Mechanism software distributions are based on the MIT KRB5 Release version 1.0. The client programs in these distributions are compatible with later MIT releases (1.1, 1.2) and with other implementations that are compliant with the standard. How Kerberos Works
The following is an overview of the Kerberos v5 authentication system. From the user's standpoint, Kerberos v5 is mostly invisible after the Kerberos session has been started. Initializing a Kerberos session often involves no more than logging in and providing a Kerberos password. The Kerberos system revolves around the concept of a ticket . A ticket is a set of electronic information that serves as identification for a user or a service such as the NFS service. Just as your driver's license identifies you and indicates what driving permissions you have, so a ticket identifies you and your network access privileges. When you perform a Kerberos-based transaction (for example, if you use rlogin to log in to another machine), your system transparently sends a request for a ticket to a Key Distribution Center, or KDC. The KDC accesses a database to authenticate your identity and returns a ticket that grants you permission to access the other machine. Transparently means that you do not need to explicitly request a ticket. Tickets have certain attributes associated with them. For example, a ticket can be forwardable (which means that it can be used on another machine without a new authentication process), or postdated (not valid until a specified time). How tickets are used (for example, which users are allowed to obtain which types of tickets) is set by policies that are determined when Kerberos is installed or administered.
Note You will frequently see the terms credential and ticket . In the Kerberos world, they are often used interchangeably. Technically, however, a credential is a ticket plus the session key for that session.
Initial Authentication
Kerberos authentication has two phases, an initial authentication that allows for all subsequent authentications, and the subsequent authentications themselves. A client (a user, or a service such as NFS) begins a Kerberos session by requesting a ticket-granting ticket (TGT) from the Key Distribution Center (KDC). This request is often done automatically at login. A ticket-granting ticket is needed to obtain other tickets for specific services. Think of the ticket-granting ticket as something similar to a passport. Like a passport, the ticket-granting ticket identifies you and allows you to obtain numerous "visas," where the "visas" (tickets) are not for foreign countries , but for remote machines or network services. Like passports and visas, the ticket-granting ticket and the other various tickets have limited lifetimes. The difference is that Kerberized commands notice that you have a passport and obtain the visas for you. You don't have to perform the transactions yourself. The KDC creates a ticket-granting ticket and sends it back, in encrypted form, to the client. The client decrypts the ticket-granting ticket using the client's password. Now in possession of a valid ticket-granting ticket, the client can request tickets for all sorts of network operations for as long as the ticket-granting ticket lasts. This ticket usually lasts for a few hours. Each time the client performs a unique network operation, it requests a ticket for that operation from the KDC. Subsequent Authentications
The client requests a ticket for a particular service from the KDC by sending the KDC its ticket-granting ticket as proof of identity.
Principals
A client is identified by its principal. A principal is a unique identity to which the KDC can assign tickets. A principal can be a user, such as joe , or a service, such as NFS. By convention, a principal name is divided into three parts : the primary, the instance, and the realm. A typical principal could be, for example, lucy/admin@EXAMPLE.COM , where: lucy is the primary. The primary can be a user name, as shown here, or a service, such as NFS. The primary can also be the word host , which signifies that this principal is a service principal that is set up to provide various network services. admin is the instance. An instance is optional in the case of user principals, but it is required for service principals. For example, if the user lucy sometimes acts as a system administrator, she can use lucy/admin to distinguish herself from her usual user identity. Likewise, if Lucy has accounts on two different hosts, she can use two principal names with different instances (for example, lucy/california.example.com and lucy/ boston .example.com ). Realms
A realm is a logical network, similar to a domain, which defines a group of systems under the same master KDC. Some realms are hierarchical (one realm being a superset of the other realm). Otherwise , the realms are non-hierarchical (or direct) and the mapping between the two realms must be defined. Realms and KDC Servers
Each realm must include a server that maintains the master copy of the principal database. This server is called the master KDC server. Additionally, each realm should contain at least one slave KDC server, which contains duplicate copies of the principal database. Both the master KDC server and the slave KDC server create tickets that are used to establish authentication. Understanding the Kerberos KDC
The Kerberos Key Distribution Center (KDC) is a trusted server that issues Kerberos tickets to clients and servers to communicate securely. A Kerberos ticket is a block of data that is presented as the user's credentials when attempting to access a Kerberized service. A ticket contains information about the user's identity and a temporary encryption key, all encrypted in the server's private key. In the Kerberos environment, any entity that is defined to have a Kerberos identity is referred to as a principal . A principal may be an entry for a particular user, host, or service (such as NFS or FTP) that is to interact with the KDC. Most commonly, the KDC server system also runs the Kerberos Administration Daemon, which handles administrative commands such as adding, deleting, and modifying principals in the Kerberos database. Typically, the KDC, the admin server, and the database are all on the same machine, but they can be separated if necessary. Some environments may require that multiple realms be configured with master KDCs and slave KDCs for each realm. The principals applied for securing each realm and KDC should be applied to all realms and KDCs in the network to ensure that there isn't a single weak link in the chain. One of the first steps to take when initializing your Kerberos database is to create it using the kdb5_util command, which is located in /usr/sbin . When running this command, the user has the choice of whether to create a stash file or not. The stash file is a local copy of the master key that resides on the KDC's local disk. The master key contained in the stash file is generated from the master password that the user enters when first creating the KDC database. The stash file is used to authenticate the KDC to itself automatically before starting the kadmind and krb5kdc daemons (for example, as part of the machine's boot sequence). If a stash file is not used when the database is created, the administrator who starts up the krb5kdc process will have to manually enter the master key (password) every time they start the process. This may seem like a typical trade off between convenience and security, but if the rest of the system is sufficiently hardened and protected, very little security is lost by having the master key stored in the protected stash file. It is recommended that at least one slave KDC server be installed for each realm to ensure that a backup is available in the event that the master server becomes unavailable, and that slave KDC be configured with the same level of security as the master. Currently, the Sun Kerberos v5 Mechanism utility, kdb5_util , can create three types of keys, DES-CBC-CRC, DES-CBC-MD5 , and DES-CBC-RAW . DES-CBC stands for DES encryption with Cipher Block Chaining and the CRC, MD5, and RAW designators refer to the checksum algorithm that is used. By default, the key created will be DES-CBC-CRC , which is the default encryption type for the KDC. The type of key created is specified on the command line with the -k option (see the kdb5_util (1M) man page). Choose the password for your stash file very carefully , because this password can be used in the future to decrypt the master key and modify the database. The password may be up to 1024 characters long and can include any combination of letters , numbers , punctuation, and spaces. The following is an example of creating a stash file: kdc1 # /usr/sbin/kdb5_util create -r EXAMPLE.COM -s Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM' master key name 'K/M@EXAMPLE.COM' You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: master_key Re-enter KDC database master key to verify: master_key Notice the use of the -s argument to create the stash file. The location of the stash file is in the /var/krb5 . The stash file appears with the following mode and ownership settings: kdc1 # cd /var/krb5 kdc1 # ls -l -rw------- 1 root other 14 Apr 10 14:28 .k5.EXAMPLE.COM
Note The directory used to store the stash file and the database should not be shared or exported.
Secure Settings in the KDC Configuration File
The KDC and Administration daemons both read configuration information from /etc/krb5/kdc.conf . This file contains KDC-specific parameters that govern overall behavior for the KDC and for specific realms. The parameters in the kdc.conf file are explained in detail in the kdc.conf(4) man page. The kdc.conf parameters describe locations of various files and ports to use for accessing the KDC and the administration daemon. These parameters generally do not need to be changed, and doing so does not result in any added security. However, there are some parameters that may be adjusted to enhance the overall security of the KDC. The following are some examples of adjustable parameters that enhance security.
The Solaris OE has a default system dictionary that is used by the spell program that may also be used by the KDC as a dictionary of common passwords. The location of this file is: /usr/share/lib/dict/words . Other dictionaries may be substituted. The format is one word or phrase per line. The following is a Kerberos v5 /etc/krb5/kdc.conf example with suggested settings: # Copyright 1998-2002 Sun Microsystems, Inc. All rights reserved. # Use is subject to license terms. # #ident "@(#)kdc.conf 1.2 02/02/14 SMI" [kdcdefaults] kdc_ports = 88,750 [realms] ___default_realm___ = { profile = /etc/krb5/krb5.conf database_name = /var/krb5/principal admin_keytab = /etc/krb5/kadm5.keytab acl_file = /etc/krb5/kadm5.acl kadmind_port = 749 max_life = 8h 0m 0s max_renewable_life = 7d 0h 0m 0s default_principal_flags = +preauth Needs moving -- dict_file = /usr/share/lib/dict/words } Access Control
The Kerberos administration server allows for granular control of the administrative commands by use of an access control list (ACL) file ( /etc/krb5/kadm5.acl ). The syntax for the ACL file allows for wildcarding of principal names so it is not necessary to list every single administrator in the ACL file. This feature should be used with great care. The ACLs used by Kerberos allow privileges to be broken down into very precise functions that each administrator can perform. If a certain administrator only needs to be allowed to have read-access to the database then that person should not be granted full admin privileges. Below is a list of the privileges allowed:
Adding Administrators
After the ACLs are set up, actual administrator principals should be added to the system. It is strongly recommended that administrative users have separate /admin principals to use only when administering the system. For example, user Lucy would have two principals in the database - lucy@REALM and lucy/admin@REALM . The /admin principal would only be used when administering the system, not for getting ticket-granting-tickets (TGTs) to access remote services. Using the /admin principal only for administrative purposes minimizes the chance of someone walking up to Joe's unattended terminal and performing unauthorized administrative commands on the KDC. Kerberos principals may be differentiated by the instance part of their principal name. In the case of user principals, the most common instance identifier is /admin . It is standard practice in Kerberos to differentiate user principals by defining some to be /admin instances and others to have no specific instance identifier (for example, lucy/admin@REALM versus lucy@REALM ). Principals with the /admin instance identifier are assumed to have administrative privileges defined in the ACL file and should only be used for administrative purposes. A principal with an /admin identifier which does not match up with any entries in the ACL file will not be granted any administrative privileges, it will be treated as a non-privileged user principal. Also, user principals with the /admin identifier are given separate passwords and separate permissions from the non-admin principal for the same user. The following is a sample /etc/krb5/kadm5.acl file: # Copyright (c) 1998-2000 by Sun Microsystems, Inc. # All rights reserved. # #pragma ident "@(#)kadm5.acl 1.1 01/03/19 SMI" # lucy/admin is given full administrative privilege lucy/admin@EXAMPLE.COM * # # tom/admin user is allowed to query the database (d), listing principals # (l), and changing user passwords (c) # tom/admin@EXAMPLE.COM dlc
Note It is highly recommended that the kadm5.acl file be tightly controlled and that users be granted only the privileges they need to perform their assigned tasks .
Creating Host Keys
Creating host keys for systems in the realm such as slave KDCs is performed the same way that creating user principals is performed. However, the -randkey option should always be used, so no one ever knows the actual key for the hosts. Host principals are almost always stored in the keytab file, to be used by root-owned processes that wish to act as Kerberos services for the local host. It is rarely necessary for anyone to actually know the password for a host principal because the key is stored safely in the keytab and is only accessible by root-owned processes, never by actual users. When creating keytab files, the keys should always be extracted from the KDC on the same machine where the keytab is to reside using the ktadd command from a kadmin session. If this is not feasible , take great care in transferring the keytab file from one machine to the next . A malicious attacker who possesses the contents of the keytab file could use these keys from the file in order to gain access to another user or services credentials. Having the keys would then allow the attacker to impersonate whatever principal that the key represented and further compromise the security of that Kerberos realm. Some suggestions for transferring the keytab are to use Kerberized, encrypted ftp transfers, or to use the secure file transfer programs scp or sftp offered with the SSH package (http://www.openssh.org). Another safe method is to place the keytab on a removable disk, and hand-deliver it to the destination. Hand delivery does not scale well for large installations, so using the Kerberized ftp daemon is perhaps the most convenient and secure method available. Using NTP to Synchronize Clocks
All servers participating in the Kerberos realm need to have their system clocks synchronized to within a configurable time limit (default 300 seconds). The safest, most secure way to systematically synchronize the clocks on a network of Kerberos servers is by using the Network Time Protocol (NTP) service. The Solaris OE comes with an NTP client and NTP server software ( SUNWntpu package). See the ntpdate (1M) and xntpd (1M) man pages for more information on the individual commands. For more information on configuring NTP, refer to the following Sun BluePrints OnLine NTP articles:
It is critical that the time be synchronized in a secure manner. A simple denial of service attack on either a client or a server would involve just skewing the time on that system to be outside of the configured clock skew value, which would then prevent anyone from acquiring TGTs from that system or accessing Kerberized services on that system. The default clock-skew value of five minutes is the maximum recommended value. The NTP infrastructure must also be secured, including the use of server hardening for the NTP server and application of NTP security features. Using the Solaris Security Toolkit software (formerly known as JASS) with the secure.driver script to create a minimal system and then installing just the necessary NTP software is one such method. The Solaris Security Toolkit software is available at: http://www.sun.com/security/jass/ Documentation on the Solaris Security Toolkit software is available at: http://www.sun.com/security/blueprints Establishing Password Policies
Kerberos allows the administrator to define password policies that can be applied to some or all of the user principals in the realm. A password policy contains definitions for the following parameters:
These values can be set as a group and stored as a single policy. Different policies can be defined for different principals. It is recommended that the minimum password length be set to at least 8 and that at least 2 classes be required. Most people tend to choose easy-to-remember and easy-to-type passwords, so it is a good idea to at least set up policies to encourage slightly more difficult-to-guess passwords through the use of these parameters. Setting the Maximum Password Lifetime value may be helpful in some environments, to force people to change their passwords periodically. The period is up to the local administrator according to the overriding corporate security policy used at that particular site. Setting the Saved Password History value combined with the Minimum Password Lifetime value prevents people from simply switching their password several times until they get back to their original or favorite password. The maximum password length supported is 255 characters, unlike the UNIX password database which only supports up to 8 characters. Passwords are stored in the KDC encrypted database using the KDC default encryption method, DES-CBC-CRC . In order to prevent password guessing attacks, it is recommended that users choose long passwords or pass phrases. The 255 character limit allows one to choose a small sentence or easy to remember phrase instead of a simple one-word password. It is possible to use a dictionary file that can be used to prevent users from choosing common, easy-to-guess words (see "Secure Settings in the KDC Configuration File" on page 70). The dictionary file is only used when a principal has a policy association, so it is highly recommended that at least one policy be in effect for all principals in the realm. The following is an example password policy creation: If you specify a kadmin command without specifying any options, kadmin displays the syntax (usage information) for that command. The following code box shows this, followed by an actual add_policy command with options. kadmin: add_policy usage: add_policy [options] policy options are: [-maxlife time] [-minlife time] [-minlength length] [-minclasses number] [-history number] kadmin: add_policy -minlife "1 hour" -maxlife "90 days" -minlength 8 -minclasses 2 -history 3 passpolicy kadmin: get_policy passpolicy Policy: passpolicy Maximum password life: 7776000 Minimum password life: 3600 Minimum password length: 8 Minimum number of password character classes: 2 Number of old keys kept: 3 Reference count: 0 This example creates a password policy called passpolicy which enforces a maximum password lifetime of 90 days, minimum length of 8 characters, a minimum of 2 different character classes (letters, numbers, punctuation), and a password history of 3. To apply this policy to an existing user, modify the following: kadmin: modprinc -policy passpolicy lucyPrincipal "lucy@EXAMPLE.COM" modified . To modify the default policy that is applied to all user principals in a realm, change the following: kadmin: modify_policy -maxlife "90 days" -minlife "1 hour" -minlength 8 -minclasses 2 -history 3 default kadmin: get_policy default Policy: default Maximum password life: 7776000 Minimum password life: 3600 Minimum password length: 8 Minimum number of password character classes: 2 Number of old keys kept: 3 Reference count: 1 The Reference count value indicates how many principals are configured to use the policy.
Note The default policy is automatically applied to all new principals that are not given the same password as the principal name when they are created. Any account with a policy assigned to it is uses the dictionary (defined in the dict_file parameter in /etc/krb5/kdc.conf ) to check for common passwords.
Backing Up a KDC
Backups of a KDC system should be made regularly or according to local policy. However, backups should exclude the /etc/krb5/krb5.keytab file. If the local policy requires that backups be done over a network, then these backups should be secured either through the use of encryption or possibly by using a separate network interface that is only used for backup purposes and is not exposed to the same traffic as the non-backup network traffic. Backup storage media should always be kept in a secure, fireproof location. Monitoring the KDC
Once the KDC is configured and running, it should be continually and vigilantly monitored . The Sun Kerberos v5 software KDC logs information into the /var/krb5/kdc.log file, but this location can be modified in the /etc/krb5/krb5.conf file, in the logging section. [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log The KDC log file should have read and write permissions for the root user only, as follows : -rw------ 1 root other 750 25 May 10 17:55 /var/krb5/kdc.log Kerberos Options
The /etc/krb5/krb5.conf file contains information that all Kerberos applications use to determine what server to talk to and what realm they are participating in. Configuring the krb5.conf file is covered in the Sun Enterprise Authentication Mechanism Software Installation Guide . Also refer to the krb5.conf (4) man page for a full description of this file. The appdefaults section in the krb5.conf file contains parameters that control the behavior of many Kerberos client tools. Each tool may have its own section in the appdefaults section of the krb5.conf file. Many of the applications that use the appdefaults section, use the same options; however, they might be set in different ways for each client application. Kerberos Client Applications
The following Kerberos applications can have their behavior modified through the user of options set in the appdefaults section of the /etc/krb5/krb5.conf file or by using various command-line arguments. These clients and their configuration settings are described below. kinit
The kinit client is used by people who want to obtain a TGT from the KDC. The /etc/krb5/krb5.conf file supports the following kinit options: renewable , forwardable , no_addresses, max_life, max_renewable_life and proxiable . telnet
The Kerberos telnet client has many command-line arguments that control its behavior. Refer to the man page for complete information. However, there are several interesting security issues involving the Kerberized telnet client. The telnet client uses a session key even after the service ticket which it was derived from has expired . This means that the telnet session remains active even after the ticket originally used to gain access, is no longer valid. This is insecure in a strict environment, however, the trade off between ease of use and strict security tends to lean in favor of ease-of-use in this situation. It is recommended that the telnet connection be re- initialized periodically by disconnecting and reconnecting with a new ticket. The overall lifetime of a ticket is defined by the KDC ( /etc/krb5/kdc.conf ), normally defined as eight hours. The telnet client allows the user to forward a copy of the credentials (TGT) used to authenticate to the remote system using the -f and -F command-line options. The -f option sends a non-forwardable copy of the local TGT to the remote system so that the user can access Kerberized NFS mounts or other local Kerberized services on that system only. The -F option sends a forwardable TGT to the remote system so that the TGT can be used from the remote system to gain further access to other remote Kerberos services beyond that point. The -F option is a superset of -f . If the Forwardable and or forward options are set to false in the krb5.conf file, these command-line arguments can be used to override those settings, thus giving individuals the control over whether and how their credentials are forwarded. The - x option should be used to turn on encryption for the data stream. This further protects the session from eavesdroppers. If the telnet server does not support encryption, the session is closed. The /etc/krb5/krb5.conf file supports the following telnet options: forward , forwardable , encrypt , and autologin . The autologin [ true /false ] parameter tells the client to try and attempt to log in without prompting the user for a user name. The local user name is passed on to the remote system in the telnet negotiations. rlogin and rsh
The Kerberos rlogin and rsh clients behave much the same as their non-Kerberized equivalents. Because of this, it is recommended that if they are required to be included in the network files such as /etc/hosts.equiv and .rhosts that the root users directory be removed. The Kerberized versions have the added benefit of using Kerberos protocol for authentication and can also use Kerberos to protect the privacy of the session using encryption. Similar to telnet described previously, the rlogin and rsh clients use a session key after the service ticket which it was derived from has expired. Thus, for maximum security, rlogin and rsh sessions should be re-initialized periodically. rlogin uses the -f, -F , and -x options in the same fashion as the telnet client. The /etc/krb5/krb5.conf file supports the following rlogin options: forward , forwardable , and encrypt . Command-line options override configuration file settings. For example, if the rsh section in the krb5.conf file indicates encrypt false , but the -x option is used on the command line, an encrypted session is used. rcp
Kerberized rcp can be used to transfer files securely between systems using Kerberos authentication and encryption (with the -x command-line option). It does not prompt for passwords, the user must already have a valid TGT before using rcp if they wish to use the encryption feature. However, beware if the -x option is not used and no local credentials are available, the rcp session will revert to the standard, non-Kerberized (and insecure) rcp behavior. It is highly recommended that users always use the -x option when using the Kerberized rcp client.The /etc/krb5/krb5.conf file supports the encrypt [ true /false ] option. login
The Kerberos login program ( login.krb5 ) is forked from a successful authentication by the Kerberized telnet daemon or the Kerberized rlogin daemon. This Kerberos login daemon is separate from the standard Solaris OE login daemon and thus, the standard Solaris OE features such as BSM auditing are not yet supported when using this daemon. The /etc/krb5/krb5.conf file supports the krb5_get_tickets [ true /false ] option. If this option is set to true, then the login program will generate a new Kerberos ticket (TGT) for the user upon proper authentication. ftp
The Sun Enterprise Authentication Mechanism (SEAM) version of the ftp client uses the GSSAPI (RFC 2743) with Kerberos v5 as the default mechanism. This means that it uses Kerberos authentication and ( optionally ) encryption through the Kerberos v5 GSS mechanism. The only Kerberos- related command-line options are -f and -m . The -f option is the same as described above for telnet (there is no need for a -F option). -m allows the user to specify an alternative GSS mechanism if so desired, the default is to use the kerberos_v5 mechanism. The protection level used for the data transfer can be set using the protect command at the ftp prompt. Sun Enterprise Authentication Mechanism software ftp supports the following protection levels:
It is recommended that users set the protection level to private for all data transfers. The ftp client program does not support or reference the krb5.conf file to find any optional parameters. All ftp client options are passed on the command line. See the man page for the Kerberized ftp client, ftp (1). In summary, adding Kerberos to a network can increase the overall security available to the users and administrators of that network. Remote sessions can be securely authenticated and encrypted, and shared disks can be secured and encrypted across the network. In addition, Kerberos allows the database of user and service principals to be managed securely from any machine which supports the SEAM software Kerberos protocol. SEAM is interoperable with other RFC 1510 compliant Kerberos implementations such as MIT Krb5 and some MS Windows 2000 Active Directory services. Adopting the practices recommended in this section further secure the SEAM software infrastructure to help ensure a safer network environment. Implementing the Sun ONE Directory Server 5.2 Software and the GSSAPI Mechanism
This section provides a high-level overview, followed by the in-depth procedures that describe the setup necessary to implement the GSSAPI mechanism and the Sun ONE Directory Server 5.2 software. This implementation assumes a realm of EXAMPLE.COM for this purpose. The following list gives an initial high-level overview of the steps required, with the next section providing the detailed information.
The sections that follow fill in the details. Configuring a DNS Client
To be a DNS client, a machine must run the resolver . The resolver is neither a daemon nor a single program. It is a set of dynamic library routines used by applications that need to know machine names. The resolver's function is to resolve users' queries. To do that, it queries a name server, which then returns either the requested information or a referral to another server. Once the resolver is configured, a machine can request DNS service from a name server. The following example shows you how to configure the resolv.conf(4) file in the server kdc1 in the example.com domain. ; ; /etc/resolv.conf file for dnsmaster ; domain example.com nameserver 192.168.0.0 nameserver 192.168.0.1 The first line of the /etc/resolv.conf file lists the domain name in the form: domain domainname
Note No spaces or tabs are permitted at the end of the domain name. Make sure that you press return immediately after the last character of the domain name.
The second line identifies the server itself in the form: nameserver IP_address Succeeding lines list the IP addresses of one or two slave or cache-only name servers that the resolver should consult to resolve queries. Name server entries have the form: nameserver IP_address IP_address is the IP address of a slave or cache-only DNS name server. The resolver queries these name servers in the order they are listed until it obtains the information it needs. For more detailed information of what the resolv.conf file does, refer to the resolv.conf (4) man page. To Configure Kerberos v5 (Master KDC)
In the this procedure, the following configuration parameters are used:
Note This procedure requires that DNS is running.
Note Before you begin this configuration process, make a backup of the /etc/krb5 files.
With regards to the configuration of Kerberos v5 in conjunction with the Sun ONE Directory Server 5.2 software, you are finished with the Kerberos v5 part. It's now time to look at what is required to be configured on the Sun ONE directory server side. Sun ONE Directory Server 5.2 GSSAPI Configuration
As previously discussed, the Generic Security Services Application Program Interface (GSSAPI), is standard interface that enables you to use a security mechanism such as Kerberos v5 to authenticate clients. The server uses the GSSAPI to actually validate the identity of a particular user. Once this user is validated , it's up to the SASL mechanism to apply the GSSAPI mapping rules to obtain a DN that is the bind DN for all operations during the connection. The first item discussed is the new identity mapping functionality. The identity mapping service is required to map the credentials of another protocol, such as SASL DIGEST-MD5 and GSSAPI to a DN in the directory server. As you will see in the following example, the identity mapping feature uses the entries in the cn=identity mapping, cn=config configuration branch, whereby each protocol is defined and whereby each protocol must perform the identity mapping. For more information on the identity mapping feature, refer to the Sun ONE Directory Server 5.2 Documents. To Perform the GSSAPI Configuration for the Sun ONE Directory Server Software
|