Kerberos Server Version 3.12 Administrator’s Guide HP-UX 11i v3 Edition 5 Manufacturing Part Number: 5991-7685 February 2007 United States © Copyright 2007 Hewlett-Packard Development Company, L.P.
Legal Notices Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor’s standard commercial license The information contained herein is subject to change without notice.
Contents 1. Overview Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How the Kerberos Server Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Authentication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DES Versus 3DES Key Type Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Configuration Files for the Kerberos Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The krb.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The krb.conf File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The krb.realms File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The krb.realms File Format .
Contents Starting the Security Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring the Secondary Security Servers with C-Tree. . . . . . . . . . . . . . . . . . . . . . Creating the Principal Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Copying the Kerberos Configuration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating a host/ Principal and Extracting the Key. . . . . . .
Contents General Tab (Principal Information Window) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Principals to the Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Multiple Principals with Similar Settings . . . . . . . . . . . . . . . . . . . . . . . . . . Creating an Administrative Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Searching for a Principal . . . . . . . . . . . . . . . . . . . . . . .
Contents Adding a New Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a Random Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying a New Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing Password to a New Randomly Generated Password . . . . . . . . . . . . . . . . Deleting a Principal . . . . . . . . . . . . . . . . . . . . . . . .
Contents Maintenance Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Protecting Security Server Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . host/fqdn@REALM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Master Password . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Contents Propagation Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Converting a secondary security server to a primary security server . . . . . . . . . . . Restarting Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cleaning the Temp Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuring Multirealm Enterprises . . . . . . . . . . . .
Contents Locking and Unlocking Accounts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clock Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Decrypt Integrity Check Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tables Table 1. HP-UX 11i Releases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Table 2. Publishing History Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18 Table 4-1. Table of Analogous Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .52 Table 5-1. Security Server Files That Require Configuration . . . . . . . . . . . . . . . . . . .62 Table 5-2. Wildcard Characters . . . . . . . . . . . .
Tables Table A-2. Configuration Worksheet Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figures Figure 1-1. Authentication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26 Figure 1-2. Integrating a Kerberos Principal in to the LDAP Directory . . . . . . . . . .31 Figure 8-1. Principals Tab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .137 Figure 8-2. Principal Information Window . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139 Figure 8-3. Change Password Window . . . . . . . . . . . . . .
Figures 12
About This Manual This manual describes how to install, configure, administer, and troubleshoot the Kerberos server on HP-UX. Intended Audience HP intends this manual for system managers or administrators responsible for configuring and maintaining the Kerberos server on HP-UX operating systems.
• Chapter 5, “Configuring the Kerberos Server With C-Tree Backend,” on page 61: Provides information on the configuration files required to configure the Kerberos server with C-tree as the backend database. • Chapter 6, “Configuring the Kerberos Server with LDAP,” on page 73: Provides information on the configuration files required to configure the Kerberos server with LDAP as the backend database.
Typographic Conventions This document uses the following typographic conventions: audit (5) An HP-UX manpage. In this example, audit is the name and 5 is the section in the HP-UX Reference. On the Web and on the Instant Information CD, it may be a link to the manpage itself. From the HP-UX command line, you can enter “man audit” or “man 5 audit” to view the manpage. See man (1). Book Title The title of a book. On the Web and on the Instant Information CD, it may be a link to the book itself.
HP-UX Release Name and Release Identifier Each HP-UX 11i release has an associated release name and release identifier. The uname (1) command with the -r option returns the release identifier. Table 1 lists the releases available for HP-UX 11i. Table 1 HP-UX 11i Releases Release Identifier Supported Processor Architecture Release Name B.11.11 HP-UX 11i v1 PA-RISC B.11.20 HP-UX 11i v1.5 Intel Itanium B.11.22 HP-UX 11i v1.6 Intel Itanium B.11.23 HP-UX 11i v2 Intel Itanium B.11.
Related Software Products Following are the products related to the Kerberos server: • PAM Kerberos delivered as part of the HP-UX Internet operating environment component. • KRB5 Client Software delivered as part of the core operating system. • GSS-API delivered as part of the core operating system.
• RFC 1510 - The Kerberos Network Authentication Service (V5) • RFC 1964 - The Kerberos v5 GSS-API Mechanism • RFC 2743 - Generic Security Service Application Program Interface • RFC 2744 - Generic Security Service API You can access these RFCs at the following Web site: http://www.ietf.org/rfc.html HP Encourages Your Comments HP welcomes any comments and suggestions you have on this manual. You can send your comments in the following ways: • Internet electronic mail: netinfo_feedback@cup.hp.
1 Overview This chapter provides an introduction to the Kerberos server v3.12 that is available on HP-UX 11i v3 operating systems.
Overview This chapter discusses the following topics: • “How the Kerberos Server Works” on page 24 • “Authentication Process” on page 25 • “DES Versus 3DES Key Type Settings” on page 28 • “Introduction to LDAP” on page 29 — “Integrating Kerberos Server v3.
Overview Introduction Introduction The term Kerberos was derived from the 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 a network. Kerberos is a mature network authentication protocol based on the RFC 1510 (The Kerberos Network Authentication Service (V5)) specification of the Internet Engineering Task Force (IETF).
Overview How the Kerberos Server Works How the Kerberos Server Works The basic currency of Kerberos is the ticket, which the user presents to use a specific service. Each service, be it a login service or an FTP service, requires a different kind of ticket. The applications on the Kerberos server keep track of all the various kinds of tickets. When you first log on to Kerberos each day, you enter your Kerberos password.
Overview Authentication Process Authentication Process The Kerberos server grants tickets to your user principal to access secured network services. You must authenticate the server by providing your user name and password. When the server authenticates you, it returns a set of initial credentials for you, including a TGT and a session key. The Kerberos server grants a service ticket for a specific service principal that can be associated with one or more Kerberos-secured services.
Overview Authentication Process Figure 1-1 illustrates the actions of the components and the Kerberos protocol in a secured environment. Figure 1-1 Authentication Process The following is a description of how a client and server authenticate each other using Kerberos: Step 1. Send a request for a ticket to the TGS that you want to access. You can choose to request specific ticket flags and specify the key type to be used to construct the secret key.
Overview Authentication Process • Server-indicates the TGS • Time stamp • Nonce Step 2. If the AS decrypts the message successfully, it authenticates the requesting user and issues a TGT. The TGT contains the user name, a session key for your use, and name of the server to be used for any subsequent communication. The reply message is encrypted using your secret key. Step 3. The client decrypts the message using your secret key.
Overview DES Versus 3DES Key Type Settings DES Versus 3DES Key Type Settings In the processes outlined in the section “Authentication Process” on page 25, if the user principal and the service principal do not use the same key type, the process continues as described. The Kerberos server acts as the only trusted party, and the client or the service does not accept a message encrypted by the client or the service key. Both the client application and the service share a secret key only with the server.
Overview Introduction to LDAP Introduction to LDAP The Lightweight Directory Access Protocol (LDAP) is a lightweight protocol for accessing directory services. LDAP defines a message protocol used by directory clients and directory servers. It is a fast-growing technology for accessing common directory information. LDAP has been embraced and implemented in most network-oriented middleware.
Overview Introduction to LDAP Integrating Kerberos Server v3.12 with LDAP You can configure Kerberos server v3.12 with LDAP as the backend database. By integrating the Kerberos principals with the corresponding users in the LDAP directory, you store data for mechanisms, such as UNIX and Kerberos in a common repository. Also, you can secure user credentials by mandating users to use LDAP credentials.
Overview Introduction to LDAP How is the Kerberos Principal Integrated in to the LDAP Directory? A directory contains a collection of objects organized in a tree structure. You can arrange entries within the DIT based on their Distinguished Names (DNs). A DN is composed of a sequence of RDNs separated by commas, such as cn=alex,ou=R&D,o=bambi. Figure 1-2, displays how a Kerberos principal is integrated in to the LDAP directory.
Overview Introduction to LDAP 32 Chapter 1
2 Installing the Kerberos Server v3.12 This chapter describes how to install the Kerberos server v3.12 on an HP-UX 11i v3 operating system.
Installing the Kerberos Server v3.
Installing the Kerberos Server v3.12 Prerequisites Prerequisites Before you install the server, ensure that: Chapter 2 • You have installed HP-UX 11i v2 or HP-UX 11i v3 operating system on your system. To check the version of the HP-UX operating system, run the uname -r command at the HP-UX prompt. • The Kerberos server is installed on a system that is physically secure and has restricted access to it.
Installing the Kerberos Server v3.12 System Requirements System Requirements This section describes the hardware and software requirements for the Kerberos server software for HP-UX server systems. Hardware Requirements The hardware requirement for installing the Kerberos server is 12 MB of free disk space. You can install the Kerberos server v3.12 software when your system is up, and you need not reboot the system after installing the software. HP does not recommend the single-user state.
Installing the Kerberos Server v3.12 Installing the Server Installing the Server To install the Kerberos server, complete the following steps: Step 1. Insert the software media (tape or disk) in the appropriate drive. Step 2. Type the swinstall command at the HP-UX prompt. For more information on the swinstall command, type man 1M swinstall at the HP-UX prompt. Step 3. In the Specify Source window, select the appropriate path of the depot and click OK. Step 4.
Installing the Kerberos Server v3.
3 Migrating to a Newer Version of the Kerberos Server This chapter describes how to migrate from the Kerberos server v1.0 to v3.0, from the Kerberos server v2.0 to v3.
Migrating to a Newer Version of the Kerberos Server v3.0 to v3.12. The Kerberos database formats of v2.0 and v3.0 are compatible with each other, but the database formats of Kerberos server v1.0 and v3.0 are not compatible with each other. Therefore, migrate the database format from v1.0 to v3.0. The Kerberos server v1.0 database contains information related both to principal and policy. However, the Kerberos server v3.
Migrating to a Newer Version of the Kerberos Server • Chapter 3 “Migrating from Kerberos Server Version 3.0 to Version 3.
Migrating to a Newer Version of the Kerberos Server Migrating from Kerberos Server Version 1.0 to 3.0 Migrating from Kerberos Server Version 1.0 to 3.0 If you want to use the Kerberos server with C-tree as the backend database, migrate your existing Kerberos server to Kerberos server v3.0. In the Kerberos server v1.0, you can create a policy with any name and attribute value. Any principal can subscribe to any of the policies in the database. In the Kerberos server v2.
Migrating to a Newer Version of the Kerberos Server Migrating from Kerberos Server Version 1.0 to 3.0 # kdb5_util dump /opt/krb5/dumpfilev1.0 Step 2. Copy the dump file to the new system where you are installing the Kerberos server v3.0. Step 3. Install the v3.0 Kerberos daemons on the new system. Step 4. Migrate the v1.0 dump file to the v3.0 dump file. To generate the v3.0 dump file, run the kdb_migrate tool on the system where Kerberos server v3.0 is installed: # kdb_migrate -i /opt/krb5/dumpfilev1.
Migrating to a Newer Version of the Kerberos Server Migrating from Kerberos Server Version 1.0 to 3.0 You can configure Kerberos server manually or by using the krbsetup tool. Ensure that the following values are the same in both versions of the Kerberos server: • Realm name • Master key name The master key password must be identical to the one that was used in v1.0. This is applicable if you have not opted to change the password, as mentioned in step 3.
Migrating to a Newer Version of the Kerberos Server Migrating from Kerberos Server Version 1.0 to 3.0 The policy applicable to the principal that is migrated from v1.0 to v3.0 is based on the instance name of the principals. To modify the policy, edit the principal to change the policy name field to the new policy. • You cannot migrate the admin_acl_file. You need to add the appropriate ACLs to the /opt/krb5/admin_acl_file using the old admin_acl_file.
Migrating to a Newer Version of the Kerberos Server Migrating from Kerberos Server Version 2.0 to Version 3.0 Migrating from Kerberos Server Version 2.0 to Version 3.0 If you want to use the Kerberos server with C-tree as the backend database, migrate your existing Kerberos server to Kerberos server v3.0. In the Kerberos server v2.x, the password policy was based on the instance name to which the principal belongs. Starting with the Kerberos server v3.
Migrating to a Newer Version of the Kerberos Server Migrating from Kerberos Server Version 2.0 to Version 3.0 # kdb_dump -f /opt/krb5/dumpfilev2.0 Step 2. Copy the dump file to the system on which you are installing the v3.0 Kerberos server Step 3. Install the v3.0 Kerberos daemons on the new system. Step 4. Configure Kerberos Server v3.0.
Migrating to a Newer Version of the Kerberos Server Migrating from Kerberos Server Version 3.0 to Version 3.12 Migrating from Kerberos Server Version 3.0 to Version 3.12 If you want to use the Kerberos server with LDAP as the backend database, migrate your existing Kerberos server to Kerberos server v3.0. Use the krb_2_ldap utility to migrate information of the previous version of the Kerberos server to the LDAP database.
4 Interoperability with Windows 2000 When you configure interoperability between the Kerberos server and the Windows 2000 operating system, you must set certain configuration Chapter 4 49
Interoperability with Windows 2000 parameters. 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 reading this chapter, ensure that you are familiar with the concepts in Chapter 10, “Managing Multiple Realms,” on page 275.
Interoperability with Windows 2000 Understanding the Terminology Understanding the Terminology Both the 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 through a trusted third party called a Key Distribution Center (KDC). HP provides a KDC on the security server, and Windows 2000 provides a KDC on the domain controller.
Interoperability with Windows 2000 Understanding the Terminology systems and the Microsoft implementation uses a DNS lookup to resolve host names. But both implementations are written to RFC 1510 (The Kerberos Network Authentication Service (V5)) and RFC 1964 (The Kerberos Version 5 GSS-API Mechanism), and hence they can interoperate. Table 4-1 summarizes analogous terminology in the Kerberos server and Windows 2000 Kerberos implementations.
Interoperability with Windows 2000 Kerberos Server and Windows 2000 Interoperability Kerberos Server and Windows 2000 Interoperability Following are the possible interrealm interoperability scenarios between the Kerberos server software and Windows 2000, each with its own configuration requirements. Scenario 1 A Windows 2000 user needs access to services in a Kerberos server realm. Here, the Kerberos server realm is the target realm and the Windows 2000 domain is the source realm.
Interoperability with Windows 2000 Establishing Trust Between Kerberos Server and Windows 2000 Establishing Trust Between Kerberos Server and Windows 2000 To establish trust between Kerberos server KRB.REALM and Windows 2000 W2K.DOMAIN, complete the following steps: Step 1. Add interrealm service principals to the Kerberos server realm. For more information, see “HP Kerberos Administrator” on page 132. • If the realm is the source realm, the name of the principal is krbtgt/W2K.DOMAIN@KRB.REALM.
Interoperability with Windows 2000 Establishing Trust Between Kerberos Server and Windows 2000 NOTE The fqdn qualifier specifies the fully qualified domain name of the Kerberos KDC. Step 4. Reboot the Windows 2000 domain controller. You need not reboot the Kerberos server or client.
Interoperability with Windows 2000 Single Realm (Domain) Authentication Single Realm (Domain) Authentication Single realm interoperability scenarios involve one or more client systems in a given realm or domain that authenticate to a single KDC. Following are the interoperability scenarios that do not require interrealm 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 Interrealm (Interdomain) Authentication Interrealm (Interdomain) Authentication If two distinct realms share common keys, the realms 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 calls such an access interrealm authentication, and Microsoft calls 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 only one master copy of the database is propagated to all secondary security servers.
Interoperability with Windows 2000 Special Considerations for Interoperability Chapter 4 59
Interoperability with Windows 2000 Special Considerations for Interoperability 60 Chapter 4
5 Configuring the Kerberos Server With C-Tree Backend This chapter describes the configuration files and procedures used to configure the Kerberos Server with C-tree backend.
Configuring the Kerberos Server With C-Tree Backend Configuration Files for the Kerberos Server Configuration Files for the Kerberos Server You must install all the critical Kerberos server files on the system before you start configuring the Kerberos Server. You must configure these files on the primary security server and copy these files to all the secondary security servers on the network. Table 5-1 briefly describes the server files that you need to configure.
Configuring the Kerberos Server With C-Tree Backend Configuration Files for the Kerberos Server The krb.conf File The krb.conf configuration file contains information about the default realm of the host, the administration server, and security servers for known realms. HP recommends that you copy the krb.conf.sample file from the /opt/krb5/examples directory to the /opt/krb5 directory.
Configuring the Kerberos Server With C-Tree Backend Configuration Files for the Kerberos Server NOTE Realm names are case sensitive; you must type the realm name correctly if your site does not follow the uppercase convention. The subsequent lines require fields that identify the security server host names. Each field in the line must be separated by a space or a tab. The second field indicates the Fully Qualified Domain Name (FQDN) of the host security server for that realm.
Configuring the Kerberos Server With C-Tree Backend Configuration Files for the Kerberos Server The krb.realms file must contain sufficient entries to define the realm used by every service a client computer must access. You can create a krb.realms file that contains all the required entries for your enterprise. If you support inter-realm authentication, the krb.realms file must contain the required entries to locate the foreign realms. NOTE The krb.
Configuring the Kerberos Server With C-Tree Backend Configuration Files for the Kerberos Server To create comments, use the hash sign (#). Any characters after a # sign are ignored. Blank lines and any leading or trailing white spaces in a line are also ignored. To identify multiple hosts that belong to the same realm in a single entry, use one of the wildcard characters described in Table 5-2. Table 5-2 Wildcard Characters Wildcard Character .
Configuring the Kerberos Server With C-Tree Backend Autoconfiguring the Kerberos Server Autoconfiguring the Kerberos Server An automated tool named krbsetup is provided to autoconfigure your Kerberos server. Use this tool to: • Configure the Kerberos Server with either LDAP or C-Tree as the backend database. • Unconfigure the server. • Start the kdcd and the kadmind daemons. You must start the kpropd daemon manually if you have opted for C-Tree as the backend database.
Configuring the Kerberos Server With C-Tree Backend Autoconfiguring the Kerberos Server • Specify the encryption type. • Specify a different location for the log messages if you do not want to store the log messages in the default syslog file. • Specify the security mechanism for your LDAP-based Kerberos server. • Specify the Directory server host name of the LDAP-based Kerberos server. • Specify the TCP port number of the LDAP-based Kerberos server.
Configuring the Kerberos Server With C-Tree Backend Autoconfiguring the Kerberos Server The following output is displayed: 1) Configure the Server with LDAP backend 2) Configure the Server with C-Tree backend 0) Return to Previous Menu Selection: [0] • To configure your Kerberos Server with C-Tree, select option 1. See “Configuring the Kerberos Server with C-Tree” on page 69 to continue configuring your Kerberos Server with C-Tree. • To configure your Kerberos Server with LDAP, select option 2.
Configuring the Kerberos Server With C-Tree Backend Autoconfiguring the Kerberos Server 5) Exit 6) Help Step 3. To configure the Kerberos Server, select option 1. The following output is displayed: 1) Configure the Server with LDAP backend 2) Configure the Server with C-Tree backend 0) Return to Previous Menu Selection: [0] Step 4. To configure the Kerberos Server with C-Tree backend, select option 2. Step 5.
Configuring the Kerberos Server With C-Tree Backend Autoconfiguring the Kerberos Server Step 11. Enter the location where you want to store log messages. By default, log messages are stored in the syslog file. To change the default location, enter y and specify the absolute directory name for the log messages. Step 12. Enter the database master password. Step 13. Re-enter the database master password to verify the password. Step 14.
Configuring the Kerberos Server With C-Tree Backend Autoconfiguring the Kerberos Server 72 Chapter 5
6 Configuring the Kerberos Server with LDAP This chapter describes the configuration files and procedures used to configure the Kerberos Server with LDAP backend.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration Configuration Files for LDAP Integration You must configure the LDAP configuration files listed in Table 6-1, before setting up your Kerberos server. This chapter contains detailed descriptions of these configuration files. The krbsetup autoconfiguration tool generates these files, based on your input. Alternatively, you can manually edit the sample configuration files available in the /opt/krb5/examples directory.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration This file is generated automatically based on the input provided by you while autoconfiguring the Kerberos server. Alternatively, a sample file is available in the /opt/krb5/examples directory. You can copy this file to the /opt/krb5 directory, and manually edit it. HP recommends that you use the autoconfiguration tool to generate this file.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration same; else the Kerberos server will not connect to the LDAP server. Table 6-2 provides a detailed description of the various parameters in the krb5_ldap.conf file. Table 6-2 krb5_ldap.conf File Format Parameter ldap_enabled Description This line indicates whether you have enabled LDAP. 1 indicates that you have enabled LDAP and 0 indicates that you have not enabled LDAP as the backend database.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration Table 6-2 krb5_ldap.conf File Format (Continued) Parameter Description security_mech This line specifies the security mechanism used to connect to the LDAP server. Currently, the supported mechanisms are Secure Sockets Layer (SSL) and PASSWORD. default_object_template This line specifies the structural class, which is added by default.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration The krb5_schema.conf File A schema is a collection of object and attribute definitions that defines the structure of the entries in a database. The krb5_schema.conf file is the kerberos schema file that contains the object and attribute definitions of the kerberos principal entries. LDAP objects are standardized in order to provide interoperability with a variety of directory services servers. The krb5_schema.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration DESC ’Kerberos principal identity for a user in the form @’ EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) attributetype: ( hpKrbMaxTicketAge-oid NAME ’hpKrbMaxTicketAge’ DESC ’Value defining the maximum lifetime of a user ticket’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetypes: ( hpKrbLastLogon-oid NAME ’hpKrbLastLogon’ DESC ’A value used to compute date and time of last successfullogon’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetypes: ( hpKrbBadPasswordTime-oid NAME ’hpKrbBadPasswordTime’ DESC ’Value used to compute date and time of last unsuccessfu logon attempt’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration SINGLE-VALUE ) attributetypes: ( hpKrbAttributes-oid NAME ’hpKrbAttributes’ DESC ’A value containing one or more flags’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) attributetypes: ( hpKrbPolicyName-oid NAME ’hpKrbPolicyName’ DESC ’The Kerberos password policy to which this principal subscribes to’ EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration attributetypes: ( hpkrbAuthzData-oid NAME ’hpkrbAuthzData’ DESC ’Other Authorization Data.’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) add: objectClasses objectClasses: ( hpKrbPrincipal-oid NAME ’hpKrbPrincipal’ DESC ’An auxiliary class for use in configuring an entry to represent a Kerberos principal.
Configuring the Kerberos Server with LDAP Configuration Files for LDAP Integration The krb5_map.
Configuring the Kerberos Server with LDAP Planning Your LDAP Configuration Planning Your LDAP Configuration The following sections of this chapter describe how to plan and configure your Kerberos Server to work with the Directory server. Before You Begin Remember the following points when you plan your LDAP setup: 84 • Use the Configuration Worksheet (see Appendix A, “Configuration Worksheet,” on page 311) to record your decisions and other information that you need later for configuration.
Configuring the Kerberos Server with LDAP Setting up Your LDAP Configuration Setting up Your LDAP Configuration Plan how to set up and verify your LDAP directory and your Kerberos server environment, before you put them into production. Consider the following questions and record your decisions and other information that you will need later in the Configuration Worksheet found in Appendix A, “Configuration Worksheet,” on page 311.
Configuring the Kerberos Server with LDAP Setting up Your LDAP Configuration you can access the information in the directory. Hence, you need to choose an authentication method. Currently, the supported mechanisms are Password, and SSL. The SSL protocol was devised to provide both authentication and data security. SSL encapsulates the TCP/IP socket so that every TCP/IP application can use it to secure its communication.
Configuring the Kerberos Server with LDAP Setting up Your LDAP Configuration • What is the name of your default principal subtree DN? Each RDN in a DN corresponds to a branch in the DIT leading from the root of the DIT to the directory entry. The search base node subtree designateS all the containers for the various information types under the base DN. For example, ou=accounts, ou=people, o=bambi.
Configuring the Kerberos Server with LDAP Setting up Your LDAP Configuration This line specifies the mandatory attributes of the default object class.The object class attribute determines the attributes the entry must have and can have. When the Kerberos server creates a default object it uses the first attribute specified in this field, as the naming attribute. For example, uid. cn, homedirectory, gidnumber, uidnumber.
Configuring the Kerberos Server with LDAP Autoconfiguring the Kerberos Server With LDAP Integration Autoconfiguring the Kerberos Server With LDAP Integration An automated tool named krbsetup is provided to autoconfigure your Kerberos server. For more information on the krbsetup tool, see “Autoconfiguring the Kerberos Server” on page 67. Configuring the Kerberos Server with LDAP Complete the following procedure to autoconfigure your Kerberos server with LDAP: Step 1.
Configuring the Kerberos Server with LDAP Autoconfiguring the Kerberos Server With LDAP Integration NOTE Ensure that you have a dump of the existing Kerberos database, before you configure the Kerberos server with LDAP. “Migrating to a Newer Version of the Kerberos Server” on page 39, for more information. Step 6. Select one of the following options to configure the security mechanism of your LDAP-based Kerberos server: 1. SSL 2. Password Step 7. Enter the host name of the directory server.
Configuring the Kerberos Server with LDAP Autoconfiguring the Kerberos Server With LDAP Integration Step 13. To extend the existing schema in the directory, press y. Press n if you do not want to extend the schema. NOTE You must have administrative privileges to extend the schema. Contact your LDAP administrator if you do not have these privileges. If you have pressed y, that is, opted to extend the schema, you are prompted for the following input: a. Enter the DN of the Admin user.
Configuring the Kerberos Server with LDAP Autoconfiguring the Kerberos Server With LDAP Integration 2. To configure your Kerberos server as a secondary security server, select option 2. Before you log on to the Remote Administrator, stop the daemons that are already running on the secondary security server. Step 18. Specify the encryption type. If you do not specify a value, the default value, DES-MD5, is selected. Step 19. To stash the principal database key file on your local disk, press y at the prompt.
Configuring the Kerberos Server with LDAP Manually Configuring the Kerberos Server with LDAP Manually Configuring the Kerberos Server with LDAP This section describes how to manually configure your Kerberos server with LDAP. HP recommends that you use the autoconfiguration tool to set up your basic Kerberos security server with LDAP. For more information on autoconfiguration, see “Autoconfiguring the Kerberos Server With LDAP Integration” on page 89.
Configuring the Kerberos Server with LDAP Manually Configuring the Kerberos Server with LDAP • Never delete any element of your Kerberos schema as this affects the compatibility of your schema to other LDAP services (servers and clients). • Never change the Kerberos schema of your directory by modifying the existing elements as this also affects the compatibility of your schema to other LDAP services. • Never map an existing attribute name to a kerberos attribute name.
7 Configuring the Primary and Secondary Security Server This chapter describes the procedure to configure the primary and secondary security server.
Configuring the Primary and Secondary Security Server Configuring the Primary Security Server Configuring the Primary Security Server The following sections describe the initial configuration tasks you need to perform to get your primary and secondary security server up and running. The primary security server requires the following basic configuration tasks: 1. Execute the krb5_encrypt command to generate the master key.
Configuring the Primary and Secondary Security Server Configuring the Primary Security Server If you are using Kerberos server v2.0 or v3.0, and want to migrate the principal database to Kerberos server v3.12, see Chapter 3, “Migrating to a Newer Version of the Kerberos Server,” on page 39. Add an Administrative Principal Use the HP Kerberos Administrator (kadminl_ui) instead of the command-line administrator (kadminl) to add the principal account.
Configuring the Primary and Secondary Security Server Configuring the Primary Security Server Step 4. Use the Edit>Edit Administrative Permissions menu to assign all administrative permissions to the principal. Step 5. On the Attributes tab, clear the Require Password Change checkbox to disable the password change requirement. You can also disable the password change requirement by setting the NoReqChangePwd setting in the principal’s password policy file to 1.
Configuring the Primary and Secondary Security Server Configuring the Primary Security Server The host/ principal is not automatically added to the principal database during security server software installation; you must manually add the host/ principal using the kadminl_ui or kadminl command. NOTE You must log on as a root user, on the primary security server, to add the host/ principal to the database.
Configuring the Primary and Secondary Security Server Configuring the Primary Security Server Alternatively, you can use the following command to start the Kerberos daemons kdcd and kadmind: /sbin/init.d/krbsrv start To start the kpropd daemon, use the following command: /opt/krb5/sbin/krpopd NOTE Propagation is disabled if you select LDAP as your backend database. Check with your LDAP administrator, for more information about propagation of information on the LDAP Server.
Configuring the Primary and Secondary Security Server Security Policies Security Policies The following files are directly related to the security of the network in your organization: • password policy • admin_acl_file Password Policy File The password policy 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 security server and on all the secondary security servers.
Configuring the Primary and Secondary Security Server Starting the Security Server Starting the Security Server After creating the Kerberos database and setting up the administrative principals, you can 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 Then, type the following: /sbin/init.
Configuring the Primary and Secondary Security Server Configuring the Secondary Security Servers with C-Tree Configuring the Secondary Security Servers with C-Tree You can now configure 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 security servers, you must perform each of the steps on the primary security server as well as on the secondary security server.
Configuring the Primary and Secondary Security Server Configuring the Secondary Security Servers with C-Tree Creating a host/ Principal and Extracting the Key To allow principal database propagation, each secondary security server must contain a host/ principal. You must also extract the key for the host/ principal to that service key table file of the server.
Configuring the Primary and Secondary Security Server Configuring the Secondary Security Servers with LDAP Configuring the Secondary Security Servers with LDAP You can now configure 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 security servers, you must perform each of the steps on the primary security server as well as on the secondary security server.
Configuring the Primary and Secondary Security Server Configuring the Secondary Security Servers with LDAP key type and master password that was specified when the database was created.If you run the kdb_create utility with the -s option, a stash file is created automatically. NOTE 106 The kdb_stash utility requires super user privileges to execute.
Configuring the Primary and Secondary Security Server Using Indexes to Improve Database Performance Using Indexes to Improve Database Performance Most LDAP servers use indexes to improve search performance. Indexes are files stored in your directory databases. Separate index files are maintained for each database in your directory. Each file is named according to the attribute it indexes. The index file for a particular attribute can contain multiple types of indexes.
Configuring the Primary and Secondary Security Server Using Indexes to Improve Database Performance 108 Chapter 7
8 Administering the Kerberos Server This chapter explains how to administer and maintain the Kerberos database and how to manage principals using the HP Kerberos Chapter 8 109
Administering the Kerberos Server Administrator, a graphical user interface, or the command-line administrator.
Administering the Kerberos Server Administering the Kerberos Database Administering the Kerberos Database After you have installed and configured the Kerberos server v3.12, the Kerberos database contains the default Kerberos principals, their keys, and other administrative information about each of these principals for your realm. For more information on installing your Kerberos server, see Chapter 2, “Installing the Kerberos Server v3.12,” on page 33.
Administering the Kerberos Server The kadmind Command The kadmind Command The kadmind command starts the administrative server. This administrative server runs on the Kerberos server that stores the Kerberos principal database. The kadmind command accepts password change requests and remote requests to administer the information in the Kerberos principal database. Table 8-1 describes the configuration files that you must set for kadmind to work properly.
Administering the Kerberos Server The admin_acl_file File The admin_acl_file File The /opt/krb5/admin_acl_file file located only on the primary security server, lists authorized principals with their respective administrative permissions. It also lists principals that you cannot modify without explicit privileges. NOTE Protect admin_acl_file with appropriate read-write privileges with access only to the root user The kadmind command checks the permissions of the principal in admin_acl_file.
Administering the Kerberos Server The admin_acl_file File Assigning Administrative Permissions Administrative principals may have varying levels of trust assigned to them, depending on the policies of your organization. Table 8-2 lists the possible administrative permission settings and the letter designator used in admin_acl_file to indicate the permissions assigned to the principal account. Table 8-2 Administrative Permission Settings Administrator Field Name ACL File Character Add principals.
Administering the Kerberos Server The admin_acl_file File Permissions designated with a lowercase letter apply only to those realms to which the administrative principal belongs. Permissions designated with an uppercase letter apply to all realms. [permissions] is an optional string containing one or more options listed in Table 8-2. The restricted administrator setting is a modifier that you must use in conjunction with permissions.
Administering the Kerberos Server The admin_acl_file File To grant the principal rabbit@FINANCE.BAMBI.COM the permission to add, list, and inquire about any principal in the database, add the following entry to admin_acl_file: rabbit@FINANCE.BAMBI.COM ali Adding Entries to admin_acl_file You can add any principal name to admin_acl_file with or without administrative permissions.
Administering the Kerberos Server The admin_acl_file File Creating Administrative Accounts You can set administrative permissions in admin_acl_file using one of the following methods: • Using the HP Kerberos Administrator to set administrative permissions. When you change the administrative permissions of the principal, admin_acl_file is automatically updated. • Editing admin_acl_file directly. To edit this file, you need to have the required system file administration rights.
Administering the Kerberos Server The admin_acl_file File IRDid is equivalent to the IRD permissions because the uppercase permissions (excluding the r and R modifiers) apply to all realms. NOTE In either case, administrative principals can delete any principal from their own realm, but they have restricted delete privileges in realms other than their own.
Administering the Kerberos Server Password Policy File Password Policy File The password policy file controls password rules, such as password length, number of character types, and the lifetime of a password. The password.policy file located on each of the primary and secondary security servers in the /opt/krb5 directory. Editing the Default File To edit the password policy file and configure it to match the requirements of your organization, use a text editor on the primary security server.
Administering the Kerberos Server Password Policy File Table 8-3 Default Password Policy Settings for the Base Group Password Policy Setting Default Value *.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 restart kdcd on both the secondary and primary secondary security servers.
Administering the Kerberos Server Principals Principals A principal is a specific entity to which you can assign a set of credentials. Principals are users and network services that are included in your security network. The general syntax for a principal is as follows: identifier/instance@REALM where: identifier Specifies the name of the network service or a user. This parameter is mandatory and you must specify the identifier. /instance Specifies the group used to further identify the name.
Administering the Kerberos Server Principals NOTE • Is case sensitive. • Cannot be longer than 767 characters. • Must be uniquely defined in the first 255 characters. • Cannot contain a space, tab, pound symbol (#), backward slash (\) or colon (:). • Does not subscribe to a NULL policy. If you subscribe to a policy that does not exist in the password.policy file, the default policy * is applied for the principal. You can use the slash (/) character in a principal name to delineate an instance.
Administering the Kerberos Server Principals Adding User Principals The Kerberos server enables you to add user principals to the principal database. The only limit on the number of principals in the database is the disk space available on the primary security server and on each of the secondary security servers. When adding a user principal to the database, assign the principal identifier, instances (if used), and the realm name. You must also designate a temporary password for the principal.
Administering the Kerberos Server 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 lowercase. For example, if the system name is IT.BAMBI.COM, the principal name must use the instance it.bambi.com.
Administering the Kerberos Server Principals the database secret key. All records in the principal database are encrypted using this key. The key for this principal is stored on each Kerberos server in the .k5.realm file. IMPORTANT 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 the realm. This principal is required in each realm.
Administering the Kerberos Server Principals kadmin/REALM@REALM: The Kerberos administrative graphical user interface and command-line interface utilities use the kadmin/REALM@REALM principal name. This principal is required in each realm. It automatically adds the principal name 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. IMPORTANT Do not remove or modify this principal entry.
Administering the Kerberos Server Principals You must enter the fqdn in lowercase letters, and the fqdn instance must be the fully qualified domain name of the host system for the server or service. These principals are not automatically added to the principal database when you install the Kerberos servers or application services. Removing User Principals You may need to delete user principals from the database.
Administering the Kerberos Server Principals Protecting a Secret Key A user principal must provide its password during authentication to create the secret key of the user principal. For best security, all users must periodically change their passwords. This version of Kerberos contains the following methods to enforce user principals to change their password: • You can enable the Password Change Required attribute to enforce the users to change their passwords during next logon.
Administering the Kerberos Server Principals Deleting a service principal using one of the Kerberos administrative utilities removes the principal name, attributes, and properties from the database. For a service principal, you need to perform an additional step of removing its secret key, which is stored in the service key table file on the host of the service. This key is not deleted when the service principal is removed from the database.
Administering the Kerberos Server The kadmin and kadminl Utilities The kadmin and kadminl Utilities The kadmin and kadminl Kerberos command-line administrative 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 in the database. You can use these utilities to maintain the Kerberos principals and service key tables (v5srvtab).
Administering the Kerberos Server The kadmin and kadminl Utilities Administration Utilities Table 8-4 describes the administrative utilities that you can use to administer the Kerberos database. Table 8-4 Administration Utilities Name NOTE Chapter 8 Description kadminl_ui The local graphical interface that runs on the primary security server. kadminl The local command-line administrator that runs on the primary security server.
Administering the Kerberos Server HP Kerberos Administrator HP Kerberos Administrator HP Kerberos Administrator is a graphical user interface that you can use to administer the principal database. You can use the HP Kerberos Administrator to perform the following functions: • Creating, modifying, and deleting principals. • Altering a principal account key type setting. • Assigning administrative permissions. • Modifying the default group principals.
Administering the Kerberos Server HP Kerberos Administrator the * permissions in admin_acl_file. The account must have at least inquire privileges. For more information, see “The admin_acl_file File” on page 113. Both the local and remote administrators are discussed in detail in this chapter. Standard Functionality of the Administrator This section contains the standard descriptions applicable to all windows in the HP Kerberos Administrator window.
Administering the Kerberos Server Local Administrator – kadminl_ui Local Administrator – kadminl_ui The local administrator, kadminl_ui, is the GUI-based database administrator that runs on the primary security server. It allows principals with administrative privileges to administer and maintain the principal database on an ongoing basis. You must include all the users, clients, or services authenticated by the Kerberos server as principals in the principal database.
Administering the Kerberos Server Local Administrator – kadminl_ui This chapter contains a detailed description of the Principals tab and the Realms tab.
Administering the Kerberos Server Principals Tab Principals Tab You can use the Principals tab (Figure 8-1) in the HP Kerberos Administrator window to manage principal entries in your database by adding, editing, or deleting principals.
Administering the Kerberos Server Principals Tab Table 8-6 describes the components of the Principals tab. Figure 8-1 Principals Tab Table 8-6 Principals Tab Components Component Name Realm Chapter 8 Description Select the realm where the principal that you want to add, change, or delete resides.
Administering the Kerberos Server Principals Tab Table 8-6 Principals Tab Components (Continued) Component Name List All Description Click this button to list all the principals associated with the realm. NOTE: If you have selected LDAP as the backend database, then information about all realms under the same base DN is displayed when you click this button. 138 Search String Enter characters for locating the principal that you want to edit or delete.
Administering the Kerberos Server General Tab (Principal Information Window) General Tab (Principal Information Window) You can use the Principal Information window to add principals or to modify existing principals and ticket information. To add a new principal, select the realm in the HP Kerberos Administrator window and click New. The Principal Information window displays as shown in Figure 8-2.
Administering the Kerberos Server General Tab (Principal Information Window) Table 8-7 Principal Information Window Components (Continued) Field Name Description LDAP DN Displays the LDAP DN. General Tab You can use the General tab on the Principal Information window to specify the ticket information, the password policy file, and values for Last Modified and Modified By, for a new or existing principal.
Administering the Kerberos Server General Tab (Principal Information Window) Table 8-8 General Tab Components (Continued) Field Name Principal Expiration Description Displays the principal expiration time, which indicates when the current logon privileges of the principal expire. Enter one of the following options in the Principal Expiration box: • A date and time in the format HH:MM MM/DD/YYY. • The keyword Never, which indicates that the principal does note expire.
Administering the Kerberos Server General Tab (Principal Information Window) Table 8-8 General Tab Components (Continued) Field Name Password Policy Description Specifies the password policy name in this field. If you do not specify the password policy name, the default policy is applied. NOTE: Do not change the password policy name for reserved service principals. 142 Last Modified Specifies the last modified date for the principal.
Administering the Kerberos Server Adding Principals to the Database Adding Principals to the Database When you add a principal, you must specify the following information: • Principal and ticket information, located in the General tab. • Password and password expiration information, located in the Password tab. • Other principal attributes, located in the Attributes Tab The Group Settings option controls the default values in all the tabs in the Principal Information window.
Administering the Kerberos Server Adding Principals to the Database Figure 8-3 Change Password Window Step 5. Enter the new password in the Change Password window and click OK. Step 6. In the Password tab, enter the Password Information and the Key and Salt Types. You cannot use the Change Password button in the Password tab because the Change Password button is disabled when you create a new principal. For more information, see “Changing Password Information” on page 158. Step 7.
Administering the Kerberos Server Adding Principals to the Database Adding Multiple Principals with Similar Settings To simultaneously add multiple principals with the same setting, complete the following steps: Step 1. In the HP Kerberos Administrator window, select the Realm in which you want to add multiple principals. Step 2. Click New to display the Principal Information window as shown in Figure 8-2. Step 3. Enter the first principal name in the Principal Information window. Step 4.
Administering the Kerberos Server Creating an Administrative Principal Creating an Administrative Principal You can use the HP Kerberos Administrator window to create an administrative principal. When you create a principal and assign the administrative permissions to it, the principal is stored in admin_acl_file located on the primary security server. For more information on admin_acl_file, see “The admin_acl_file File” on page 113.
Administering the Kerberos Server Creating an Administrative Principal Step 6. Enter the password information and click OK in the Change Password window. Do not select the Generate Random Key option. Step 7. In the Attributes tab, select the attributes for the administrative principal. Select the Require Preauthentication attribute if the administrative principal requires a hardware authentication device. Step 8. If necessary, click Apply. Step 9.
Administering the Kerberos Server Creating an Administrative Principal Step 11. Click OK to save all the values to the database and to close the Principal Information window, or click Cancel to close the Principal Information window without saving the values to the database.
Administering the Kerberos Server Searching for a Principal Searching for a Principal Following are the methods to search for a principal: • Click List All in the Principals tab to display a list of principals in the current realm in the List of Principals list box, which displays up to 1,000 principals. • Click Search to display a list of principals in the current realm that match the search criteria in the Search String text box. The List of Principals dialog box displays up to 1,000 principals.
Administering the Kerberos Server Searching for a Principal Table 8-9 Search Criteria (Continued) Character [...] Description Represents any one character from the set except / (slash). For example, [abc]* searches for all principal names starting with a, b, or c. The following characters have a special meaning with the [...] construct: ! Represents an exclusion when used immediately after [ . For example: [!abc]* searches for all principal names that start with any character other than a, b, or c.
Administering the Kerberos Server Deleting a Principal Deleting a Principal When you delete a principal using one of the Kerberos administrative utilities, all references to the principal are automatically removed from both the principal database and admin_acl_file. To delete a user principal, complete the following steps: Step 1. In the Principals tab, select the Realm in which you want to delete a principal. Step 2. Click List All or enter the Search String to find the principal. Step 3.
Administering the Kerberos Server Loading Default Values for a Principal Loading Default Values for a Principal When you add or edit a principal in the Principal Information window, you can quickly restore any changed values to the default values that are specified in the default group. When you reload the default values, all fields in the Principal Information window are updated with the default values.
Administering the Kerberos Server Restoring Previously Saved Values for a Principal Restoring Previously Saved Values for a Principal You can restore any value for a principal that you have changed but not yet saved to the values that were previously saved for that principal. To retain the previously saved values for a principal while you are modifying the values for that principal in the Principal Information window, choose Edit>Restore Values in the Principal Information window.
Administering the Kerberos Server Changing Ticket Information Changing Ticket Information You can change the ticket information used for a principal, including the principal expiration date, ticket lifetime, and ticket renewal time. To change the ticket information, complete the following steps: Step 1. In the Principals tab, select the Realm where the principal resides. Step 2. Click List All or Search to find the principal whose ticket information you want to change.
Administering the Kerberos Server Rules for Setting Maximum Ticket Lifetime Rules for Setting Maximum Ticket Lifetime Maximum ticket lifetime indicates the maximum lifetime for which a ticket can be issued to the principal. You can specify the maximum ticket lifetime value in the General>Maximum Ticket Lifetime text box. The format for the ticket lifetime is as follows: [Nw] [Nd] [Nh] [Nm] where: N Indicates an integer.
Administering the Kerberos Server Rules for Setting Maximum Renew Time Rules for Setting Maximum Renew Time Maximum renew time indicates the maximum amount of time for which a ticket can be renewed. You can specify the maximum renew time value in the Principal Information>General>Maximum Renew Time text box. The format for the ticket lifetime is as follows: [Nw] [Nd] [Nh] [Nm] where: N Indicates an integer number. w, d, h, m Identifies the unit of time: weeks, days, hours, or minutes, respectively.
Administering the Kerberos Server Rules for Setting Maximum Renew Time You have entered an invalid time Chapter 8 157
Administering the Kerberos Server Changing Password Information Changing Password Information You can change the following password information used by a principal: • Password expiration date Indicates when the password of the current principal is due to expire. Check the Password Expiration Date box to activate password expiration for the current principal. If you do not enable this option, the current password of the principal will never expire.
Administering the Kerberos Server Changing Password Information IMPORTANT If you change the key or salt type, you must change the password of the principal. You must inform the principal of the required temporary password. The principal must change the password during next logon. You can use the Principal Information>Edit menu to quickly reload default values or to restore previously saved values anytime while editing a principal.
Administering the Kerberos Server Password Tab (Principal Information Window) Password Tab (Principal Information Window) You can use the Password tab (Figure 8-5) on the Principal Information window to specify the password parameters for the principal. Figure 8-5 Password Tab Table 8-10 describes the components of the Password tab. Table 8-10 Password Tab Components Component Name 160 Description Principal Displays the name of the principal that you are editing.
Administering the Kerberos Server Password Tab (Principal Information Window) Table 8-10 Password Tab Components (Continued) Component Name Password Expiration/Date Description Indicates when the current principal password expires. Select Password Expiration/Date to activate password expiration for the current principal. If you do not enable this function, the password of the current principal never expires.
Administering the Kerberos Server Password Tab (Principal Information Window) Table 8-10 Password Tab Components (Continued) Component Name Description Failed Auth Count Specifies the number of failed authentication attempts since the last successful authentication by the principal. Every failed SignOn request by the client increments the Failed Auth Count value by 1.
Administering the Kerberos Server Password Tab (Principal Information Window) Generate Random Key only for service principals. If you select the Generate Random Key option, a unique encrypted key is created without entering a password. Figure 8-6 Change Password Window Table 8-11 describes the components of the Change Password window. Table 8-11 Change Password Window Components Components Chapter 8 Description Principal Displays the name of the principal that you are editing.
Administering the Kerberos Server Password Tab (Principal Information Window) Table 8-11 Components 164 Change Password Window Components Description New Password Specifies the new password information. This is a temporary password because the principal is required to change the password of the user during next logon. The assumption is that the NoChangeReqPwd setting in the password policy file of the principal is set to 0 (zero), which is the default.
Administering the Kerberos Server Changing a Key Type Changing a Key Type For a strong enterprise wide security between the Kerberos servers and clients, all principals must have 3DES keys using Normal (V5) salt. Changing a DES-CRC or DES-MD5 Principal Key Type to 3DES If you are changing the key type for a service principal that has extracted keys, complete the following steps on the host system where the service resides: Step 1.
Administering the Kerberos Server Changing a Key Type • If the principal is a service principal with an extracted key, select the Generate Random Key check box to generate a random key. Step 8. Click OK to close the Change Password window. Step 9. Click OK to close the Principal Information window. If the principal is a user principal, communicate the new temporary password to the user. During next logon, the principal must change the password.
Administering the Kerberos Server Changing Principal Attributes Changing Principal Attributes You can change the attributes of a principal in the Principal Information window (Figure 8-5). These attributes are the characteristics and properties assigned to a user or a service principal. Attributes control how a principal behaves and what that principal can do, such as renewing and forwarding valid tickets. To change the principal attributes, complete the following steps: Step 1.
Administering the Kerberos Server Attributes Tab (Principal Information Window) Attributes Tab (Principal Information Window) Attributes are the characteristics and properties assigned to a principal that control the behavior of the principal. You can use the Attributes tab in the Principal Information window to assign attributes for a principal, as shown in Figure 8-7. Figure 8-7 Attributes Tab Table 8-12 describes the components of the Attributes tab.
Administering the Kerberos Server Attributes Tab (Principal Information Window) Table 8-12 Attributes Tab Components (Continued) Components Description LDAP DN Displays the LDAP DN that you are editing. Allow Postdated Specifies whether a principal is allowed for ticket postdating. Postdating is a mechanism that allows a principal to obtain a ticket that is initially invalid, but that can become valid at some time in the future.
Administering the Kerberos Server Attributes Tab (Principal Information Window) Table 8-12 Attributes Tab Components (Continued) Components Allow Forwardable Description Specifies if a principal is allowed ticket forwarding. Forwarding is a process that sends a ticket-granting ticket (TGT) from one network host to another host. The second host system can use the forwarded TGT to generate a new service ticket on behalf of the principal.
Administering the Kerberos Server Attributes Tab (Principal Information Window) Table 8-12 Attributes Tab Components (Continued) Components Require Preauthentication Description Specifies if a principal is required to use preauthentication in the TGT request. Preauthentication means that additional known encrypted data is sent with the ticket request, providing additional security when the TGT is presented to gain access to a secured service.
Administering the Kerberos Server Attributes Tab (Principal Information Window) Table 8-12 Attributes Tab Components (Continued) Components Lock Principal Description Specifies if a principal is active. A locked principal still exists in the principal database, but it is unable to use or provide Kerberos services. The Lock Principal attribute applies to both user and service principals. If you set this attribute for a user principal, tickets cannot be issued to the user.
Administering the Kerberos Server Attributes Tab (Principal Information Window) Table 8-12 Attributes Tab Components (Continued) Components Require Initial Authentication Description Specifies if the server is allowed to issue service to the service principal on behalf of a user principal using a previously obtained TGT. If you set this attribute for the service principal, a user principal must authenticate to the server again, to obtain a ticket for that service.
Administering the Kerberos Server LDAP Attributes Tab (Prinicpal Information Window) LDAP Attributes Tab (Prinicpal Information Window) The LDAP Attributes tab displays the mandatory LDAP attributes that need to be specified while creating a Kerberos principal. These attributes need to be specified only if the LDAP DN does not exist in the Directory server.
Administering the Kerberos Server LDAP Attributes Tab (Prinicpal Information Window) You can use the LDAP Attributes tab in the Principal Information window to assign LDAP attributes for a principal, as shown in Figure 8-8. Figure 8-8 LDAP Attributes Tab Figure 8-8 describes the components of the LDAP Attributes tab, if you have opted for the object class posixaccount. The LDAP Attributes tab displays the mandatory attributes based on the object class selected.
Administering the Kerberos Server Deleting a Service Principal Deleting a Service Principal The Kerberos server requires several specific principals. If you accidentally delete these principals, you must restore the principal database from a backup tape. To delete a service principal that has a random key extracted to the service key table, remove the entry from the v5srvtab service key table file by completing the following steps: Step 1.
Administering the Kerberos Server Extracting Service Keys Extracting Service Keys Unlike users who type their password using a keyboard, a service principal needs to have its secret key automatically available during authentication. Therefore, store the secret key for the service principals on the host where the service is located, in the service key table called the v5srvtab file. The service key table, v5srvtab, contains service principal names and their corresponding keys.
Administering the Kerberos Server Extracting Service Keys If you change the default name and location to a different name and location than the programs of the Kerberos server, you must edit the settings to indicate the new location of the service key table file. Step 8. Select the Generate New Random Key before Extracting option. HP recommends that you select this option for increased security because it generates a new random key before the principal and key are extracted to the service key table. Step 9.
Administering the Kerberos Server Extracting a Service Key Table Extracting a Service Key Table You can extract the key for a service principal to the service key table (v5srvtab) by using the Extract Principal Key to Service Key Table window. Because a service does not enter the password using the keyboard, you must store its secret key in a table. When this service is invoked, the key is obtained from the table.
Administering the Kerberos Server Extracting a Service Key Table Table 8-13 Extract Service Key Table Components Component 180 Description Principal Displays the name of the principal for which you are extracting a key. Service Key Table Type Identifies the type of key table into which the principal name and keys are extracted. Service Key Table Name Displays the default location and name of the service key table.
Administering the Kerberos Server Using Groups to Control Settings Using Groups to Control Settings You can modify the default values used for new principals using the Principal Information window (Figure 8-2). Each realm has a default group, and the default group for the realm contains default values. The values that 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.
Administering the Kerberos Server Using Groups to Control Settings You can also edit the default group by selecting the default@REALM principal from the List of Principals list box in the Principals tab. In the Principals tab, click Edit to open the Principal Information window, and enter the value for all the fields in the General, Password, and Attributes tabs.
Administering the Kerberos Server Group Information Window (Principal Information Window) Group Information Window (Principal Information Window) You can view or modify the default group settings of a realm using the Group Information window. The default group is similar to a template used to control the settings for new principals added to a realm. Changing the settings for the default group does not affect the settings for existing prinicpals in the realm.
Administering the Kerberos Server Group Information Window (Principal Information Window) To open the Group Information window, choose Principal Information>Edit>Edit Default Group to display the Group Information window (Figure 8-10). Figure 8-10 Group Information Window Table 8-14 describes the components of the Group Information window. Table 8-14 Component Group 184 Group Information Window Components Description Displays the default group principal name.
Administering the Kerberos Server Group Information Window (Principal Information Window) Table 8-14 Group Information Window Components Component Group Information window tabs Description Displays the following tabs: • “General Tab (Principal Information Window)” on page 139 • “Password Tab (Principal Information Window)” on page 160 • “Attributes Tab (Principal Information Window)” on page 168 The fields in these tabs are similar to the tabs in the Principal Information window (Figure 8-2).
Administering the Kerberos Server Group Information Window (Principal Information Window) To edit the default group, use the HP Kerberos Administrator or the command-line administrator, discussed as follows: • In the HP Kerberos Administrator window, complete the following steps to edit the default group: 1. Select a principal from the realm. 2. Click Edit to open the Principal Information window. 3.
Administering the Kerberos Server Setting Administrative Permissions Setting Administrative Permissions Use the HP Kerberos Administrator window to assign administrative permissions to users. When you assign administrative permissions to a principal, the principal and its permissions are saved to admin_acl_file located on the primary security server. HP recommends that you add the /admin instance to a principal to identify a principal as an administrator.
Administering the Kerberos Server Administrative Permissions Administrative Permissions You can assign administrative permissions using the Administrative Permissions window. Choose Principal Information>Edit, and select the Edit Administrative Permissions option to display the Administrative Permissions window (Figure 8-11). You can assign different levels of permissions in any combination or all the permissions to a single user.
Administering the Kerberos Server Administrative Permissions the Add Principals, Delete Principals, Change Principal Password, Inquire About Principals, Modify Principals, and Extract Keys permissions. Table 8-15 describes the components of the Group Information window. Table 8-15 Group Information Window Components Component Description Principal Displays the name of the principal that you are editing.
Administering the Kerberos Server Administrative Permissions Table 8-15 Group Information Window Components (Continued) Component Restricted Administrator Description Select this option in addition to the Add Principals, Delete Principals, Modify Principals, Inquire about Principals, Extract Keys, Change Principal Password attributes in the realm of the administrative principal or all realms to permit administrative principals to use these options only for the following principals: • Restricted administ
Administering the Kerberos Server Administrative Permissions Table 8-15 Group Information Window Components (Continued) Component Description Modify Administrative Permissions Modifies administrative permissions for others users. You can modify the administrative permission using the Principal Information>Edit>Edit Administrative Permissions>Administrative Permissions window.
Administering the Kerberos Server Realms Tab Realms Tab 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 principals share the same security and administrative policy.
Administering the Kerberos Server Realms Tab Figure 8-12 Realms Tab Table 8-16 describes the components in the Realms tab. Table 8-16 Component Chapter 8 Realms Tab Components Description List of Realms Displays a list of all the available realms. New Creates a new realm. Delete Deletes a realm. You must select an entry to enable this button.
Administering the Kerberos Server Realms Tab Realm Information Window You can use the Realm Information window to add realms. Click New in the HP Kerberos Administrator window>Realms tab to display the Realm Information window as shown in Figure 8-13. Figure 8-13 Realm Information Window Table 8-17 describes the components of the Realm Information window. Table 8-17 Component Realm 194 Realm Information Window Components Description Name of the new realm.
Administering the Kerberos Server Adding a Realm Adding a Realm When you add a realm, HP Kerberos Administrator automatically creates some reserved principals, which remain in the database. To add a realm, complete the following steps: Step 1. In the HP Kerberos Adminsitrator window, select the Realms tab (Figure 8-12). Step 2. In the Realms tab, click New to display the Realm Information window (Figure 8-13). Step 3. Enter the name of the new realm in the Realm field. Step 4.
Administering the Kerberos Server 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 from the database, you can use the HP Kerberos Administrator window or the command-line administrator. For more information, see “Deleting a Principal” on page 151. To delete a realm, complete the following steps: Step 1. In the HP Kerberos Administrator window, select the Realms tab (Figure 8-12). Step 2.
Administering the Kerberos Server Remote Administrator – kadmin_ui Remote Administrator – kadmin_ui The kadmin_ui utility is the GUI-based Kerberos remote administrative utility that runs on the secondary security servers and clients. Principals with administrative privileges use the remote administrator to maintain the database on the primary security server from their local workstation. You can use kadmin_ui to accomplish the following tasks: • Add, modify, specify, or delete principals.
Administering the Kerberos Server Remote Administrator – kadmin_ui Step 1. Execute the following command at the HP-UX prompt: # /opt/krb5/kadminl_ui The logon screen displays as shown in Figure 8-14. Figure 8-14 Logon Screen Step 2. Enter your principal name and password in the logon screen. Step 3. Click OK to display the change password window as shown in Figure 8-15.
Administering the Kerberos Server Remote Administrator – kadmin_ui Step 4. Enter a new password in the change password screen to change your password, and click OK. Figure 8-15 Change Password Screen NOTE This screen is displayed only when you first log on using the remote administrator. To access the database using the remote administrator, you must have the appropriate administrative permissions. The warming message, shown in Figure 8-16, displays if you do not have administrative privileges.
Administering the Kerberos Server Remote Administrator – kadmin_ui The graphical user interface for the remote administrator is similar to that for the local administrator. For more information on using the remote administrator, kadmin_ui, and administering your Kerberos server, see “Local Administrator – kadminl_ui” on page 134.
Administering the Kerberos Server Manual Administration Using kadmin Manual Administration Using kadmin You can use the command-line administrator to administer the principal database. It enables principals with administrative privileges to maintain the principal database. You must include all the users, clients, and services authenticated by the Kerberos server into the principal database.
Administering the Kerberos Server Manual Administration Using kadmin Only a user with root permission can invoke the local command-line administrator, kadminl. To log on to the remote administrator, kadmin, use a principal account that has an entry in admin_acl_file and an account that has at least inquire privileges. For complete access to all functions, use an unrestricted administrative principal account, one with the * permissions in admin_acl_file. The account must at least have inquire privileges.
Administering the Kerberos Server Manual Administration Using kadmin HP recommends that you use the graphical user interface administrative utility, kadminl_ui, to administer these parameters. Adding a New Principal You must specify the add administrative privilege in admin_acl_file to add a principal to the database. To add a new principal, type kadmin add at the HP-UX prompt. This command adds a new principal with the specified name and password to the principal database.
Administering the Kerberos Server Manual Administration Using kadmin For example, to add a new principal admin, type kadmin at the HP-UX prompt, and specify the add command, the principal name, and the policy name.
Administering the Kerberos Server Manual Administration Using kadmin command: cpw Name of Principal: admin Enter password: password Re-enter password for verification: password Principal modified Changing Password to a New Randomly Generated Password The cpwrnd command changes the password of a principal to a new randomly generated password.
Administering the Kerberos Server Manual Administration Using kadmin Extracting a Principal The ext command securely extracts the key of the principal into a local service key table file. By default, the host/fqdn@REALM principal is extracted into the v5srvtab file, where fqdn is the fully qualified domain name of the host system. If the principal does not exist in the principal database, it is added with the name that you have specified.
Administering the Kerberos Server Manual Administration Using kadmin [principal] Specifies an alternate principal to extract other than the default host/fqdn@REALM principal, for example, ext finance@BAMBI.COM After ext executes, it prompts you for the service key table file name. The default file name is /krb5/v5srvtab. Listing the Attributes of a Principal The inq command lists the attributes of the principal, if it exists.
Administering the Kerberos Server Manual Administration Using kadmin policy Specifies the new policy name. If you do not specify a policy name, the default policy is applied. dn Specifies the LDAP DN name. If you do not specify an LDAP DN name, the default policy is applied.
Administering the Kerberos Server Manual Administration Using kadmin Command: mod Name of Principal to Modify: admin Parameter Type to be Modified (attr,fcnt,vno,policy,dn or quit ):fcnt Failure Count (or quit): Principal modified. Key Version Number Attribute Every principal password has an associated version number that identifies the frequency of password changes. When you create a principal, its password version number is inherited from the default group template.
Administering the Kerberos Server Manual Administration Using kadmin Following is a sample output for the mod command with the dn parameter: Command: mod Name of Principal to Modify: admin Parameter Type to be Modified (attr,fcnt,vno, policy,dn or qui t) :dn Enter LDAP DN name or quit: Principal modified. Policy Name This option specifies the policy name subscribed by the principal.
Administering the Kerberos Server Manual Administration Using kadmin The Allow Postdated attribute applies to both user and service principals specified as follows: NOTE • You can issue either a postdated or postdatable ticket for user principals. • The server can issue postdated service tickets for the service. Before the server issues a postdated service ticket, the requesting user must possess a postdatable TGT.
Administering the Kerberos Server Manual Administration Using kadmin NOTE Before the server issues a renewable service ticket, the requesting user must possess a renewable TGT. To modify the type of the parameter attr for the principal admin and to set the Allow Renewable attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.
Administering the Kerberos Server Manual Administration Using kadmin Command: mod Name of Principal to Modify: admin Parameter Type to be Modified (attr,fcnt,vno, policy,dn or qui t) :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.
Administering the Kerberos Server 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 and determines which key is used to encrypt the requested service tickets. This setting controls the security protocol between a client application, initiator, and a service called the acceptor.
Administering the Kerberos Server Manual Administration Using kadmin Require Preauthentication Attribute The Require Preauthentication attribute determines whether a principal is required to preauthenticate when requesting a TGT. Preauthentication implies that the client logon program attaches known encrypted data to a ticket request, providing additional security when the TGT is presented to access a secured service. The Require Preauthentication attribute applies to user and service principals.
Administering the Kerberos Server Manual Administration Using kadmin When a new principal is added to the database or when a password of the principal is changed, this attribute is controlled by the NoReqChangePwd setting in the password policy file of the principle. By default, NoReqChangePwd is set to 0 (zero), that is, the user must change the password at first logon.
Administering the Kerberos Server Manual Administration Using kadmin To modify the type of the parameter attr for the principal admin and to set the Lock Principal attribute, type kadmin at the HP-UX prompt and specify the mod command, the principal name, the attr parameter type, and the attribute.
Administering the Kerberos Server Manual Administration Using kadmin Require Initial Authentication Attribute The Require Initial Authentication attribute specifies if the server is allowed to issue service tickets to a service principal on behalf of a user principal using an existing TGT. The Require Initial Authentication attribute applies only to service principals.
Administering the Kerberos Server Manual Administration Using kadmin You can use the kadmin inq command to view the attribute of the principal. With Require Initial Authentication selected (tgt), the inquire command shows TGT_BASED in the attributes field. Without the Require Initial Authentication setting (notgt), the text does not appear in the attributes field. Table 8-18 displays the output of the HP Kerberos Administrator>Attributes tab setting that is equivalent to the kadmin command.
Administering the Kerberos Server Manual Administration Using kadmin Following is a sample output of the Password Change Service attribute: Command: mod Name of Principal to Modify: admin Parameter Type to be Modified (attr, fcnt, vno, policy,dn or q ui) :attr Attribute (or quit): {cpwsrv|nocpwsrv} Principal modified. Password Expiration Attribute A principal password may have a finite or an infinite lifetime.
Administering the Kerberos Server Manual Administration Using kadmin Because the expiration time is calculated from the time you add a new principal to the database, the password change load on the server is distributed over time. Therefore, you can select a password expiration in the default group principal template without affecting the administrative load, provided you add new principals over a period of time.
Administering the Kerberos Server Manual Administration Using kadmin You cannot set this attribute using the command-line administrator. Maximum Renew Time Attribute The Maximum Renew Time attribute controls the renew time limit for renewable tickets. If you set the renew time longer than the renew time assigned to the krbtgt/REALM@REALM principal, the settings in the krbtgt/ principal take precedence. You cannot set this attribute using the command-line administrator.
Administering the Kerberos Server Principal Database Utilities Principal Database Utilities Principal database utilities are tools that help you 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 Kerberos server. To use the principal database utilities, you must have root user privileges. Table 8-6 lists the global database tasks and the tools used to perform each task.
Administering the Kerberos Server Kerberos Database Utilities Kerberos Database Utilities The primary security server contains a database of all principals that are trusted in each of the supported realms. You can also create the database during installation. See “Auto-Configuration of the Kerberos Server” on page 63 for more information. The kdb_create utility creates a Kerberos database and adds a realm to the existing database. You cannot use this utility if you do not remember the master password.
Administering the Kerberos Server Kerberos Database Utilities • DES-CRC or 1: DES-CBC-CRC The default, DES3-CBC-MD5, will be set as the encryption type if you do not specify any of the encryption types previously mentioned. NOTE -f keyfile Specifies an alternate name for the stash file when used with the -s switch. If you do not use the -f switch, .k5.REALM is used as the default keyfile. -M mkeyname Specifies an alternate primary principal name. The default primary name is K/M@REALM.
Administering the Kerberos Server Kerberos Database Utilities Adding principals to database... Cleaning up.... shell% The kdb_create command creates the following principals: IMPORTANT • K/M@ This is the default key name. However, you can configure this key name. • default@ • kadmin/@ • kcpwd/@ • krbtgt/@ Do not delete these principals. The K/M keyname is the default master key name.
Administering the Kerberos Server Kerberos Database Utilities • DES-MD5 • DES-CRC The encryption type selected during database creation determines the encryption type applied to the master password, which in turn is used to create the key that secures all records stored in the principal database. Encrypt the database using DES encryption if you are installing a secondary security server that has an existing principal database encrypted using DES.
Administering the Kerberos Server 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 command-line options, it prompts you with a confirmation message and then removes the default principal database, /krb5/prinicpal. To confirm the deletion, type yes otherwise, kdb_destroy returns the message Database not destroyed.
Administering the Kerberos Server Destroying the Kerberos Database sure? (type ‘yes’ to confirm)? Database destroyed! Chapter 8 229
Administering the Kerberos Server 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 on the terminal using the stdout command. NOTE You must be a root user to run the kdb_dump program.
Administering the Kerberos Server 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 overrides the existing database entries with the corresponding entries present in the dump file. Principals in the existing database that are absent in the dump file are not changed or removed. HP recommends that you run the kdb_load utility on the primary security servers only.
Administering the Kerberos Server Stashing the Master Key Stashing the Master Key The kdb_stash utility stores the master key, the encrypted master password, to a stash file. This utility runs on the primary and secondary security servers. Use the kdb_stash utility to store the master key in a stash file. You must specify the same key type and master password that you specified when you created the database.
Administering the Kerberos Server Stashing the Master Key Following is an example of using kdb_stash: shell% kdb_stash -f Enter password: Re-enter password for verification: Chapter 8 233
Administering the Kerberos Server Starting and Stopping Daemons Starting and Stopping Daemons If you change the configuration of the Kerberos server, you must stop and restart the services and daemons for the changes to take effect. Table 8-8 briefly describes the related services and daemons that you must stop and restart.
Administering the Kerberos Server Maintenance Tasks Maintenance Tasks Following are the maintenance tasks associated with the Kerberos server: • “Protecting Security Server Secrets” on page 235 • “Backing Up primary security server Data” on page 236 Protecting Security Server Secrets The Kerberos server stores the following types of secrets: • host/fqdn@REALM service principal • Master password It is crucial that these secrets not be compromised.
Administering the Kerberos Server Maintenance Tasks Backing Up primary security server Data Save the copied information to a CD or tape — whatever your preferred archive method is. Be aware that primary security server files contain sensitive information; therefore, do not copy files unless you intend to properly secure the backup copies. Be sure to make backup copies of the following: • admin_acl_file • password.policy (password.pol) • Principal database files • krb.
Administering the Kerberos Server Maintenance Tasks • Run the following command as a root user: # /sbin/init.d/krbsrv stop Step 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. Step 3.
Administering the Kerberos Server Removing Unused Space from the Database Removing Unused Space from the Database After long and continued use, the principal database on the primary security server can grow large due to unused space. When you delete a principal, the space that the record had occupied is not removed. Instead, the space is reserved and marked as available. Therefore, after extensive use, the database can grow very large.
Administering the Kerberos Server Removing Unused Space from the Database Step 8. Remove the /tmp/filename file after you have verified that the new database is functioning without problems.
Administering the Kerberos Server Removing Unused Space from the Database 240 Chapter 8
9 Propagating the Kerberos Server This chapter describes how to propagate the Kerberos database from the primary security server to the secondary security server.
Propagating the Kerberos Server This chapter discusses the following topics: NOTE 242 • “Propagation Hierarchy” on page 243 • “Service Key Table” on page 244 • “Propagation Tools” on page 246 • “The kpropd Daemon” on page 248 • “The mkpropcf Tool” on page 249 • “The kpropd.
Propagating the Kerberos Server Propagation Hierarchy Propagation Hierarchy To authenticate users on the network, each secondary security server must contain the latest copy of the principal database, at all times. secondary security servers obtain the copy of the principal database from the primary security server using the database propagation service.
Propagating the Kerberos Server Service Key Table Service Key Table The /opt/krb5/v5srvtab file is the service key table file that contains service principal names with their corresponding secret keys. You must store this file on the system that hosts the service or application, which requires an extracted key. Secured application servers use the keys in this file to decrypt data packets, which the security server encrypts, using a copy of the same key.
Propagating the Kerberos Server Service Key Table To extract the principal to a local service key table file, SrvTab, type kadmin at the HP-UX prompt and specify the ext command, the principal name, and the service key table file name.
Propagating the Kerberos Server Propagation Tools Propagation Tools The kpropd daemon manages and performs propagation of the principal database on each server in the propagation hierarchy. It uses the following local files: • prop_q A default propagation input queue file that contains the names of every principal whose record has changed since the last successful database propagation. • prop_q.wrk A temporary working copy of prop_q, the default propagation input queue file.
Propagating the Kerberos Server Propagation Tools Table 9-1 Propagation Tools (Continued) If You Want To: Manually control propagation on one or more servers once propagation is configured and started. Use This Tool: prpadmin For more information on the process for configuring propagation, see “Setting Up Propagation” on page 258. This chapter contains a detailed discussion of these tools.
Propagating the Kerberos Server The kpropd Daemon The kpropd Daemon The /opt/krb5/sbin/kpropd daemon propagates the principal database from one server to another and starts running when the security server starts up. It propagates principal records from a given security server to kpropd on the receiving security server or to the propagation plug-in on the receiving security server, if kpropd is not running on this security system.
Propagating the Kerberos Server The mkpropcf Tool The mkpropcf Tool The /opt/krb5/install/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 security servers. When you execute mkpropcf on the primary security server without any arguments, it creates the krpopd.ini file in the /opt/krb5 directory. The mkpropcf tool derives the information from the krb.
Propagating the Kerberos Server The mkpropcf Tool -f Overwrites the kpropd.ini file. You can use this option with the -i option to explicitly overwrite the kpropd.ini file. To synchronize the kpropd configuration, HP recommends that you export the original configuration, kpropd.ini, on the primary security server to export.ini, and then copy the export file to each of the secondary security servers and execute the following command at the HP-UX prompt: mkpropcf -i export.
Propagating the Kerberos Server The kpropd.ini File The kpropd.ini File The /opt/krb5/kpropd.ini file is the propagation configuration file created by the mkpropcf tool using the information from the local krb.conf file. Ensure that only authorized users have access to this file. Unauthorized access to kpropd.ini can jeopardize the integrity of your realm. Intruders who modify or replace entries can also modify your principal database.
Propagating the Kerberos Server The kpropd.ini File Sections The kpropd.ini file stores configuration parameters required for propagation. This file contains the following sections: • The [default_values] section controls the various global propagation properties. The listed values apply to all security servers unless you override the defaults by specifying different values in the [secsrv_name] section for a given security server.
Propagating the Kerberos Server The kpropd.ini File Specifies the length of time for which a session key is valid, where n indicates the number of seconds, minutes, hours, or days. The default is value 6 hours. max_cache=n[K|M] Specifies the maximum size that each cache file of the security server (prop_hostname) can reach before it is deleted, where n indicates the number of bytes, kilobytes, or megabytes. A deleted cache file initiates a full database propagation when the connection is re-established.
Propagating the Kerberos Server The kpropd.ini File 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][,...]] Specifies the realms whose records are propagated to the secondary security servers. The default value, all, propagates principal records from all realms to all security servers.
Propagating the Kerberos Server The kpropd.ini File child[n]=fqdn Specifies the child security server of the secsrv_name in the propagation hierarchy, where fqdn is the FQDN 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.
Propagating the Kerberos Server The kpropd.ini File [default_values] interval=15s key_exp=6h max_cache=1024K max_retry_delay=1h net_timeout=30s port=kerberos-adm primary_realm=REALM1 realms=all service_name=host [sersrv1] child = secsrv2 [secsrv2] child1 = secsrv3 child = secsrv4 parent = secsrv1 [secsrv3] parent = secsrv2, realms = REALM1 [secsrv4] parent = secsrv2, realms = REALM2 The [default_values] section lists the default values that mkpropcf may create using the krb.
Propagating the Kerberos Server The prpadmin Administrative Application The prpadmin Administrative Application The /opt/krb5/adm/prpadmin administrative application runs on all security servers and helps you manage the propagation system. For example, to propagate all the contents of the primary principal database to all the secondary security servers, execute the prpadmin full_dump command on the primary security server. You can run prpadmin from the command line or in a shell-like command loop.
Propagating the Kerberos Server Setting Up Propagation Setting Up Propagation After installing and configuring your primary and secondary security servers, you must propagate principal database information from the primary security server to all secondary security servers. Before you can configure propagation, each secondary security server must have an existing principal database to act as a container for the information being propagated to the server.
Propagating the Kerberos Server Setting Up Propagation Table 9-2 lists the daemons, and briefly describes their functions. To avoid confusion and redundancy in this section regarding names, Table 9-2 also indicates the generic names used in this document to discuss the daemon. Table 9-2 primary security server Services and Daemons Daemon Name Function Generic Usage Name kadmind Accepts administration requests from the administrator and database propagation requests from the propagation daemon, kpropd.
Propagating the Kerberos Server Setting Up Propagation 3. From the primary security server /opt/krb5/install directory, run the following command: # 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 implement your preferred hierarchy. For more information on this file, see “The kpropd.ini File” on page 251. 4. Copy the kpropd.
Propagating the Kerberos Server Setting Up Propagation NOTE The is the same as the one added on the primary security server in step 2. Step 5. Start the admin daemon on the secondary security server by using the following command: # /opt/krb5/sbin/kadmind Step 6. Start the propagation daemon on the primary security server, and verify whether the daemons have started or not, by using the following command: # /opt/krb5/sbin/kpropd Propagation System Started.
Propagating the Kerberos Server Setting Up Propagation Verify that propagation has occurred on the secondary security server by using the kdb_dump utility to view the contents of the principal database on the secondary security server. The existence of recently added principal accounts indicates a successful propagation. For information on troubleshooting problems encountered during propagation, see “Monitoring Propagation” on page 263.
Propagating the Kerberos Server Monitoring Propagation Monitoring Propagation You must regularly monitor database propagation between servers. Monitoring helps you to identify the following problems: • Primary-secondary link failure • Stalled propagation To monitor the propagation, you need to examine the log file and the propagation queue files. When propagation problems occur, the copies of the database on the secondary security servers do not match with the database on the primary security server.
Propagating the Kerberos Server Monitoring Propagation [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.
Propagating the Kerberos Server Monitoring Propagation For example, a prop_hostname file that is older than 48 hours or is unusually large indicates a propagation problem between the primary and secondary security servers as specified in hostname. Updating the principal.ok Time Stamp You may notice that, by default, the time stamp of the principal.ok file on the primary security server does not update after propagation. On the primary security server, the principal.
Propagating the Kerberos Server Monitoring Propagation attempt is sent to the primary security server. However, if the principal fails on one server as many times as specified by the MaxFailAuthCnt parameter in the password policy file, that principal is locked out. HP authentication servers do not issue different messages for different situations that cause authentication failure. For security reasons, the error message displayed is the same for bad password, bad user, or locked user.
Propagating the Kerberos Server Monitoring Propagation incremental database propagation. To ensure accurate results, dump the databases simultaneously when administrative activity is at a minimum. Under these conditions, consider a discrepancy of more than five principal entries to be significant.
Propagating the Kerberos Server Monitoring Propagation Step 3. Restart the daemons on both the primary and secondary security servers. Step 4. To compare the files for discrepancies, copy the files to a common location and execute the following command at the HP-UX prompt: # diff primary.db secondary.db > diffs_p.db The diff command creates a file, diffs_p.db, which lists each principal entry on the primary database that does not match an entry on the secondary principal database.
Propagating the Kerberos Server Monitoring Propagation # rm -r -f /opt/krb5/prop/* Step 3. Restart the propagation daemon by using the following command: # /opt/krb5/sbin/kpropd Step 4. Perform a full dump to all secondary security servers by using the following command: # /opt/krb5/admin/prpadmin full_dump This process may take a lot of time if the database contains more than 10,000 principals, and if many secondary security servers exist that act as propagation servers.
Propagating the Kerberos Server Monitoring Propagation If you encounter the following error message after installing a new secondary security server and attempting propagation, restart the daemons on the secondary security server after the full dump is complete: TGS: Error processing request from host Converting a secondary security server to a primary security server You may need to convert a secondary security server to a primary security server, for instance, during disaster recovery.
Propagating the Kerberos Server Monitoring Propagation Step 4. Remove the Kerberos server software on the secondary security server. Step 5. Install the Kerberos server software on the previous secondary security 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 security server in step 2. These are the same files that were created during installation in step 5.
Propagating the Kerberos Server Configuring Multirealm Enterprises Configuring Multirealm Enterprises When you support multiple realms, additional configuration steps are required for both the security servers and clients. This section discusses the servers requirements. Number of Realms per Database A single primary security server supports more than one realm.
Propagating the Kerberos Server Configuring Multirealm Enterprises Multiple primary security servers Supporting a Single Realm You must have one primary security server for each realm if you have distributed administrative groups in which each group maintains its own realm information. You cannot propagate changes from one primary security server to another. You can only propagate changes from a primary security server to a secondary security server.
Propagating the Kerberos Server Configuring Multirealm Enterprises Database Propagation for Multirealm Databases If you plan to support more than one realm in a single principal database on a primary security server and to propagate only selected realms to certain secondary security servers, you must perform additional steps when you configure propagation. HP assumes that you are familiar with the propagation setup procedure as specified in “Propagation Hierarchy” on page 243.
10 Managing Multiple Realms This chapter describes how to set up and configure interrealm authentication between Kerberos servers, and how to manage multiple realms. You must establish trust between the two realms before a principal in one realm can access a service in another realm.
Managing Multiple Realms This chapter discusses the following topics: 276 • “Considering a Trust Relationship” on page 277 • “Configuring Direct Trust Relationships” on page 279 • “Hierarchical Interrealm Trust” on page 281 Chapter 10
Managing Multiple Realms Considering a Trust Relationship Considering a Trust Relationship You can 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 each another.
Managing Multiple Realms Considering a Trust Relationship Hierarchical Trust In interrealm 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.COM are child realms of their respective parent realms, BAMBI.COM and JUNGLE.COM.
Managing Multiple Realms Configuring Direct Trust Relationships Configuring Direct Trust Relationships If the Kerberos security servers manage all the realms in a multirealm environment, you must add interrealm principals to the principal databases for each realm. Interrealm principals are special-case krbtgt/REALM1@REALM2 principal accounts, where krbtgt/REALM1 is the ticket-granting service principal for realm 1 and REALM2 is the foreign realm.
Managing Multiple Realms Configuring Direct Trust Relationships • The Kerberos server does not recognize the realm listed in the interrealm ticket, that is, when a proper trust relationship between the realms is not established. • The Kerberos server does not recognize the requested service principal, and has no further trust relationships for which it returns an interrealm ticket. To set up a cross-realm authentication between the two realms ADMIN.BAMBI.COM and IT.BAMBI.
Managing Multiple Realms Hierarchical Interrealm Trust Hierarchical Interrealm Trust You need to use hierarchical interrealm authentication when a realm does not have a direct path to its destination realm, but has a path to an intermediate realm. Hierarchical Chain of Trust Interrealm 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, consider realm 1 as X.Y.A , realm 2 as X.Y.
Managing Multiple Realms Hierarchical Interrealm Trust interrealm ticket from VIBGYOR.INDIGO.COM, and can use this interrealm ticket to contact GREEN.YELLOW.COM for a ticket to use a service in its realm. Hierarchical Interrealm Configuration To configure realms to perform hierarchical interrealm authentication, complete the following steps in the local realm, intermediate realm, and target realm: Step 1.
Managing Multiple Realms Hierarchical Interrealm Trust These actions are described in detail in the following sections. The example configuration in this section uses the interrealm authentication principals shown in Figure 10-1. Figure 10-1 Hierarchical Interrealm Configuration The relationships are defined as follows: Chapter 10 • krbtgt/BAMBI.COM@FINANCE.JUNGLE.COM allows the server in BAMBI.COM to accept tickets from FINANCE.JUNGLE.COM. • krbtgt/IT.JUNGLE.COM@BAMBI.COM allows the server in IT.
Managing Multiple Realms Hierarchical Interrealm Trust For interrealm authentication in the other direction, two-way hierarchical interrealm authentication, you must also add these principals: • krbtgt/FINANCE.JUNGLE.COM@BAMBI.COM allows the server in FINANCE.JUNGLE.COM to accept tickets from BAMBI.COM. • krbtgt/BAMBI.COM@IT.JUNGLE.COM allows the server in BAMBI.COM to accept tickets from IT.JUNGLE.COM. Configuring the Local Realm To configure the local realm, consider the local realm as FINANCE.JUNGLE.
Managing Multiple Realms Hierarchical Interrealm Trust Configuring the Intermediate Realm To configure the intermediate realm, consider the local realm as FINANCE.JUNGLE.COM , the intermediate realm as BAMBI.COM , the target realm as IT.JUNGLE.COM, and complete the following steps in the BAMBI.COM realm: Step 1. Use the Kerberos administrative utility, HP Kerberos Administrator, to add the krbtgt/BAMBI.COM@FINANCE.JUNGLE.COM principal, which allows users in the FINANCE.JUNGLE.
Managing Multiple Realms Hierarchical Interrealm Trust Step 7. Enable the same settings for this principal as for the first krbtgt/BAMBI.COM@IT.JUNGLE.COM principal, with the same settings enabled as used for the principal in the local realm. Refer to step 2 in “Configuring the Target Realm” on page 286. Configuring the Target Realm To configure the target realm, consider the intermediate realm as BAMBI.COM , the target realm as IT.JUNGLE.COM and complete the following steps in the IT.JUNGLE.
Managing Multiple Realms Hierarchical Interrealm Trust Chapter 10 287
Managing Multiple Realms Hierarchical Interrealm Trust 288 Chapter 10
11 Troubleshooting This chapter describes how to troubleshoot the Kerberos server, and also includes the strategies and tools to use while investigating the software and hardware components of the Kerberos server.
Troubleshooting When you encounter a problem, you may need to investigate many hardware and software components. You can identify and resolve some problems quickly, such as invalid software installation, version incompatibilities, insufficient HP-UX resources, corrupt configuration shell scripts, and programming or command errors. Other problems require more investigation.
Troubleshooting Characterizing a Problem Characterizing a Problem You need to consider many questions while 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 has happened.
Troubleshooting Characterizing a Problem • Data corruption. • Logging messages at the syslog. Knowing what has recently changed on your network can also help you understand whether the problem is software-related or hardware-related.
Troubleshooting Diagnostic Tools Summary Diagnostic Tools Summary Table 11-1 describes the most frequently used diagnostic tools, which are documented in the link installation manuals. Table 11-1 Tool Name Chapter 11 Diagnostic Tools Description netstat A nodal management command that returns statistical information regarding your network. landiag A diagnostic program that tests LAN connections between HP computers.
Troubleshooting Troubleshooting Kerberos Troubleshooting Kerberos When troubleshooting problems with Kerberos, you need a reference point from which to work. For example, is the problem 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 on to a remote system and then the remote system logs back onto the local system.
Troubleshooting Troubleshooting Kerberos UNIX Syslog File The security server daemons, kadmind, kpropd, and kdcd, write error messages to the system log (/var/adm/syslog/syslog.log) file. You can also configure the daemons to log the messages in a different file.
Troubleshooting Troubleshooting Kerberos Services Checklist While troubleshooting ensure, that you have answered all the questions in the troubleshooting checklist in the section “Characterizing a Problem” on page 291. Ensure that your node name and the Internet address exists in the /etc/hosts file, and run the service on your own node. If the server is successful in authenticating, the client and the server side of the service operates correctly.
Troubleshooting Troubleshooting Kerberos Table 11-2 Troubleshooting Scenarios (Continued) Clock skew too great in KDC reply while getting initial credentials. This problem generally occurs because the clock of the system deviates too much from the time on the authenticating KDC. A clock skew time of up to 5 minutes is allowed. Requesting host principal without fully qualified domain name. The host uses the /etc/hosts file to resolve name lookups before using DNS.
Troubleshooting Troubleshooting Kerberos Table 11-2 298 Troubleshooting Scenarios (Continued) Required parameters in krb.realms missing while initializing the Kerberos context. This problem occurs when the parameters are missing or incorrect in the krb.realms file. Ensure that the krb.realms file has the appropriate information. Stored master key is corrupted while initializing kadminl interface. This message appears if the stash file is corrupted. Recreate the stash file.
Troubleshooting Troubleshooting Kerberos Table 11-2 Table 11-3 Chapter 11 Troubleshooting Scenarios (Continued) Cannot find/read stored master key while getting master key. This problem occurs when the stash file is not found. Provide the master key as a command-line option. You can also create the stash file. Error verifying pre-authentication data type 2. This problem occurs due to an incorrect password. Enter the correct password. Service key not available while getting initial credentials.
Troubleshooting Troubleshooting Kerberos Table 11-3 300 Troubleshooting Scenarios for your LDAP-based Kerberos server (Continued) Scenario Cause Troubleshooting Tips Connection to the LDAP server was lost. Connection to the LDAP server was lost. Verify that the Directory server is accessible, else restart the Directory server. You can also restart the Kerberos server, if needed. LDAP server timeout The directory server timed out a request.
Troubleshooting Troubleshooting Kerberos Table 11-3 Chapter 11 Troubleshooting Scenarios for your LDAP-based Kerberos server (Continued) Scenario Cause LDAP authentication failed The Kerberos server was unable to connect to the Directory server with the information provided in the /opt/krb5/krb5_ld ap.conf configuration file. Troubleshooting Tips Verify that the values of the proxy_user and proxy_user_password are correct.
Troubleshooting Troubleshooting Kerberos Table 11-3 Troubleshooting Scenarios for your LDAP-based Kerberos server (Continued) Scenario Cause LDAP database is read-only An attempt to modify the Kerberos entry failed as the Directory server entry is read-only. Edit the Kerberos configuration file, krb5_ldap.
Troubleshooting General Errors General Errors Following are the general errors that you may encounter while setting up your Kerberos server: • 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.
Troubleshooting General Errors Locking and Unlocking Accounts If a user or a service principal exceeds the maximum number of failed authentication attempts allowed by the password policy file, the account is locked and the principal is not issued a ticket. Alternatively, a security administrator may have purposefully locked a principal account so that it cannot be used. In each case, the principal remains in the principal database but is unable to use the Kerberos services.
Troubleshooting User Error Messages User Error Messages Users may see error messages while using the Kerberos server. The following sections describe user error messages, explain their causes, and suggest corrective actions. Decrypt Integrity Check Failed Explanation: This message is displayed if a user requests a ticket from the server and one of the following conditions is true: • User entered the wrong password for the realm chosen for the ticket request.
Troubleshooting Administrative Error Messages Administrative Error Messages Following are some messages that administrative principals may see when using their accounts. This section also contains some recommended solutions. Password Has Expired While Getting Initial Ticket Explanation: This message may appear when a user tries to log on as a remote administrator using the remote command-line administrator, kadmin.
Troubleshooting Administrative Error Messages key during authentication. If the principal does not have a 3DES key, the tools attempt to negotiate a supported key type. If the tools cannot negotiate a supported key type, the error message Service key not available while getting initial ticket is returned. Action If the user is using the command-line administrator, verify that the user does not enter an inappropriate key type during logon with the -e switch.
Troubleshooting Reporting Problems to Your HP Support Contact Reporting Problems to Your HP 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 HP support contact. Include the following information where applicable: • A characterization of the problem.
Troubleshooting Reporting Problems to Your HP Support Contact Chapter 11 • Prepare a listing of the HP-UX I/O configuration you are using for your HP support contact to further analyze. • 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.
Troubleshooting Reporting Problems to Your HP Support Contact 310 Chapter 11
A Configuration Worksheet The following worksheet helps you configure your Kerberos server with LDAP as the backend database.
Configuration Worksheet Table A-1 Configuration Worksheet Configuration Worksheet for LDAP database Directory administrator DN Directory server host Directory server port Base DN for search Subtree DN Proxy user DN Certificate db path NOTE: Enter the Certificate db path only if you plan to use SSL as your security mechanism Following is an explanation and sample table.
Configuration Worksheet Table A-2 Configuration Worksheet Explanation (Continued) LDAP Server Configuration Worksheet Base DN for search The default base DN for search is the root of the directory tree on the Directory server, where the Kerberos server searches for kerberos principals. Example: ou=people, o=bambi.com Default Principal Subtree DN The default principal subtree DN is where all Kerberos principals are added by default, if no LDAP entry is specified while creating the kerberos principal.
Configuration Worksheet 314 Appendix A
B Sample krb.conf File The sample krb.conf file named krb.conf.sample is available in the /opt/krb5/examples directory. Copy this sample file to /opt/krb5/krb.conf file and modify it to reflect the host names and realm name for your realm.
Sample krb.conf File NOTE If you have configured your Kerberos server with C-Tree as the backend then the realm names are case sensitive. If you have configured your Kerberos server with LDAP as the backend then the realm names are not case sensitive. Replace the underlined Your_Realm_Name, Your_Secondary_Server1, Your_Secondary_Server2, and your_primary_server with the name of your Kerberos REALM, secondary security servers, and the primary security server host names, respectively.
Sample krb.conf File The services File The services File The services file contains entries that allow client applications to establish socket connections to the KDC or to the applications servers.
Sample krb.
C Sample krb.realms File The sample krb.realms file named krb.realms.sample is available in the /opt/krb5/examples directory. You can copy this sample file to the /opt/krb5 directory, and modify it to reflect your realm name.
Sample krb.realms File NOTE The realm names are case sensitive. Replace the underlined Your_Realm_Name, Your_Primary_Security_Server, Your_Secondary_Security_Server, and Your_Domain_Name with the name of your Kerberos REALM and host names of the primary security server and secondary security servers. Your_Primary_Security_Server Your_Realm_Name .Your_Secondary_Security_Server Your_Realm_Name *.Your_Domain_Name Your_Realm_Name The following is an example of the krb.
Glossary A-B admin_acl_file (administrator access control list) Text file that lists the administrators and their respective permissions. HP Kerberos 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 in 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 host names to realm names.
Glossary v5srvtab Ticket-granting ticket See TGT. V v5srvtab Binary file that contains service principal names and their corresponding secret keys.
Glossary Ticket-granting ticket 324 Glossary
