Installing, Configuring and Administering the Kerberos Server V 2.0 on HP-UX 11i HP 9000 Networking Edition 2 Manufacturing Part Number: T1417-90003 E0602 U.S.A. © Copyright 2002, Hewlett-Packard Company. .
Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. Hewlett-Packard shall not be held liable for errors contained herein or direct, indirect, special, incidental or consequential damages in connection with the furnishing, performance, or use of this material. Warranty.
This software is based in part on the Fourth Berkeley Software Distribution under license from the Regents of the University of California. ©Copyright 1983-2002, Hewlett-Packard Co., All Rights Reserved ©Copyright 1979, 1980,1983, 1985-1993 The Regents of the Univ. of California ©Copyright 1980, 1984, 1986 Novell, Inc. ©Copyright 1986-1992 Sun Microsystems, Inc. ©Copyright 1985-2002 Massachusetts Institute of Technology. ©Copyright 1989-93 The Open Software Foundation, Inc.
Contents 1. Overview Chapter Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How The Kerberos Server Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DES vs 3DES Key Type Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents krb.conf Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Sample krb.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 krb.realms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 krb.realms Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Adding User Principals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding New Service Principals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . kadmin Vs kadminl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Administrator . . . . . . . . .
Contents Attributes Tab (Principal Information window). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a Service Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . To delete a service principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extracting Service Keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Stashing the Master Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Starting and Stopping Daemons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintenance Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protecting Security Server Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backing Up Primary Server Data . . .
Contents One-way Trust. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Two-way Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hierarchical Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Other Types Of Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Reporting Problems to Your Hewlett-Packard Support Contact . . . . . . . . . . . . . . . . . 276 Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents 12
Tables Table 4-1. Table of Analogous Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 Table 5-1. Security Server Files That Require Configuration . . . . . . . . . . . . . . . . . . 63 Table 6-1. Administrative Permission Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Table 6-2. Default Password Policy Settings for the base group . . . . . . . . . . . . . . . 101 Table 6-3. Administration Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tables 14
Figures Figure 1-1. Authentication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Figure 6-1. Principals Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Figure 6-2. General Tab (Principal Information Window) . . . . . . . . . . . . . . . . . . . . 120 Figure 6-3. Password Tab (Principal Information Window) . . . . . . . . . . . . . . . . . . 138 Figure 6-4. Change Password Window (Password Tab) . . . . . . . . . . .
Figures 16
Preface This manual describes how to install, configure, administer and trouble shoot the Kerberos Server on HP 9000 servers running on HP-UX 11i.
Audience HP intends this manual for system managers or administrators responsible for configuring and maintaining the Kerberos server on HP-UX 11i. This manual is based on the assumption that you have: • An understanding of distributed network concepts and client-server computing • Demonstrated knowledge of UNIX • An understanding of the basics Kerberos Related Software Products • PAM Kerberos on HP-UX 11i delivered as part of the HP-UX Internet operating environment component (HP-UX 11i-OE).
— http://docs.hp.com — http://www.unixsolutions.hp.com/products/hpux/ hpux11/whitepapers/netsecur.pdf • HP-UX IT Resource Center: — http://us-support.external.hp.com (US and Asia Pacific) — http://europe-support.external.hp.com (Europe) • The Internet Engineering Task Force RFC Pages — http://www.ietf.org/rfc.
Conventions The following conventions are used throughout this manual: Text Conventions italic Identifies book titles bold Identifies command-line options, command buttons and menu items Syntax Conventions fixed width Identifies file names, system prompts, operating system commands, and UNIX error and system messages italic fixed Identifies variables that you need to replace according width to your environment bold fixed width 20 Identifies the default in a series of parameters | Separates mutuall
Using This Manual The Installing, Configuring and Administering the Kerberos Server on HP-UX 11i manual describes how this product can provide the infrastructure for your security needs. Use this guide as a road map to find information that you need to configure and maintain the Kerberos Server.
• Chapter 9, Troubleshooting - Provides trouble shooting techniques that will enable you to resolve most of the common problems encountered while using the Kerberos Server. Also, a brief note on reporting problems to your Hewlett-Packard Support Contact is provided here.
1 Overview This chapter provides an introduction to the HP’s Kerberos Server V 2.0, now available on HP-UX 11i.
Overview Chapter Overview Chapter Overview This chapter covers the following topics: 24 • “How The Kerberos Server Works” on page 25 • “Authentication Process” on page 27 • “DES vs 3DES Key Type Settings” on page 32 Chapter 1
Overview How The Kerberos Server Works How The Kerberos Server Works The term “Kerberos” was derived from Greek mythology. “Cerberus” is the latin variant of Kerberos who guarded the entrance of Hades, the Greek hell. The Kerberos security system, on the other hand, guards electronic transmissions that are sent across the network. Kerberos is a mature network authentication protocol based on the RFC 1510 specification of the IETF.
Overview How The Kerberos Server Works NOTE For more information on the basics of Kerberos, refer to Installing, Configuring and Administering the Kerberos Server on HP-UX 11i (T1417 -0001). This document is available at, http://www.docs.hp.com The next section describes the Kerberos Authentication process. This section enables you to understand the intricacies of the Authentication process.
Overview Authentication Process Authentication Process To aid you in understanding the configuration and administration issues this section describes the authentication process. The process of Configuring and Administering your Kerberos Server have been discussed in detail in the subsequent chapters of this manual.
Overview Authentication Process The figure shown below depicts the components of the secure environment and the Kerberos protocol. Also, given below is a step-wise procedure of how a client and server authenticate each other using Kerberos. The step numbers match with the numbered arrows in the figure below. Figure 1-1 Authentication Process Step 1. The user begins to use a Kerberos-secured application by entering the user principal name and password.
Overview Authentication Process Step 3. If the AS can decrypt the message successfully, it knows that the requesting user is who they claim to be, and issues a TGT. The TGT contains the name of the user, a session key to be used by the user and the Server for any subsequent communication. The reply message is encrypted using the user’s secret key. Step 4. The KDC decrypts the message using the user’s secret key.
Overview Authentication Process Step 8. The TGS decrypts the authenticator to check the user’s identity and verifies that the user’s TGT and credentials have not expired. The TGS reads the secured application’s service principal key from the principal database, then builds and sends a reply back to the secured client application.
Overview Authentication Process Kerberos-secured applications perform this optional step. First, the service modifies the data in the authenticator with an algorithm known to the client. The authenticator is then encrypted in the session key and returned to the client. The client uses its copy of the session key to decrypt the authenticator and verifies that the data was properly modified.
Overview DES vs 3DES Key Type Settings DES vs 3DES Key Type Settings In the processes outlined above, what happens if the user principal and the service principal do not use the same key type? The answer is - the process continues as described. Here’s why. There is no step in which the client or the service accepts a message encrypted by the other’s key. The Kerberos Server acts as the only trusted party. Both the client application and the service share a secret with only the server.
2 Installation This chapter provides preliminary information that you would need to understand before you begin to install the on your HP-UX systems. It also provides you with the installation procedures that will enable you to install the HP’s Kerberos Server V 2.0.
Installation Chapter Overview Chapter Overview This chapter contains the following sections: 34 • “Before Installing The Kerberos Server” on page 35 • “Hardware Requirements” on page 36 • “Software Requirements” on page 37 • “Installing The Kerberos Server” on page 38 Chapter 2
Installation Before Installing The Kerberos Server Before Installing The Kerberos Server Before you install the Server, it is recommended that you: • Ensure that the Kerberos Server is installed on a system that is physically secure and has restricted access to it. If necessary, ascertain that the system, on which you install the Server, is kept under lock and key. • Disable all the network services, such as ftp, telnet, rlogin, finger et all, by restricting access to the machine.
Installation Hardware Requirements Hardware Requirements This section describes the hardware requirements for the Kerberos Server software for HP 9000 server systems. OS Platform and Version Compatibility The version of the Kerberos Server you are installing must be compatible with the version of HP-UX you are running.
Installation Software Requirements Software Requirements This section describes the software requirements for the Kerberos Server software for HP 9000 server systems. Before installing the Server product, ensure that the software listed below has been correctly installed on your system. Refer to the related documentation if you need more information about any of these products. If you cannot find the software or information you need, contact your HP representative or logon to our website, http://www.
Installation Installing The Kerberos Server Installing The Kerberos Server If you are migrating your Kerberos database from version 1.0 to the new version, version 2.0, create a dump file of the older Kerberos database before installing the new version of HP’s Kerberos Server. Refer to Chapter 3, “Migration,” on page 41. Step 1. Insert the software media (tape or disk) in the appropriate drive Step 2. Type: swinstall See the man page on swinstall (1m) for more information on this command Step 3.
Installation Installing The Kerberos Server NOTE The Software Distributor is documented in Managing HP-UX Software with SD-UX. Your Kerberos Server is now installed. To configure the Server to act as either the Primary Security Server or one of the Secondary Security Servers refer to, Chapter 5, “Configuration,” on page 61, for more details.
Installation Installing The Kerberos Server 40 Chapter 2
3 Migration This chapter describes the migration procedure to migrate from the Kerberos Server V 1.0 to the Kerberos Server V 2.0. The Kerberos database formats of version 1.0 and version 2.0 are not compatible with each other. Hence, the database from the Kerberos Server V 1.
Migration to be migrated to the Kerberos Server V 2.0 database format. The older database version of Kerberos contains the Principal and Policy related information. The new version of the Kerberos Server supports automatic migration of only the Principal related information. NOTE 42 The Policies cannot be automatically migrated to the new version of the Kerberos Server. This task has to performed manually.
Migration Chapter Overview Chapter Overview Chapter 3 • “Policy Migration” on page 44 • “Step-wise Procedure For Migration” on page 45 43
Migration Policy Migration Policy Migration In the previous version of the Kerberos Server, version 1.0, a policy with any name and attribute values could be created. Further, any principal could subscribe to any of the policies present in the database. In the new version of the Kerberos Server, version 2.0, the policies are classified depending on the instance name of the Principal. Refer to “Password Policy File” on page 101, for more information on classifying policies.
Migration Step-wise Procedure For Migration Step-wise Procedure For Migration Given below is a step-wise procedure to migrate from version 1.0 to version 2.0 of the Kerberos Server. NOTE The lines beginning with => is a continuation with the previous line. Step 1. Dump the database on the version 1.0 Server On the Kerberos Server version 1.0, dump the database with the default dump version.
Migration Step-wise Procedure For Migration The password of the master key can also be changed while executing the migration tool. The tool will prompt you for a password change. If you want to change the password, type yes at the command prompt. If you do not want to change the password, type no at the command prompt. NOTE The same password has to be used while creating the minimal database for version 2.0 of the Kerberos Server, as described in Step 5.
Migration Step-wise Procedure For Migration Step 6. Load the new version of the dump file generated from Step 4. Use the kdb_load tool to load the database from the dump file, /opt/krb5/dumpfilev2.0. # kdb_load -f /opt/krb5/dumpfilev2.0 On successful completion the following message is displayed: “Load Successful” The migration of the Principal information is now complete. Given below are a few pointers that need to be considered: • The principal information is migrated from version 1.0 to version 2.0.
Migration Step-wise Procedure For Migration 48 Chapter 3
4 Interoperability With Windows 2000 There are certain configuration requirements when you set up inter-realm interoperability between HP’s Kerberos Server and Chapter 4 49
Interoperability With Windows 2000 Windows 2000. This chapter discusses what you need to know about configuring such an environment. This chapter contains information specific to establishing interoperability with Windows 2000 Kerberos implementations. Before you read this chapter, you must be familiar with the concepts in Chapter 8, “Inter-realm,” on page 243.
Interoperability With Windows 2000 Chapter Overview Chapter Overview This chapter contains the following: Chapter 4 • “Understanding the Terminology” on page 52 • “Table of Analogous Terms” on page 54 • “HP’s Kerberos Server and Windows 2000 Interoperability” on page 55 • “Establishing Trust Between HP’s Kerberos Servers and Windows 2000” on page 56 • “Single Realm (Domain) Authentication” on page 57 • “Inter-Realm (Inter-Domain) Authentication” on page 58 • “Special Considerations for Inter
Interoperability With Windows 2000 Understanding the Terminology Understanding the Terminology Both HP’s Kerberos Server and Microsoft provide Kerberos security for your network. While the technology is the same - the terminology varies. Kerberos authentication depends upon establishing trust between users and services via a trusted third party called a Key Distribution Center (KDC). HP provides a KDC on the security server, while Windows 2000 provides a KDC on the domain controller.
Interoperability With Windows 2000 Understanding the Terminology In broad strokes, that is how the Kerberos authentication protocol works and both implementations under discussion have virtually identical conceptual frameworks. Of course there are mechanical differences -for example, the HP’s implementation uses configuration files to locate host systems and the Microsoft implementation uses strictly DNS lookup to resolve host names.
Interoperability With Windows 2000 Table of Analogous Terms Table of Analogous Terms The following terms are analogous counterparts in HP’s Kerberos Server and Windows 2000 Kerberos implementations: Table 4-1 Table of Analogous Terms HP’s Kerberos Server 54 Windows 2000 Realm Domain Inter-Realm Inter-Domain Cross-Domain Cross-Realm Secret Key Long-Term Key Shared Principal Key Credentials Cache Secure Cache Principal Database Active Directory Service Ticket Session Ticket Security Server D
Interoperability With Windows 2000 HP’s Kerberos Server and Windows 2000 Interoperability HP’s Kerberos Server and Windows 2000 Interoperability When you set up inter-realm interoperability between the HP’s Kerberos Server software and Windows 2000, there are three basic cases, each with its own configuration requirement: Case 1 A Windows 2000 user needs access to services in an HP’s Kerberos Server realm.
Interoperability With Windows 2000 Establishing Trust Between HP’s Kerberos Servers and Windows 2000 Establishing Trust Between HP’s Kerberos Servers and Windows 2000 If you want to establish trust between Kerberos Server KRB.REALM, and Windows 2000, W2K.DOMAIN, you would need to do the following: Step 1. Add inter-realm service principals to the Kerberos Server realm. For more information, refer to “Administrator” on page 114. • If the realm is the source realm, the name of the principal is: krbtgt/W2K.
Interoperability With Windows 2000 Single Realm (Domain) Authentication Single Realm (Domain) Authentication The simplest interoperability scenarios involve one or more client systems in a given realm or domain that authenticate to a single Key Distribution Center. There are two such interoperability scenarios that do not require inter-realm authentication: • Kerberos Server principals and Windows 2000 users can authenticate to a Kerberos Server and access services registered in that realm.
Interoperability With Windows 2000 Inter-Realm (Inter-Domain) Authentication Inter-Realm (Inter-Domain) Authentication When two distinct realms share common keys, the two realms are said to trust one another. With that trust in place, principals can securely access services in their native realm as well as those in the trusted realm. HP terms such access inter-realm authentication; Microsoft terms it inter-domain authentication or cross-realm authentication.
Interoperability With Windows 2000 Special Considerations for Interoperability Special Considerations for Interoperability You must consider the following issues related to interoperability with Windows 2000 implementations. Database Considerations Your network can contain more than one server, but there is only one master copy of the database that is propagated to all secondary servers.
Interoperability With Windows 2000 Special Considerations for Interoperability 60 Chapter 4
5 Configuration This chapter describes and discusses the configuration files and procedures to configure the Kerberos Server on your HP-UX 11i systems.
Configuration Chapter Overview Chapter Overview This chapter contains the following sections: • “Configuration Files For The Kerberos Server” on page 63 • “Auto-Configuration of the Security Server” on page 64 • “Manual Configuration Of The Kerberos Server” on page 67 • “krb.conf” on page 69 — “Sample krb.conf File” on page 71 • “krb.realms” on page 73 — “Sample krb.
Configuration Configuration Files For The Kerberos Server Configuration Files For The Kerberos Server During installation, several critical Kerberos Server files should have been installed on your system. These files must now be configured on the Primary Security Server and then copied to all the Secondary Security Servers on your network. Table 5-1 lists and briefly describes the server files that need to be configured.
Configuration Auto-Configuration of the Security Server Auto-Configuration of the Security Server An automated tool named, krbsetup, has been provided to auto-configure your Kerberos Server. Using this tool, you can configure; un-configure; start and stop the kdcd and the kadmind daemons. This tool is installed at the following directory: /opt/krb5/sbin This tool will automatically create your krb.conf and krb.realms files and places them in the /opt/krb5 directory.
Configuration Auto-Configuration of the Security Server 1) 2) 3) 4) 5) Configure the server Start the Kerberos daemons Stop the Kerberos daemons Un-configure the Server Exit 6) Help Step 3. Select option 1 to configure the server. a. You will be prompted to opt between Configuring your Kerberos Server as either a Primary Security Server or a Secondary Security Server. 1. Select option 1 to configure your Kerberos Server as a primary security server 2.
Configuration Auto-Configuration of the Security Server h. You will be prompted to re-enter the database master password to verify the password. i. Your configuration is now complete and your Kerberos daemons are up and running. To return to the main menu, press the return key. Step 4. Select option 2 to start the Kerberos daemons. Press the return key to return to the main menu. Step 5. Select option 3 to stop the Kerberos daemons. Press the return key to return to the main menu. Step 6.
Configuration Manual Configuration Of The Kerberos Server Manual Configuration Of The Kerberos Server The following sections of this chapter describe the procedure to manually configure your Security Servers. We recommend that you use the auto-configuration tool to setup your basic Kerberos Security Server. For more information on auto-configuration, refer to “Auto-Configuration of the Security Server” on page 64. The Key Distribution Center (KDC) issues Kerberos tickets.
Configuration Manual Configuration Of The Kerberos Server Modify the configuration files, /opt/krb5/krb.conf and /opt/krb5/krb.realms to reflect the correct information, such as the hostname and realm name, for your realm. Refer to “Configuring The Primary Server” on page 78, for more details.
Configuration krb.conf krb.conf The krb.conf file contains information about the default realm of the host, the administration server, and security servers for known realms. We recommend that you copy the krb.conf.sample file from /opt/krb5/example/krb.conf to the /opt/krb5/krb.conf directory.
Configuration krb.conf The first line of the krb.conf file identifies the host systems default realm. The second line and its subsequent lines require fields that identify the Security Server hostnames. Each field in line must be separated by a space or a tab. The following format is generally used: • NOTE The first field in the krb.conf file denotes the realm name. By convention, realm names are in upper-case letters to visually distinguish them from domain names.
Configuration Sample krb.conf File Sample krb.conf File The sample krb.conf file named krb.conf.sample is available in the /opt/krb5/example directory. Copy this sample file to /opt/krb5/krb.conf file and modify it to reflect the hostnames and realm name for your realm. NOTE The realm names are case sensitive. Replace the underlined Your_Realm_Name, Your_Secondary_Server1, Your_Secondary_Server2 and hostname.subdomain.domain.
Configuration Sample krb.conf File REFERENCE To view the krb.conf manpage, type the following command at the prompt: shell%: man krb.conf Services The services file contains entries that allow client applications to establish socket connections to the KDC or to the applications servers.
Configuration krb.realms krb.realms The realms file defines host-to-realm or domain-to-realm name mapping data. The krb.realms file is located only on the Kerberos Server systems. This file maps hostnames to realms names. The krb.realms is located in the following directory: /opt/krb5 The realms file ensures that all systems on the network understand the other systems that reside in each realm. The krb.
Configuration krb.realms NOTE This file does not identify systems as primary or secondary servers, nor does it define the relationship between the primary and secondary servers. These definitions exist in the configuration file, krb.conf. krb.realms Format Your_Primary_Security_Server Your_Realm_Name .Your_Secondary_Security_Server Your_Realm_Name *.Your_Domain_Name Your_Realm_Name # # # You can add entries to the file to identify various translations from hostnames to realm names.
Configuration krb.realms For example, to indicate that hosts deer.bambi.com and goat.bambi.com belong to REALM1, you need to add the following entry in your krb.realms file: .bambi.com * (an asterisk) REALM1 Begin the name field with an asterisk followed by a parent domain name to designate all hosts in subdomains belong to the indicated realms. For example, to indicate that hosts june.sales.com and july.sales.com belong to REALM2, you need to add the following entry in your krb.realms file: *.sales.
Configuration Sample krb.realms Sample krb.realms The sample krb.realms file named krb.realms.sample is available in the /opt/krb5/examples directory. Copy this sample file and modify it to reflect your realm name. This file should be copied to the following location: /opt/krb5 NOTE The realm names are case sensitive.
Configuration Sample krb.realms Line three of the krb.realms file maps all hosts in the domain and sub-domains with the root name bambi.com to the BAMBI.COM realm.
Configuration Configuring The Primary Server Configuring The Primary Server Before you begin configuring, ensure that your primary and secondary servers are installed. The following section describes the initial configuration tasks you need to perform to get your Primary and Secondary Security Servers up and running.
Configuration Creating The Principal Database After Installation Creating The Principal Database After Installation If you choose not to create the principal database during installation, you must do so before configuring the Security Server. To do this, use the following command: kdb_create -s NOTE kdb_create, by default, uses the 3DES encrypted database. For those of you using the older version, HP’s Kerberos Server V 1.
Configuration Add An Administrative Principal Add An Administrative Principal Use the Administrator instead of the Command-Line-Administrator option to add the principal account. Refer to, “kadmin Vs kadminl” on page 112, for more information on using the Administrator and the Command-Line-Administrator. While it is possible to use the kadmin option to create an administrative principal, it cannot be used to assign administrative privileges.
Configuration Add An Administrative Principal To enable authentication, you must disable the password change requirement when you create the administrative principal account. If you are using the kadminl_ui, go to the Attributes tab on the Principal Information Window and clear the Require Password Change checkbox. If you are using kadminl, use the mod command and set nopwchg to indicate no password change is required.
Configuration Create The host/ principal And Extract Its Service Key Create The host/ principal And Extract Its Service Key To allow principal database propagation, the Primary Server must have a host/ principal and the service key for this principal must be extracted to that server’s service key table file.
Configuration Start the Kerberos daemons Start the Kerberos daemons The krbsetup tool can be used to start the Kerberos daemons, namely: NOTE • kdcd • kadmind You cannot use the krbsetup tool to start the kpropd daemon. This has to be done manually. Alternatively, you can the following command to start the Kerberos daemons, kdcd and kadmind daemons. /sbin/init.d/krbsrv start You cannot use the command specified in the line above, to start the kpropd daemon.
Configuration Define Secondary Server Network Locations Define Secondary Server Network Locations To configure propagation, you must define server network locations by altering the content of the Kerberos configuration files. You cannot use the DNS lookup to configure propagation. Refer to the Chapter 7, “Propagation,” on page 207, for more information. For each Secondary Server installed on your network, you must edit the krb.
Configuration Security Policies Security Policies There are two files that are directly related to the security of the network in your organization. Namely, • password policy file • admin_acl_file Password Policy File This file controls password rules such as password length, number of character types, and the lifetime of a password. This file is located on each Primary and all the Secondary Security Servers. Refer to “Password Policy File” on page 101, for more information on the Password Policy File.
Configuration Starting the Security Server Starting the Security Server Once the Kerberos database has been created and the administrative principals set up, you are ready to start the Kerberos daemons on the Primary Security Server. To do this, edit the /etc/rc.config.d/krbsrv file to reflect the following values: KDC = 1 ADMD = 1 Type, /sbin/init.
Configuration Summary Summary Given below is a summarized step-wise procedure to configure the KDC server. Step 1. Install the Kerberos Server. For more information on carrying out this step, refer to “Installing The Kerberos Server” on page 38. Step 2. Create and modify the configuration files /opt/krb5/krb.conf, and /opt/krb5/krb.realms. Refer to “Configuration Files For The Kerberos Server” on page 63. Step 3. Create the Database using the kdb_create command. # /kdb_create “Your_Realm_Name” -s Step 4.
Configuration Summary % /sbin/initd/krbsrv start Verify that the daemons have started properly by checking for the messages in the system log files. Step 7. Once the KDC is set up and running, it is time to create the principals of all the hosts and users into the Kerberos database.
Configuration Configuring The Secondary Security Servers Configuring The Secondary Security Servers You are now ready to start configuring the secondary security servers. Assuming that you are setting up the Primary Security Server so that you can easily switch the Primary Security Server with one of the Secondary Servers, you should perform each of the steps on the Primary Server as well as on the Secondary Server.
Configuration Configuring The Secondary Security Servers Create a host/ Principal and Extract Its Key To allow principal database propagation, each Secondary Server must contain a host/ principal. Also, the key for this principal must be extracted to that server’s service key table file. Creating a host/ principal and extracting its key is performed on a Secondary Server the same way it is performed on a Primary Server.
6 Administration This chapter describes the procedures that will help you to administer and maintain the Kerberos database. It also entails a discussion on Principals and how to manage them using either the Administrator or the Command-Line Administrator.
Administration Chapter Overview Chapter Overview This chapter contains the following sections: • “Administering the Kerberos Database” on page 93 • “kadmind” on page 94 • “admin_acl_file” on page 95 • “Password Policy File” on page 101 • “Principals” on page 103 • “kadmin Vs kadminl” on page 112 • “Administrator” on page 114 — “Local Administrator - kadminl_ui” on page 116 — “Remote Administrator - kadmin_ui” on page 167 92 • “Manual Administration Using kadmin” on page 170 • “Principal D
Administration Administering the Kerberos Database Administering the Kerberos Database Once, you have installed and configured the HP-UX Kerberos Server version 2.0, the Kerberos database will contain the default Kerberos principals, their keys, and other administrative information about each of these principal’s, for your realm. For more information on installing your security server, refer to Chapter 2, “Installation,” on page 33.
Administration kadmind kadmind The kadmind command starts the administrative server. This administrative server runs on Kerberos server that stores the Kerberos principal database. The kadmind accepts password change requests and remote requests to administer the information in this database. kadmind requires the following configuration files to be set for it to work appropriately: 94 krb.conf The Kerberos configuration file contains configuration information for the Kerberos Server. Refer to “krb.
Administration admin_acl_file admin_acl_file This file lists authorized principals with their respective administrative permissions. It also lists principals that cannot be modified without explicit privileges. This file is located only on the primary security server, at the following location: /opt/krb5 It must be protected with appropriate read-write privileges and must be accessible only by the root user. kadmind checks for the principal’s permissions in the admin_acl_file.
Administration admin_acl_file Assigning Administrative Permissions Administrative principals may have varying levels of trust assigned to them, depending on your organization’s policies. Table 6-1 lists the possible administrative permission settings and the letter designator used in the admin_acl_file to indicate the permissions assigned to the principal account. Permissions designated with a lower case letter apply only to the realm to which the administrative principal belongs.
Administration admin_acl_file Table 6-1 Administrative Permission Settings (Continued) Administrator Field Name NOTE ACL file Character List prinicpal. This is redundant with i or I Note: This permission is not displayed in Administrator l or L Modify Principals m or M Extract Keys x or X Restricted Administrator. Use the r, R and Rr modifiers in combination with the a, A, c, C, d, D, i, I, m, M, or x.
Administration admin_acl_file FINANCE.BAMBI.COM realm name * all permissions To grant the principal, rabbit@FINANCE.BAMBI.COM, permission to add, list and inquire about any principal in the database, you can add the following line into the acl file: rabbit@FINANCE.BAMBI.COM ali Adding Entries to the admin_acl_file You can add any principal name to the admin_acl_file as an entry with or without assigned administrative permissions.
Administration admin_acl_file Creating Administrative Accounts You can set administrative permissions in the admin_acl_file using one of the following methods: • Using the Administrator to set administrative permissions. The admin_acl_file is automatically edited, when you change the administrative permissions of the principal. • Edit the admin_acl_file directly. To edit this file you must have the required system file administration rights.
Administration admin_acl_file In either case, administrative principals can delete any principal from their own realm, but have restricted delete privileges in realms other than their own. As another example, administrative principals assigned the IDRm or IDRidm permissions have restricted delete permissions in all other realms but not their own, but can modify and delete any principal in their own realm.
Administration Password Policy File Password Policy File This file controls password rules such as password length, number of character types, and the lifetime of a password. The file, password.policy, is located on each of the primary and secondary security servers. This file can be located at: /opt/krb5 Editing the Default File To edit the password policy file and configure it to match your organization’s requirements, use a text editor on the primary security server.
Administration Password Policy File Table 6-2 Default Password Policy Settings for the base group (Continued) Password Policy setting Default *.Expiration None *.MinimumAge None *.NotifyTime 7d *.Dictionaries None *.MaxFailAuthCnt 10 *.NoReqChangePwd 0 *.MaximumHistory 1 If you modify the MaxfailAuthCnt parameter, you must copy the password policy file to the secondary security server and then restart the kdcd on both the secondary and primary secondary servers.
Administration Principals Principals A Principal is a string that names a specific entity to which a set of credentials may be assigned. Principals are users and network services that are included in your security network. The general syntax of a principal is: identifier/instance@REALM A principal name consists of three parts, identifier is the name of either the network service or a user. This is a required parameter and has to be specified. /instance is a group used to further identify the name.
Administration Principals • cannot be longer than 767 characters • must be uniquely defined in the first 255 characters • cannot contain a space, tab, number sign (#), backward slash (\) or colon (:) NOTE The forward slash (/) is an allowed character and is used to delineate the instance. There are two types of principals: • user principals User principals are accounts assigned to individuals in your organization. There must be at least one account for each individual.
Administration Principals Adding User Principals The Kerberos Security Server allows you to add user principals to the principal database as needed. The only limit on the number of principals in the database is the disk space available on the primary security server and each of the secondary security servers. When adding a user principal to the database, you must assign the principal identifier, instances (if used) and realm. You must also designate a temporary password for the principal.
Administration Principals The instance portion of the service principal name must be the fully qualified domain name (FQDN) of the host on which the service resides. Although the FQDN in your network can use mixed case characters, the instance portion of the principal name must be in lower case. For example, if the system name is ‘IT.BAMBI.COM’, the principal name must use the instance ‘it.bambi.com’.
Administration Principals WARNING Do not remove, modify, or change the key type for this principal. Do NOT generate a new key for this principal. default@REALM The default@REALM principal name contains the default group principal attributes for REALM. This principal is required in each realm. This principal, called the default group, is automatically created when a realm is added to the database.
Administration Principals kadmin/REALM@REALM The kadmin/REALM@REALM principal name is used by the administration tools: Administrator and the Command-Line-Administrator programs. This principal is required in each realm. It is automatically added when you add a realm to the database. This principal uses a random key, but you do not need to extract the key to a service key table file. WARNING Do NOT remove or modify this principal entry.
Administration Principals The fqdn instance must be the fully qualified domain name (FQDN) of the host system for the server or service. The FQDN must be entered as lower-case characters. These principals are not automatically added to the principal database when the security servers or application services are installed. Removing User Principals You may need to delete user principals from the database.
Administration Principals Protecting Secret Keys User principals must provide their passwords during authentication to create their secret keys. For best security, users should be required to periodically change their passwords. This version of Kerberos has two methods of enforcing that users change their passwords. A user principal is required to change their passwords when: • A system administrator enables the Password Change Required attribute.
Administration Principals Removing Service Principals When a service principal account is deleted from the database, the service account is no longer available in the network. Deleting a service principal using one of the administration tools removes the principal name, attributes, and properties from the database. For a service principal, there is an additional step that must be performed to remove its secret key stored in the service key table file on the service’s host.
Administration kadmin Vs kadminl kadmin Vs kadminl These utilities provide a unified administration interface for the Kerberos database. Kerberos administrators use these utilities to create new users and services for the primary database, and to modify information for the existing entries present in the database. Both these utilities provide for maintenance of Kerberos principals and service key tables (v5srvtab).
Administration kadmin Vs kadminl Table 6-3 Administration Tools Tool Name NOTE Chapter 6 Tool Description Local Administrator (kadminl_ui) The graphical interface that runs on the primary security server Local Command-Line-Administra tor (kadminl) The command line tools that runs on the primary security server Remote Administrator (kadmin_ui) The graphical user interface that can only be run by administrative principals with the required permissions.
Administration Administrator Administrator The Administrator is a Graphical-User-Interface that is used to administer the principal database.
Administration Administrator You do not need to log in as a admin principal to the Local Administrator, any user with root access to the primary security server can run the Local Administrator. Alternatively, to log in to the Remote Administrator, you must use a principal account that has an entry in the admin_acl_file. For complete access to all the functions use the an unrestricted administrative principal account, one with the ‘*’ permissions in the admin_acl_file.
Administration Local Administrator - kadminl_ui Local Administrator - kadminl_ui The Local Administrator, kadminl_ui, is the GUI based Administrator that runs on the primary security server. This program is used to administer the Kerberos database. It allows principals with administrative privileges to administer and maintain the principal database on an ongoing basis. Each user, client or service that is authenticated by the Security Server must be included as a principal in the principal database.
Administration Local Administrator - kadminl_ui — Deleting a Realm The tabs mentioned above have been discussed in the subsequent pages of this chapter.
Administration Principals Tab Principals Tab The kadminl_ui window can be opened by executing the following command at the command line prompt, # /opt/krb5/admin/kadminl_ui This window enables you to manage principals. Click on the Principals tab in the Kerberos Administrator main window. This window can be used to control principal entries your principal database by adding principals, editing or deleting existing principals.
Administration Principals Tab Realm Select the realm where the principal that you want to add, change or delete resides. List All Button Click on this button to list all the principals associated with the realm. Search String Enter characters for locating the principal you want to either edit or delete. Refer to “Finding a Principal” on page 126 for pointers on searching for a principal.
Administration General Tab (Principal Information window) General Tab (Principal Information window) Using the Principal Information window, principals can be added or an existing principal and ticket information can be modified. Figure 6-2 General Tab (Principal Information Window) Principal Displays the name of the principal you are editing. If you are adding a new principal, type the name of the new principal here.
Administration General Tab (Principal Information window) Maximum Ticket Lifetime You can set the maximum ticket lifetime for each individual principal. The time should not exceed the corresponding ticket lifetime set for the realm, as controlled by the krbtgt/REALM@REALM principal. Maximum Renew Time You can set the maximum renewal time for each individual principal. The time should not exceed the corresponding renewal time set for the realm.
Administration Adding Principals to the Database Adding Principals to the Database When you add a principal you must specify some basic information, namely, • Principal and ticket information located on the General Tab • Password and Password expiration information located on the Password Tab • Other Principal attributes located on the Attributes Tab Each tab include default values, as controlled by the Group Settings.
Administration Adding Principals to the Database The List of Principals in the kadminl_ui window is not automatically refreshed after this operation. The principal is present in the database, but it appears in the principal list only after you refresh it using the List All or Search buttons. To simultaneously add multiple principals with the same settings Step 1. Enter the first principal name in the Principal Information window. Step 2.
Administration Creating an Administrative Principal Creating an Administrative Principal Use the kadminl_ui to create administrative prinicpals. When a principal is created and the administrative permissions have been assigned to it, it is saved to the admin_acl_file located on the primary server. For more information on the admin_acl_file, refer to “admin_acl_file” on page 95. We recommend that the /admin instance be assigned to each principal who is an administrator.
Administration Creating an Administrative Principal Step 7. Click OK. Step 8. On the Attributes tab, select the attributes for the administrative principal. • If this administrative principal requires the use of a hardware authentication device, select the Require Preauthentication attribute. Step 9. If necessary, click Apply. Step 10. From the Edit Menu, select Edit Administrative Permission. Select the permissions for the administrative principal. Click *All to select all principals. Click OK. Step 11.
Administration Finding a Principal Finding a Principal There are two ways to search for a principal: • Click List All to display a list of principals of the current realm in the List of Principals dialog box. This dialog box can display upto 1,000 principals. — or • Click Search to display a list of principals of the current realm that match the search criteria entered in the Search String field. The List of Principals dialog box can display upto 1,000 principals. To search for a principal Step 1.
Administration Finding a Principal *test* searches for all principals containing the characters test. ? Each ? represents a single character, except for “/”. For example, test? searches for all principal names containing the characters test, followed by a single character. test?? searches for all principal names containing the characters test, followed by any two characters. [...] Represents any one character from the set, except “/”.
Administration Finding a Principal test [1-9] searches for all principal names starting with the characters test, followed by an one number is the range 1 through 9. [abc-] searches for all principal names starting with a, b, c or, “-”. : Represents the start of a character class descriptor when used immediately after the “[“ or “[!”. Otherwise it is matched literally. The following character classes are supported: [:alnum:] [:digit:] [:print:] [:upper:] {,...
Administration Deleting a Principal Deleting a Principal When you delete a principal using one of the Administrator’s tools, all references to the principal are automatically removed from both the principal database and admin_acl_file. To delete a user principal Step 1. In the kadminl_ui window, choose the Principals tab, and select the principal’s realm. Step 2. Find the principal using the List All or Search button. Step 3.
Administration Loading Default Values for a Principal Loading Default Values for a Principal When you are adding or editing a principal in the Principal Information window, you can quickly restore any changed values back to the default values that have been specified in the default group. Reloading default values updates all fields in each of the Principal Information window tabs.
Administration Restoring Previously Saved Values for a Principal Restoring Previously Saved Values for a Principal When you are editing a principal in the Principal Information window, you can restore any values you have changed, but not yet saved, back to values that were previously saved for that principal. To restore previously saved values for a principal Before you save your current changes, select Restore Values from the Edit menu on the Principal Information window.
Administration Changing Ticket Information Changing Ticket Information You can change the ticket information used for a principal. Ticket information might include the principal expiration date, ticket lifetime and ticket renew time. To change ticket information Step 1. In the kadminl_ui window, choose the Principals tab and select the realm where the principal resides. Step 2. Find the principal whose ticket information you want to change by using the List All or Search button and then click Edit.
Administration Changing Ticket Information You can use the Edit menu to quickly reload default values or to restore previously saved values at any time while you are editing a principal. When you reload default or restored values all the fields in the Principal Information window tabs are reset to the default or previously saved values.
Administration Rules for Setting Maximum Ticket Lifetime Rules for Setting Maximum Ticket Lifetime Enter a value in the Maximum Ticket Lifetime box to indicate the maximum lifetime that a ticket may be issued to the principal. The value format is [Nw] [Nd] [Nh] [Nm], where N is an integer number, and the lower case suffix identifies the unit of time: weeks, days, hours or minutes respectively. A number with no suffix, w,d,h or m, is interpreted as hours.
Administration Rules for Setting Maximum Renew Time Rules for Setting Maximum Renew Time The value in the Maximum Renew Time box indicates the maximum amount of time for which, a ticket can be renewed. The value format is [Nw] [Nd] [Nh] [Nm], where N is an integer number, and the lower case suffix identifies the unit of time: weeks, days, hours or minutes respectively. A number with no suffix, w,d,h or m, is interpreted as hours. NOTE Spaces are not allowed between the number and the suffix.
Administration Changing Password Information Changing Password Information You can change the password information used by a principal that includes: • Password expiration date - indicates when the current principal’s password expires. Check the Password Expiration Date box to activate password expiration for the current principal. If this function is not enabled, then the current principal’s password will never expire.
Administration Changing Password Information WARNING By changing the key and / or salt types, you necessitate a change in a principal’s password. You must inform the principal of the required temporary password. The principal must change their password at their next logon. You can use the Edit menu to quickly reload default values or to restore previously saved values at any time while you are editing a principal.
Administration Password Tab (Principal Information window) Password Tab (Principal Information window) The Password tab is used to specify the password parameters for the principal. Figure 6-3 Password Tab (Principal Information Window) Principal Displays the name of the principal you are editing. Password Expiration Date The password expiration date indicates when the current principal password expires. Check the Password Expiration Date box to activate password expiration for the current principal.
Administration Password Tab (Principal Information window) • The keyword NEVER, which indicates that the expiration is not effected. Key Version Number Every principal password has a version number associated with it that identifies the number of times the password has been changed. When a principal is first created, its password version number is one. Every time the password is changed, the version number is incremented by one. Password Last Changed This date is updated when you change a password.
Administration Password Tab (Principal Information window) Information window. Salts are used to strengthen passwords and ensure that principals with the same passwords do not have the same key. Change Password window (Password tab) kadminl_ui automatically displays the Change Password window when a new principal is created from the Password tab of the Principals Information window. Enter a new password and verify the password for user principals. For service principals, select Generate Random Key.
Administration Password Tab (Principal Information window) assuming the NoChangeReqPwd setting in the principal’s password policy file is set to zero, which is the default. Verification Chapter 6 Re-enter your new password for verification.
Administration Changing Key Types Changing Key Types For the strongest enterprise-wide security between the Security Servers and Clients, all principals must have 3DES keys using Normal (V5) salt. To change a DES principal’s key type to 3DES If you are changing the key type for a service principal that has extracted keys, you must perform these steps on the host system where the service resides.
Administration Changing Key Types If the principal is a service principal, you must extract the new key for the principal. For more information on this procedure, refer to “Extracting Service Keys” on page 151.
Administration Changing Principal Attributes Changing Principal Attributes You can change the principal attributes in the Principal Information window. These attributes are the characteristics and properties assigned to either a user or service principal. Attributes control how a principal behaves and what that principal can or cannot do, such as renewing and forwarding valid tickets. To change principal attributes Step 1. In the kadminl_ui, choose the Principals tab and select the principal’s realm.
Administration Attributes Tab (Principal Information window) Attributes Tab (Principal Information window) Attributes are the characteristics and properties assigned to a principal. Attributes control how a principal behaves and what that principal may or may not do. This window is used to assign the attributes for a principal. Figure 6-5 Attributes Tab (Principal Information Window) Principal Displays the name of the principal you are editing.
Administration Attributes Tab (Principal Information window) postdatable ticket. If this attribute is set for a service principal, the server can issue postdated service tickets for the service. Allow Renewable Tickets The Allow Renewable attribute specifies if a principal is allowed to renew its tickets. Renewable tickets are those that a principal can re-validate up to the maximum renewable time. The Allow Renewable attribute applies to both user and service principals.
Administration Attributes Tab (Principal Information window) Allow Duplicate Session Keys Attribute The Duplicate Session Key attribute specifies if a principal is allowed to use a duplicate session key. A duplicate session key. A duplicate session key is used in user-to-user authentication and specifies which key is used to encrypt the tickets. Require Pre-authentication Attribute The Require Preauthentication attribute specifies if a principal is required to use preauthentication in the TGT request.
Administration Attributes Tab (Principal Information window) The Lock Principal attribute applies to both user and service principals. If this attribute is set for a user principals. If this attribute is set for a user principal, no tickets can be issued to the user. If this attribute is set for a service principal, no tickets are issues for it. The Lock attribute becomes set when a principal exceeds the maximum number of failed authentication attempts allowable by the password policy file.
Administration Attributes Tab (Principal Information window) change password service. If this attribute is not set, then the server issues a server ticket based on the TGT they already posses. The Require Initial Authentication attribute only applies to service principals. If this attribute is selected for a principal being edited or created, the Allow as Service attribute is automatically selected.
Administration Deleting a Service Principal Deleting a Service Principal The Security Server requires several specific principals. If these principals are accidentally deleted, you must restore the principal database from a backup tape. If you need to delete a service principal that had a random key extracted to the service key table, you must remove the entry from the v5srvtab service key table file, using the following procedure. To delete a service principal Step 1.
Administration Extracting Service Keys Extracting Service Keys Unlike users who type their passwords at a keyboard, a service principal needs to have its secret key automatically available during authenticaton. This is done by storing the secret key for the service principal in a file called a service key table on the host where the service resides. The service key table, v5srvtab, contains service principal names and their corresponding keys.
Administration Extracting Service Keys Step 8. Select Generate New Random Key before Extracting. This option is recommended for increased security as it generates a new random key before the principal and key are extracted to the service key table. Step 9. Click OK to extract the principal and its key to the service key table. If a service key table file does not exist in the selected directory, then a new file is created. A service key table file cannot be created if the selected directory does not exist.
Administration Extract Service Key Table window Extract Service Key Table window The Extract Principal Key to Service Key Table window is used to extract the key for a service principal to the service key table (v5srvtab). As a service does not enter a password using the keyboard, its secret key must be stored in a table. The key is obtained from the table when this service is invoked. This window is opened by using the Edit menu in the Principal Information window.
Administration Extract Service Key Table window Service Key Table Name The Name box shows the default location and name of the service key table. Enter a new service key table name in this box if you want to use a service key table other than the default v5srvtab. If you change from the default name, you must also edit the KeyTab environment variable setting on the service’s host. File button Select a new path or name for the service key table file.
Administration Using Groups to Control Settings Using Groups to Control Settings You can modify the default values used for new principals in the Principal Information window. These default values are stored in a default group for the realm. Each realm has one default group. The values you specify for the default group are inherited by all new principals in that realm. A default group is similar to a template, that controls the settings for a new principal. This template is called default@REALM.
Administration Group Information window (Principal Information window) Group Information window (Principal Information window) The Group Information window is used to view or modify the settings used by the default group for the realm. This default group is similar to a template in that it is used to control the settings for new principals added to the realm. Changing the settings for the default group does not affect the settings for existing prinicpals in the realm.
Administration Group Information window (Principal Information window) To open this window, use the Edit menu to the Principal Information window. Select Edit Default Group. Figure 6-7 Group Information Window Group Displays the default group principal name. Group Information Tabs The fields in these tabs correspond exactly to the tabs in the Principal Information window.
Administration Group Information window (Principal Information window) Principal Attributes Each principal must be assigned attributes to control the usage and rights of the account. This section describes the possible attributes and the default settings. Setting the Default Group Principal Attributes Before you begin adding principals to the database, you should review the attributes and properties assigned to the default group principal, default@REALM, and establish a set of base attributes for it.
Administration Setting Administrative Permissions Setting Administrative Permissions Use the kadminl_ui window to assign administrative permissions to users. When a principal is assigned administrative permissions, the principal and its permissions are saved to the admin_acl_file located on the primary security server. We recommend the convention of adding a principal with the instance /admin to identify a principal who is an administrator.
Administration Administrative Permissions Administrative Permissions Use this window to assign administrative permissions to users. Varying levels of permissions can be assigned. Any combination or all permissions can be assigned to a single user. There are eight permissions that can be assigned under the KDC for the current realm or for all realms. If you assign permissions for the current realm only the administrator can perform administrative tasks only within the realm.
Administration Administrative Permissions Principal Displays the name of the Principal you are editing. You should add an additional principal account with the /admin instance for the individual requiring administrator privileges. Add Principals Select this box to allow this principal to add new principals to the principal database. Delete Principals Select this box to allow this principal to delete principals from the principal database.
Administration Administrative Permissions • Restricted administrator in both This Realm and All Realms fields - Restricts actions on admin_acl_file entries that belong to any realm supported by the primary security server. Administrative principals who have the Restricted Administrator modifiers are not restricted from managing principals that are not included in the admin_acl_file.
Administration Realms Tab Realms Tab The kadminl_ui window can be opened by executing the following command at the command line prompt, # /opt/krb5/admin/kadminl_ui The opens the main window - Kerberos Administrator. Click on the Realms tab in the Kerberos Administrator window. This window can be used to add or delete realms. Figure 6-9 Chapter 6 Realms Tab List of Realms Displays a list of all the available realms. New button Click on this button to create a new realm.
Administration Realms Tab Delete Button Click on this button to delete a realm. You must select an entry to enable this button. Realm Information window (Realms tab) The Realm Information is used to add realms. To invoke this window, click on New in the Kerberos Administrator window. Figure 6-10 Realm Information Window (Realms Tab) Realm 164 Enter the name of the new realm here.
Administration Adding a Realm Adding a Realm A realm is a collection of principals that reside in the same administrative domain. Your network naming scheme, network topology, security policy and company organization determine which principals and services you put in a relam. Within a realm, all prinicpals share the same security and administrative policy. When you add a realm, kadminl_ui automatically creates some reserved principals, which must remain in the database. To add a realm Step 1.
Administration Deleting a Realm Deleting a Realm When you delete a realm, all the principals for that realm are not deleted from the database. To delete the principals form the database, you need use either the Adminsitrator or the Command-Line-Adminsitrator. Refer to “Deleting a Principal” on page 129, for more information. To delete a realm Step 1. In the kadminl_ui window, choose the Realms tab. Step 2. In the List of Realms box, selected the realm to be deleted and then click Delete.
Administration Remote Administrator - kadmin_ui Remote Administrator - kadmin_ui The Remote Administrator, kadmin_ui, is the GUI based Administrator that runs on the Secondary Security Servers and the clients. This program is used by principals with administrative privileges. It also enables administrators to maintain the database on the primary security server from their work stations on an on-going basis.
Administration Remote Administrator - kadmin_ui Step 2. The following screen appears: Figure 6-11 Logon Window (Remote Administrator) Step 3. Enter your principal name and password. You are prompted to change your password.
Administration Remote Administrator - kadmin_ui NOTE This screen is displayed only when you first logon using the Remote Administrator. Step 4. If you do not have the administrative privileges you will be unable to access the Kerberos database. The following message is displayed. Figure 6-13 Warning Message (Remote Administrator) Step 5. If you have the appropriate administrative permissions, you will be able to access the database using the Remote Administrator.
Administration Manual Administration Using kadmin Manual Administration Using kadmin The Command-Line-Administrator is the program used to administer the principal database. It allows principals with administrative privileges to maintain the principal database using this command line tool. Each user, client or service that is authenticated by the security server must be included in the principal database.
Administration Manual Administration Using kadmin The Local Command-Line-Administrator, kadminl, can be invoked only by a root user. To log in to the Remote Administrator, kadmin, you must use a principal account that has an entry in the admin_acl_file. For complete access to all the functions, use an unrestricted administrative principal account, one with the ‘*’ permissions in the admin_acl_file. At a minimum, the account must have the inquire privileges.
Administration Manual Administration Using kadmin We recommend that the Graphical user Interface be used for all administrative purposes. Add a New Principal To add a principal to the database, use the kadmin add command. This command requires the “add” administrative privilege to be specified in the admin_acl_file. This command adds a new principal with the specified name and password to the principal database.
Administration Manual Administration Using kadmin command: addrnd Name of Principal to add: admin Principal added Specify New Password The cpw command enables you to specify a new password for the principal selected.
Administration Manual Administration Using kadmin The general syntax for deleting a specified principal: command: del For example, to delete the principal “admin”, you would do the following: command: del Name of Principal to delete: admin Principal removed You are not alerted with a confirmation message on deletion of a principal. Extract a Principal The ext command securely extracts a principal’s key into a local service key table file.
Administration Manual Administration Using kadmin [-p keytype] Defines the key type for the primary key, and extracts it to the service key table file. Supported values for keytype are 1 for DES type and 5 for 3DES type. [-a keytype] Defines the key type for the secondary key and extracts it to the service key table file. Supported values for keytype are 0 for no secondary key, 1 for DES and 5 for 3DES.
Administration Manual Administration Using kadmin Number of authentication failures (fcnt) Specify the number of failed authentication attempts the principal is allowed. The number must be an integer between 0 and 255. Key Version Number (vno) The number must be an integer between 0 and 255. When you create a principal, its key version number (vno) is 1 and then it automatically increments by one each time the key is changed. You can manually change the key version number using this command.
Administration Manual Administration Using kadmin Command: mod Name of Principal to Modify: admin Parameter Type to be Modified (attr,fcnt,vno or quit) :fcnt Failure Count (or quit): Principal modified. Key Version Number Attribute Every principal password has an associated version number that identifies the number of times the password has been changed. When a principal is created, its password version number is inherited from the default group template.
Administration Manual Administration Using kadmin Allow Postdated Attribute The Allow Postdated attribute determines whether a principal is allowed ticket postdating. Postdating is a mechanism that allows a principal to obtain a ticket that is initially invalid but becomes valid in the future.
Administration Manual Administration Using kadmin • NOTE Service principal, the server can issue a renewable ticket for the service Before the server issues a renewable service ticket, the requesting user must possess a renewable TGT.
Administration Manual Administration Using kadmin Command: mod Name of Principal to Modify: admin Parameter Type to be Modified (attr,fcnt,vno or quit) :attr Attribute (or quit): {forward|noforward} Principal modified. Allow Proxy Attribute The Allow Proxy attribute determines whether a principal is allowed proxy tickets. Proxy tickets allow applications that a principal accesses with a TGT to request a special class of service ticket.
Administration Manual Administration Using kadmin Allow Duplicate Session Key Attribute The Allow Duplicate Session Key attribute determines whether a principal is allowed to use a duplicate session key. A duplicate session key, applies to user-to-user authentication, determines which key is used to encrypt the requested service tickets. This setting controls the security protocol between an initiator, typically a client application, and acceptor, typically a service.
Administration Manual Administration Using kadmin • NOTE Service principal, the service accepts TGTs only from user principals who obtained a TGT using a preauthentication protocol Client applications require preauthentication by default; however, a client can override this setting.
Administration Manual Administration Using kadmin Lock Principal Attribute The Lock Principal attribute determines whether a principal account is usable. A locked principal exists in the principal database but is unable to use or provide security network services. The Lock Principal attribute applies to both user and service principals.
Administration Manual Administration Using kadmin To modify the parameter type attr of the principal admin, to set the Allow as Service Attribute, you need to do the following: Command: mod Name of Principal to Modify: admin Parameter Type to be Modified (attr,fcnt,vno or quit) :attr Attribute (or quit): {svr|nosvr} Principal modified.
Administration Manual Administration Using kadmin The notgt command in kadmin is equivalent to selecting the Require Initial Authentication on the Attributes tab of the Administrator; the tgt command in the kadmin is equivalent to clearing the Require Initial Authentication check-box on the Attributes tab. You can use the kadmin inq command to view this principal’s attribute. With Require Initial Authentication selected (tgt), the inquire command shows TGT_BASED in the attributes field.
Administration Manual Administration Using kadmin Normally, you would select the Set As Password Change Service attribute for only the service principal defined as a change password service. You can add other Change Password service principals to the principal database if you have created custom applications that require different password service principals.
Administration Manual Administration Using kadmin If the user ignores the advance notice and the expiration date elapses, the user must change the password before they can obtain any more tickets from the security server. As the expiration time is calculated from the time a new principal is added to the database, the password change load on the server is distributed over time.
Administration Manual Administration Using kadmin You may choose to set a maximum ticket lifetime for the default group template that is different than the krbtgt/ principal if you plan to enter a block of users that should have restricted ticket lifetimes. After the block of user principals are added, you can alter the default group setting again. This attribute cannot be set with Command-Line-Administrator.
Administration Manual Administration Using kadmin This attribute cannot be set with Command-Line-Administrator.
Administration Principal Database Utilities Principal Database Utilities The principal database utilities are tools that you can use to globally manage the principal database. Use these tools only if the database was not properly created or configured during installation, or if you are debugging or upgrading your security server. To use the principal database utilities, you must have operating system administrative privileges or logged on as the root user.
Administration Creating the Kerberos Database Creating the Kerberos Database The primary security server contains a database of all principals that are trusted in each of the supported realms. The database can also be created during installation, refer to “Auto-Configuration of the Security Server” on page 64, for more information. The kdb_create utility creates a database and adds a realm to the existing database.
Administration Creating the Kerberos Database • 3DES or 5: DES-CBC-MD5 (default) -f keyfile When used with the -s switch, it specifies an alternate name for the stash file. If you do not use the -f switch, the default keyfile is .k5.REALM. -M mkeyname Specifies an alternate primary principal name. The default primary name is K/M@REALM. -p PASSWORD Suppress the kdb_create from prompting you for the master password, which makes it easier to configure a database with a shell script.
Administration Creating the Kerberos Database IMPORTANT • kadmin/@ • kcpwd/@ • krbtgt/@ The principals mentioned above should NOT be deleted. The K/M keyname is the default master-key-name. However, the master-key-name can be changed by specifying the tag when using the -M mkeyname option in kdb_create command.
Administration Creating the Kerberos Database Encrypt the database using the DES encryption if you are installing a secondary security server that has an existing principal database encrypted using DES. In this case, do not create the database during installation, instead use the kdb_create utility to create the database after installation. Regardless of the database encryption choice, the installation program always installs both DES and 3DES algorithms.
Administration Destroying the Kerberos Database Destroying the Kerberos Database The kdb_destroy utility securely removes the principal database. This utility runs on the primary and secondary security servers. If you run this utility using the command line options, it prompts you with a confirmation and then removes the default principal database, /krb5/prinicpal. To confirm the request, you must type the word “yes”; else kdb_destroy returns the message “Database not destroyed”.
Administration Dumping the Kerberos Database Dumping the Kerberos Database The kdb_dump utility copies the contents of the principal database to stdout or to a text file. By default, the output is displayed to a terminal via stdout. NOTE You must be a root user to run this program. The general syntax for this is: kdb_dump [-f filename] The kdb_dump utility uses the following options: -f filename Specifies a destination file name and path to store the output.
Administration Loading the Kerberos Database Loading the Kerberos Database The kdb_load utility loads the database with the principal entries from a database dump text file. This utility over-rides the existing database entries with the corresponding entries that are present in the dump file. Principals in the existing database that are absent in the dump file are not changed or removed. We recommend that you run the kdb_load utility on the primary servers only.
Administration Stashing the Master Key Stashing the Master Key The kdb_stash utility stores the master key, the encrypted master password, to a disk file. This utility runs on the primary and secondary security servers. Use the kdb_stash utility to store the master key to a stash file. You must specify the same key type and master password that you specified when you created the database. NOTE If you have used the kdb_create -s utility to create your database, you already have a stash file.
Administration Stashing the Master Key Given below is an example of using the kdb_stash: shell% kdb_stast -f Enter password: Re-enter password for verification: Chapter 6 199
Administration Starting and Stopping Daemons Starting and Stopping Daemons There are certain situations that require you to stop services and daemons and start them up again in order for changes to take effect. Table 6-6 lists and briefly describes these situations and the related services and daemons that require stopped and re-started.
Administration Maintenance Tasks Maintenance Tasks There are various maintenance tasks associated with Kerberos Security Servers. This section describes: • Protecting Security Server Secrets • Backing Up Primary Server Data Protecting Security Server Secrets Kerberos Security Server stores two types of secrets, namely: • host/fqdn@REALM service prinicpal • Master Password It is crucial that these secrets not be compromised.
Administration Backing Up Primary Server Data Backing Up Primary Server Data It is a good idea to backup the several critical primary server files. Save the copied information to a CD or tape - whatever your preferred archive method is. Be aware that primary server files contain sensitive information; therefore, you should not copy these unless you intend to properly secure the backup copies. Ensure to make backup copies of the following: • admin_acl_file • password.policy (password.
Administration Backing Up Primary Server Data To perform backup: 1. Stop the services and daemons • run this command as a root user /sbin/init.d/krbsrv stop 2. Copy the principal.dat, principal.idx, and principal.ok files from one of the propagation servers to your desired destination. For example, CD-ROM or tape. • the files are located at /opt/krb5 3.
Administration Removing Unused Space From the Database Removing Unused Space From the Database After long and continued use, the principal database on the primary server can grow large due to unused space. When a principal is deleted, the space that the record occupied is not removed. Instead, the space is reserved and marked as "available". Therefore, with extended use, the database can grow very large. Correct the situation by loading all existing principals into a new database.
Administration Removing Unused Space From the Database /sbin/init.d/krbsrv start 8. Remove the /tmp/filename file after you have verified that the new database is functioning without problems.
Administration Removing Unused Space From the Database 206 Chapter 6
7 Propagation This chapter describes the tools and procedures that will help you to propagate the Kerberos database from the Primary Security Server to the Secondary Security Servers.
Propagation Chapter Overview Chapter Overview This chapter contains the following sections: 208 • “Propagation Hierarchy” on page 209 • “Service Key Table (v5srvtab)” on page 210 • “Propagation Tools” on page 212 • “kpropd” on page 214 • “mkpropcf” on page 215 • “kpropd.
Propagation Propagation Hierarchy Propagation Hierarchy To grant authentication to users on the network, each Secondary Server must have the latest copy of the principal database, at all times. Secondary servers obtain the copy of the principal database from the Primary Security Server using the database propagation service. At predefined intervals, the database propagation service automatically copies database modifications from the primary server to its associated secondary servers.
Propagation Service Key Table (v5srvtab) Service Key Table (v5srvtab) The Service key table file (v5srvtab) contains service principal names with their corresponding secret keys. This file must be stored on the system that hosts the service or application that requires an extracted key. Secured application servers use the keys in this file to decrypt data packets that the security server encrypts using a copy of the same key.
Propagation Service Key Table (v5srvtab) Step 2. command: ext Name of Principal (host/fqdn@REALM): Service Key Table File Name (/opt/krb5/v5srvtab): Principal modified Key extracted Creating a New Service Key Table File Each secured daemon requires a service principal account and the principal’s key must be extracted to a service key table file. When you create a new service key table file, you must consider the number of daemons that reside on the system.
Propagation Propagation Tools Propagation Tools Propagation of the principal database is managed and performed on each server in the propagation hierarchy by the kpropd daemon. It uses four local files, namely: • prop_q - Default propagation input queue file that contains the names of each and every principal whose record has changed since the last successful database propagation. • prop_q.wrk - Temporary working copy of prop_q, the default propagation input queue file.
Propagation Propagation Tools These tools have been discussed in detail in the subsequent sections of this chapter.
Propagation kpropd kpropd The kpropd daemon propagates the principal database from one server to another. This daemon runs on startup of the security server. It propagates principal records from a given security server to the kpropd on the receiving security server or the propagation plug-in on the receiving security server, if kpropd is not running on this security system.
Propagation mkpropcf mkpropcf The mkpropcf tool creates the kpropd.ini file, which is the default propagation configuration file in a propagation hierarchy. The mkpropcf tool exports the kpropd.ini file to the secondary servers. This file can be located at the following directory: /opt/krb5/install/mkpropcf When the mkpropcf is executed on the primary security server without any arguments, it creates the krpopd.ini file in the /opt/krb5 directory.
Propagation mkpropcf -f Used in conjunction with the -i option to explicitly overwrite existing kpropd.ini file. To synchronize the kpropd configuration, it is recommended to export the original configuration,kpropd.ini, on the primary to export.ini, and then copy the export file to each of the secondary servers and run, mkpropcf -i export.
Propagation kpropd.ini kpropd.ini The kpropd.ini file is the propagation configuration file mkpropcf creates using the information from the local krb.conf file. This file is generally located at: # /opt/krb5 Ensure that only authorized users have access to this file. Unauthorized access to kpropd.ini could jeopardize the integrity of your realm. Intruders who modify or replace entries could also modify your principal database.
Propagation kpropd.ini key_phrase = value • Any character following a a pound sign (#) on a given line is ignored as comments. Blank lines are ignored. • Use a backslash (\) to specify a line extension. Sections kpropd.ini stores configuration parameters important to propagation. This file contains the following sections: • The [default_values] section controls the various global propagation properties.
Propagation kpropd.ini NOTE Intervals less than 15s could generate too much network traffic during peak authentication times. key_exp=n[s|m|h|d] Specifies the length of time a session key is valid, where n, indicates the number of seconds, minutes, hours, or days. The default is value six hours (6h). The default unit is hours.
Propagation kpropd.ini port=port_name Specifies the communication port over which to propagate the database. The value can be a well known service or a numeric value, but must be listed in the Services file. The default port is kerberos-adm. primary_realm=DEFAULT_REALM Specifies the default realm of the primary security server. If the krb.conf file does not exist, the DEFAULT REALM is assigned the uppercase equivalent of the domain name. realms=[all|realm1[, realm2][,...
Propagation kpropd.ini child[n]=fqdn Specifies secsrv_name’s child security server in the propagation hierarchy, where fqdn is the fully qualified domain name of the child server. A security server can have zero or more child servers. If more than one child server receives propagated records from secsrv_name, include a complete child configuration line for each additional child, where each child is uniquely numbered with the suffix n, beginning with child1.
Propagation kpropd.ini As the krb.conf file cannot describe a propagation hierarchy where secondary servers themselves have secondary servers, you must edit the kpropd.ini file to support such relationships.
Propagation prpadmin prpadmin prpadmin is an administrative application that runs on all security servers and helps you manage the propagation system. For example, to propagate the full contents of the primary principal database to all secondary security servers, execute the prpadmin full_dump command on the primary security server. This application can be located at # /opt/krb5/admin You can run prpadmin from the command line or in a shell-like command loop.
Propagation Setting Up Propagation Setting Up Propagation Once your primary and secondary servers are installed and configured, you must propagate principal database information from the primary server to all secondary servers. Before you can configure propagation, each secondary server must have an existing principal database to act as a container for the information being propagated to the server. The principal database is created during installation.
Propagation Setting Up Propagation Table 7-2 lists the daemons, and briefly describes their functions. To avoid confusion and redundancy in this section when using names, the table also indicates the generic names this document will use to discuss the daemon. Table 7-2 Primary Server Services and Daemons Daemon Name Function Generic Usage Name kadmind Accepts administration requests from the administrator and database propagation requests from propagation daemon, kpropd.
Propagation Setting Up Propagation # mkpropcf This creates the kpropd.ini file, which defines your propagation hierarchy. NOTE If you do not want to use the default hierarchy structure (a two-tier system) you must edit the kpropd.ini file to contain your preferred hierarchy. Refer to “kpropd.ini” on page 217, for more details on this file. 4. Copy the kpropd.ini file to the secondary server. 5.
Propagation Setting Up Propagation Step 4. Kill all the running daemons on the secondary server and extract the service key 1. Kill the daemons on the secondary server, using the following command: # /sbin/init.d/krbsrv stop 2. Extract the service key, using the following command: # /opt/krb5/bin/kadmin -R ext NOTE The is the same as the one added in Step 2, on the primary server. Step 5. Start the admin daemon on the secondary server 1.
Propagation Setting Up Propagation nnn.nnn.nnn.nnn is the IP address of the secondary server. If the primary server propagates to multiple secondary servers, the message sequence is displayed for each secondary server. Step 7. Start the kdcd and the propagation daemon on the secondary server and verify whether the daemons have started 1. Start the kdcd daemon # /opt/krb5/sbin/kdcd 2. Start the propagation daemon # /opt/krb5/sbin/kpropd 3.
Propagation Monitoring Propagation Monitoring Propagation It is important to monitor database propagation between servers on a regular basis. Monitoring helps identify two potential problems: • Primary-secondary link failure • Stalled propagation Monitoring requires examining the log file and the propagation queue files. When propagation problems occur, the copies of the database on the secondary servers can become out of sync with the database on the primary server.
Propagation Monitoring Propagation connect delay is seconds sec [hostname of peer] Can’t connect to subscriber to propagate principal database information [hostname of peer] could not get service ticket [hostname of peer] full_dump failed [hostname of peer] not enough memory to allocate work buffer Not enough free system resources to run or start the propagation system. Propagation system aborting. Not enough system resources free to read from propagation queue. Propagation system aborting.
Propagation Monitoring Propagation times a day. For example, if a prop_q.wrk file exists with a file creation date older than 24 hours from current time, or if the prop_q file size is unusually large, the propagation cycle may very likely be stalled. Another example would be if a prop_hostname file that is older than 48 hours or is unusually large, this indicates a propagation problem between the primary and secondary servers as specified in hostname. principal.
Propagation Monitoring Propagation • Number of principals does not match • An authentication test to the primary server succeeds but fails on the secondary server Authentication Problems Occur The out-of-sync condition may first appear as an intermittent authentication failure. In this scenario, a prinicpal that changes the password, perhaps after the password expires, is not able to authenticate, even though the password change is successful.
Propagation Monitoring Propagation Log Files Indicate Problems If an examination of the logs for the primary server and the secondary servers suggests propagation problems, then your set of clues is nearly complete. If kpropd is not running on the primary server and each secondary server, then you can be certain that an out-of-sync condition exists. Number of Principals Does Not Match The number of principals on both machines should be identical or close.
Propagation Monitoring Propagation Step 1. On a secondary server, stop the daemons and then from the /opt/krb5/admin directory, run the kdb_dump utility using the following syntax: # /opt/krb5/admin/kdb_dump -f /tmp/secondary.db Step 2. From the primary server, stop the daemons and then repeat the procedure: # /opt/krb5/admin/kdb_dump -f /tmp/primary.db Step 3. Restart the daemons on both the primary and the secondary. Step 4.
Propagation Monitoring Propagation Restarting Propagation Using the Full Dump Method An alternate process to the simple method is one that clears out the propagation directory and restarts kpropd, which then starts a full dump of the database to all secondary servers. The following procedure initiates a full database dump to all the secondary servers for that primary server.
Propagation Monitoring Propagation Step 4. Verify that the date/time is the same among all security servers. Synchronize time on all the servers to match the primary security server time. Step 5. Check resource utilization on the server. If there is 100 percent utilization of a file system, it can prevent kpropd from building queue files, which will cause propagation to stall or fail. Remove unnecessary files, and archive log files. Step 6.
Propagation Monitoring Propagation • admin_acl_file • password.policy • kpropd.ini Step 3. Make an archive of the principal.* files on the secondary server Step 4. Remove the Kerberos Server software on the secondary server Step 5. Install the Kerberos Server software on the former secondary server. Do not create the database during installation. Step 6. Restore the principal.* database files archived in Step 3 Step 7. Restore the original files retrieved from the primary server in Step 2.
Propagation Monitoring Propagation This can all be executed with shell scripts and cron jobs if desired.
Propagation Configuring for Multi-realm Enterprises Configuring for Multi-realm Enterprises When you support multiple realms, there are additional configuration steps required for both the Security Servers and Clients. This section addresses the Server requirements. Number of Realms per Database A single Primary Security Server can support more than one realm.
Propagation Configuring for Multi-realm Enterprises Multiple Primary Servers That Support A Single Realm You must have one Primary Server for each realm, if you have a de-centralized administrative groups where each group maintains its own realm information. You cannot propagate changes from one Primary Server to another. You can only propagate changes from a Primary Server to a Secondary Server.
Propagation Configuring for Multi-realm Enterprises You can follow the standard propagation configuration if you have configured a multi-realm environment that has only one realm for every Primary Security Server. In other words, you have multiple Primary Security Servers or if you want to propagate all realms from the Primary Server to each Secondary Server, follow the steps mentioned below. In the following steps, we assume you are familiar with the propagation setup procedure.
Propagation Configuring for Multi-realm Enterprises 242 Chapter 7
8 Inter-realm This chapter describes the procedures that will help you to setup and configure inter-realm authentication between Kerberos Servers.
Inter-realm must be established between the two realms. This chapter explains how to set up and manage multiple realms.
Inter-realm Considering Trust Relationships Considering Trust Relationships You may establish a multiple realm environment within your enterprise. Regardless of the reason, if principals in one realm need access to secured services supported in a different realm, you must establish a trust relationship between the realms. When two distinct realms share secret keys, the two realms are said to trust one another.
Inter-realm Considering Trust Relationships In simple terms, if Harry trusts Sally with his secrets, and Sally trusts Harry with her secrets, Harry and Sally have a two-way trust relationship between them. Hierarchical Trust In inter-realm authentication, hierarchical trust allows principals in one realm to access resources in another realm if there is a chain of trust established between the realms. The chain relies on a hierarchical realm naming scheme. For example, IT.BAMBI.COM and DEER.JUNGLE.
Inter-realm Configuring for Multi-realm Enterprises Configuring for Multi-realm Enterprises When you support multiple realms, there are additional configuration steps required for both the Security Servers and Clients. This section addresses the Server requirements. Number of Realms per Database A single Primary Security Server can support more than one realm.
Inter-realm Configuring for Multi-realm Enterprises Multiple Primary Servers That Support A Single Realm You must have one Primary Server for each realm, if you have a de-centralized administrative groups where each group maintains its own realm information. You cannot propagate changes from one Primary Server to another. You can only propagate changes from a Primary Server to a Secondary Server.
Inter-realm Configuring for Multi-realm Enterprises You can follow the standard propagation configuration if you have configured a multi-realm environment that has only one realm for every Primary Security Server. In other words, you have multiple Primary Security Servers or if you want to propagate all realms from the Primary Server to each Secondary Server, follow the steps mentioned below. In the following steps, we assume you are familiar with the propagation setup procedure.
Inter-realm Configuring Direct Trust Relationships Configuring Direct Trust Relationships If the Kerberos Security Servers manage each and every realm in a multi-realm environment, you must add inter-realm principals to the principal databases for each realm. Inter-realm principals are special-case krbtgt/REALM1@REALM2 principal accounts.
Inter-realm Configuring Direct Trust Relationships The Kerberos Server returns a failure for any of the following reasons: • If the client authentication fails. • It does not recognize the realm listed in the inter-realm ticket, that is, a proper trust relationship between the realms has not been established. • It does not recognize the requested service principal, and has no further trust relationships for which it returns an inter-realm ticket.
Inter-realm Hierarchical Inter-realm Trust Hierarchical Inter-realm Trust Hierarchical inter-realm authentication is used when one realm does not have a direct path to its destination realm, but has a path to an intermediate realms. A Hierarchical Chain of Trust Inter-realm trust can be transitive, for example if realm A trusts B and B trusts C, then a client in A can get a ticket from C by following the trust path from A to B to C. For example, realm 1 could be X.Y.A and realm 2 could be X.Y.
Inter-realm Hierarchical Inter-realm Trust Now VIBGYOR.INDIGO.COM has a direct trust relationship established with both RED.BLUE.COM and GREEN.YELLOW.COM. Hence, RED.BLUE.COM can obtain an inter-realm ticket through the intermediate realm, VIBGYOR.INDIGO.COM. The client in RED.BLUE.COM requests for an inter-realm ticket from VIBGYOR.INDIGO.COM, and can then use this inter-realm ticket, that was obtained, to contact GREEN.YELLOW.COM for a ticket to use a service in its realm.
Inter-realm Hierarchical Inter-realm Trust • Figure 8-1 krbtgt/IT.JUNGLE.COM@BAMBI.COM allows the server in IT.JUNGLE.COM to accept tickets from BAMBI.COM Hierarchical Inter-realm Configuration For inter-realm authentication in the other direction, two-way hierarchical inter-realm authentication, these principals must also be added: 254 • krbtgt/FINANCE.JUNGLE.COM@BAMBI.COM allows the server in FINANCE.JUNGLE.COM to accept tickets from BAMBI.COM • krbtgt/BAMBI.COM@IT.JUNGLE.
Inter-realm Hierarchical Inter-realm Trust Step 1. Steps for configuring the Local Realm For these steps, the local realm is FINANCE.JUNGLE.COM and the intermediate realm is BAMBI.COM. In the FINANCE.JUNGLE.COM realm: 1. Using the Kerberos Server’s Administrator in the FINANCE.JUNGLE.COM realm, add the krbtgt/BAMBI.COM@FINANCE.JUNGLE.COM principal, which allows users in the FINANCE.JUNGLE.COM realm to authenticate with the server in the BAMBI.COM realm.
Inter-realm Hierarchical Inter-realm Trust NOTE Each intermediate realm has four keys if you are performing two-way inter-realm authentication. In the BAMBI.COM realm: 1. Using the Kerberos Server’s Administrator, add the krbtgt/BAMBI.COM@FINANCE.JUNGLE.COM principal, which allows users in the FINANCE.JUNGLE.COM realm to authenticate with the server in the BAMBI.COM realm. Enable the same settings for the principal, krbtgt/BAMBI.COM@FINANCE.JUNGLE.COM, as used for the principal, krbtgt/BAMBI.COM@FINANCE.
Inter-realm Hierarchical Inter-realm Trust Step 3. Steps for configuring the Target Realm For these steps, the name of the intermediate realm is BAMBI.COM and the name of the target realm is IT.JUNGLE.COM. In the IT.JUNGLE.COM realm: 1. Using HP’s Kerberos Server Administrator, add the krbtgt/IT.JUNGLE.COM@BAMBI.COM principal, which allows users in the BAMBI.COM realm to authenticate with the server in the IT.JUNGLE.COM realm.
Inter-realm Hierarchical Inter-realm Trust 258 Chapter 8
9 Troubleshooting Troubleshooting problems may require you to investigate many hardware and software components. Some problems can be quickly identified and resolved.
Troubleshooting version incompatibilities, insufficient HP-UX resources, corrupt configuration shell scripts, and programming or command errors. Other problems require more investigation. Once identified, most problems can be resolved by the programmer, user, or node manager, using the suggestions in this chapter or the error messages documented in the link installation manuals. However, there may be problems that you should report to your Hewlett-Packard support contact.
Troubleshooting Chapter Overview Chapter Overview The strategy and tools to use while investigating the software and hardware components are provided in this chapter.
Troubleshooting Characterizing the Problem Characterizing the Problem It is important to ask questions when you are trying to characterize a problem. Start with global questions and gradually get more specific. Depending on the response, ask another series of questions until you have enough information to understand exactly what happened.
Troubleshooting Characterizing the Problem • Data corruption. • Logging messages at the syslog. Knowing what has recently changed on your network may also indicate whether the problem is software-related or hardware-related.
Troubleshooting Diagnostic Tools Summary Diagnostic Tools Summary The most frequently used diagnostic tools are listed below. These tools are documented in the link installation manuals. Table 9-1 Diagnostic Tools netstat A nodal management command that returns statistical information regarding your network. landiag A diagnostic program that tests LAN connections between HP 9000 computers.
Troubleshooting Troubleshooting Kerberos Troubleshooting Kerberos When troubleshooting problems with Kerberos, you need a reference point to work from. For example, does the problem exist on the remote system or on the local system? However, the terms “local” and “remote” are limited in their description of complex communications, such as when a local system logs onto a remote system and then the remote system logs back onto the local system.
Troubleshooting Troubleshooting Kerberos Unix Syslog File Each security server daemon, kadmind, kpropd, and kdcd writes to the system log (syslog) file. However, you can also configure the daemons to write the system logs to any file specified by you. However, principal database operations performed locally on the primary server using the Administrator are not recorded as these programs do not use syslog to audit their activities. The syslog daemon (syslogd) is configured using the /etc/syslog.
Troubleshooting Troubleshooting Kerberos • Run the service to your own node. To do this, your node name and internet address must be in the /etc/hosts file. If the server is successful, then the client and the server halves of the service operate correctly. This provides a starting point to determine where problems are occurring. Troubleshooting Techniques The following section describes various scenarios for potential problems.
Troubleshooting Troubleshooting Kerberos Table 9-2 Table of Errors Messages (Continued) Clock skew too great in KDC reply while getting initial credentials This generally occurs because the system’s clock deviates too much from the time on the authenticating KDC. You are, generally, allowed upto five minutes of clock skew. Requesting host principal without fully-qualified domain name. The host uses /etc/hosts to resolve name lookups before dns.
Troubleshooting Troubleshooting Kerberos Table 9-2 Chapter 9 Table of Errors Messages (Continued) Required parameters in krb.realms missing while initializing the Kerberos context Missing or incorrect parameters in the krb.realms file. Stored master key is corrupted while initializing kadminl interface If the stash file is corrupted this message appears. Cannot find/read stored master key while getting the master key.
Troubleshooting Troubleshooting Kerberos Table 9-2 270 Table of Errors Messages (Continued) Cannot find/read stored master key while getting master key Stash file not found Provide the master key as a command line option. You can also create the stash file.
Troubleshooting General Errors General Errors • Ensure that the Domain Name Server (DNS) is working properly. Several aspects of Kerberos rely on this name service. It is important that your DNS entries and your hosts have the correct information. Each host’s canonical name must be a fully-qualified host name, including the domain, and each host’s IP address must reverse-resolve the canonical name. • Ensure that you remove all trailing spaces in the configuration files.
Troubleshooting General Errors security administrator may have purposefully locked a principal account so it could temporarily not be used. In each case, the principal remains in the principal database, but is unable to use Kerberos services. To unlock a principal account, use either the Administrator or Command-Line-Administrator. Using the Administrator: 1. go to the Principal information window - Principals tab. 2. Select the Attributes tab 3.
Troubleshooting Typical User Error Messages Typical User Error Messages Your application users may encounter error messages while using the Kerberos Server. The following sections describe typical user error messages, explains why they might occur, and suggests how to avoid them.
Troubleshooting Administrative Error Messages Administrative Error Messages Following are some messages that administrative principals may encounter when using their accounts. This section also contains some recommended solutions. Password has expired while getting initial ticket Explanation: This message may occur when a user tries to log on as a remote administrator using the Remote Command-Line-Administrator, the kadmin command.
Troubleshooting Administrative Error Messages Command-Line-Administrator are set to use a 3DES key during authentication. If the principal does not have a 3DES key, the tools attempt to negotiate a supported key type. If that fails, this message is returned. Action: If the user is using Command- Line-Administrator, verify that the user is not entering an inappropriate key type during logon with the -e switch.
Troubleshooting Reporting Problems to Your Hewlett-Packard Support Contact Reporting Problems to Your Hewlett-Packard Support Contact If you do not have a service contract with HP, you may follow the procedure described below but you will be billed accordingly for time and materials. If you have a service contract with HP, document the problem as a Service Request (SR) and forward it to your Hewlett-Packard support contact.
Troubleshooting Reporting Problems to Your Hewlett-Packard Support Contact Chapter 9 • Try to determine the general area within the software where you think the problem exists. Refer to the appropriate reference manual and follow the guidelines on gathering information for problems. • Document your interim or “workaround” solution. The cause of the problem can sometimes be found by comparing the circumstances in which it occurs with the circumstances in which it does not occur.
Troubleshooting Reporting Problems to Your Hewlett-Packard Support Contact 278 Chapter 9
Glossary A-B admin_acl_file (Administrator Access Control List) This is a text file that lists the various administrators with their respective permissions. Administrator The graphical user interface that is used to administer the principal database of the Kerberos Server. Authentication Service (AS) Authentication is a verification of a user’s identity. The Authentication Service (AS) hands out a ticket-granting-ticket, which is turn is used to access the ticket-granting-service (TGS).
Glossary kpropd.ini kpropd.ini Propagation configuration file mkpropcf creates using information in the local krb.conf file. krb.conf File that contains configuration information that describes the default realm of the host, the administration server, and security servers for known realms. krb.realms The realms file defines host-to-realm or domain-to-realm name mapping data. The krb.realms file is located only on the Kerberos Server systems. This file maps hostnames to realms names.
Glossary v5srvtab ticket-granting-ticket This service issues tickets to connect to hosts in its own domain. V v5srvtab Binary file that contains service principal names and their corresponding secret keys.
Glossary ticket-granting-ticket 282 Glossary
Index Symbols #, 74 # comment, 95 ,, 25 /etc/hosts, 267 /etc/inetd.conf, 35 /etc/rc.config.d/krbsrv, 86 /etc/syslog.conf, 266 /opt/krb5/kadmind, 271 /opt/krb5/sbin, 64 /sbin/init.d/krbsrv start, 86 /var/adm/krb5/krb5kdc, 71 /var/adm/messages, 266 /var/adm/sw/swagent, 38 A ACL file, 94 acl format, 95 add, 172 adding realms, 240, 248 ADMD = 1, 86 admin_acl_file, 63, 85 administrative server, 94 Administrator, 93 AS, 28 ASN.
Index I identifier, 95 IETF, 25, 246 Incorrect net address, 268 incremental propagation, 214 inetd, 265 initial ticket, 25 initializing krb5, 267 inquire, 98 Install, 33, 93 Installation, 33 Installing the KDC Server, 33 instance, 95 Intermittent errors, 262 Internet Engineering Task Force, 19 interrealm authentication, 243 issuing tickets, 280 K K/M, 45 K/M@REALM principal, 106 KADM5, 94 kadmin.
Index ping, 264 Policies, 42 Policy Migration, 44 pound sign (#), 74 prop_hostname, 212 prop_hostname.ok, 212 prop_q, 212 prop_q.wrk, 212 Propagation, 239, 247 Propagation Hierarchy, 209 prpadmin, 212 R -r command, 35 REALM, 69 Related Documentation, 18 Related Software Product, 18 Remote Administrator, 93 remote requests, 94 Request for Comments, 19 RFC 1510, 19, 25, 53 RFC 1964, 19, 53 RFC 2743, 19 RFC 2744, 19 RFCs, 19 S sample kdc.conf, 76 sample krb.conf, 71 Sample krb.realms, 76 sample krb5.
