Kerberos
This chapter examines the z/OS implementation of Kerberos.
4.1 Introduction to Kerberos
Figure 4-1 Introduction to Kerberos
Introduction to Kerberos
Kerberos is a network authentication protocol that was developed in the 1980s by Massachusetts Institute of Technology (MIT), in cooperation with IBM and Digital Equipment Corporation. Data Encryption Standard (DES) cryptography and Advanced Encryption Standard (AES) are used to provide data privacy, especially for the sensitive data such as password to log into a server.
In z/OS, this component’s formal name is Integrated Security Services Network Authentication Service for z/OS; however, in this book, we refer to it as Network Authentication Service for z/OS. The GSS-APIs supports the SPKM-3/LIPKEY mechanisms.
Kerberos is an encryption-based security system that provides mutual authentication between the users and the servers in a network environment. The assumed goals for this system are as follows:
•Authentication to prevent fraudulent requests/responses between users and servers that must be confidential and on groups of at least one user and one service.
•Authorization can be implemented independently from the authentication by each service that wants to provide its own authorization system. The authorization system can assume that the authentication of a user/client is reliable.
•Message confidentiality can also be used that provides assurance to a data sender that the message's content is protected from access by entities other than the context's named peer.
The Kerberos authentication is based heavily on shared secrets, which are passwords stored on the Kerberos server. Those passwords are encrypted with a symmetrical cryptographic algorithm, which is DES and AES in this case, and decrypted when needed. This fact implies that a decrypted password is accessed by the Kerberos server, which is not usually required in an authentication system that exploits public key cryptography. Therefore, the servers must be placed in secure locations with physical security to prevent an attacker from stealing a password.
For a complete description of the supported RFCs, see:
The following RFCs are supported by the Kerberos functions:
RFC 1510 The Kerberos Network Authentication Service V5
RFC 3962 Advanced Encryption Standard (AES) Encryption for Kerberos
RFC 3961 Encryption and Checksum Specifications for Kerberos 5 - description of DES3 encryption
RFC 4120 The Kerberos Network Authentication Service (V5) - description of key usage numbers.
The following RFCs supported by the GSS:
•RFC 2078
•RFC 2744
•RFC 1964
•RFC 4121
•RFC 2025
•RFC 2253
•RFC 2459
•RFC 2847
4.2 Kerberos terminology
Figure 4-2 Kerberos terminology
Kerberos terminology
Kerberos terminology includes:
•Realm: The Kerberos domain, that is the set of entities which authenticate using that Kerberos key distribution center (KDC).
•Principal: A client or an application server in a Kerberos domain.
•Instance: Additional distinction between principals names.
•Kerberos name: principal_name.instance@realm
•Kerberos ticket: The ticket is encrypted under a key only known to the Kerberos KDC and the end server. The ticket includes:
 – Client’s identity
 – A dynamically created session key
 – A time stamp
 – A lifetime for the ticket
 – A service name
A ticket can be reused during its lifetime.
•Authenticator: Client’s name and IP address as well as a time stamp. Issued with each client’s request. The authenticator must be different for each request and is used for replay protection.
4.3 Kerberos protocol overview
Figure 4-3 Kerberos protocol overview
Kerberos protocol overview
The Kerberos system consists of three components:
•A client
•A server
•A trusted third party, which is also known as a Key Distribution Center (KDC)
KDC interacts with both a client and server to accept the client’s request, to authenticate its identity, and to issue tickets to it.
The domain served by a single KDC is referred to as a realm. A principal identifier is used to identify each client and server in a realm. The principal name is uniquely assigned for all clients and servers by the Kerberos administrator. All principals must be known to the KDC. Kerberos realms can interoperate by establishing trust relationships, sharing secret keys, between them.
All entities in the network, clients and servers, have their own secret symmetric key. A copy of all the keys is kept in the Kerberos Key Distribution Center. Clients’ keys are actually derived from their password.
Kerberos is intended for corporate networks or intranets, because the scalability of the protocol is directly related to the amount of secret keys that can be managed in a KDC.
Although the Kerberos protocol consists of several sub-protocols, three exchanges are particularly interesting to most readers. The first phase exchange takes place between a client and the authentication server. In this phase, a client asks the authentication server that knows the secret keys of all clients in the realm to authenticate himself and give the client a ticket (called a ticket-granting ticket) to be used to get a secret key which is then shared with an application server the client wants to access.
Upon receiving the ticket-granting ticket, the client sends a request that contains the ticket-granting ticket, for a service ticket to the ticket-granting server, and waits for a service ticket to be returned. Having the session ticket (service ticket) ready, the client is allowed to communicate with the server that is providing a service he wants to use. Optionally, the application server can perform further authentication processing against the client.
Message encoding defined in Kerberos Version 5 is described using the Abstract Syntax Notation 1 (ASN.1) syntax, in accordance with ISO standards 8824 and 8825.
In the remainder of this chapter, we discuss the interactions in more detail. We use the following notations:
•Kx: X’s symmetric encryption key
•Kx,y: Encryption key shared by X and Y (for example, a session key)
•Kx{data}: A message that contains data encrypted with X’s key
4.4 Get a ticket-granting ticket
Figure 4-4 Get a ticket-granting ticket
Phase 1: Authentication service exchange
To simplify our explanation, we us an example with a user named Alice (username=Alice). So, in Figure 4-4 the numbered steps become:
1. Alice enters a user name and password.
2. KAlice{timestamp}, "Alice", tgs, nonce
3. KAlice{KAlice,KDC, nonce}, TGT, where TGT = KAlice{"Alice",KAlice,KDC}
The authentication service exchange is initiated by a client when it wants to get authentication credentials for an application server but currently holds no credentials. Two messages are exchanged between the client and the Kerberos authentication server, then credentials for a ticket-granting server are given to the client. These credentials are the so-called ticket-granting ticket, which is used subsequently to obtain credentials for other services.
This exchange is used for other services, such as the password-changing service, as well.
 
Note: The client’s secret key is used exclusively in this phase.
When a user logs into a client system and enters his password, a client sends the Kerberos authentication server a message that includes a user name in plain text (“Alice”), the current time encrypted with her secret key, and the identity of the server for which the client is requesting credentials.
Upon receiving the request from the client, the authentication server looks up the client name and the service name (the ticket-granting service in this case) in the Kerberos database, and obtains an encryption key for each of them, KAlice and KKDC.
The authentication server then generates a response back to the client, which contains the ticket-granting ticket and a session key KAlice,KDC, which is used in the subsequent secure communication between the client and KDC. The ticket-granting ticket includes the session key KAlice,KDC, the identities of the server and the client, lifetime, and some other information. The authentication server then encrypts the ticket using its own key KKDC. This produces a sealed ticket. The session key KAlice,KDC is also encrypted using the client’s key KAlice with some other information, such as nonce.
The encrypted current time is also known as the authenticator, because the receiver can assure that the sender knows the correct shared secret KAlice, which is the client’s encryption key derived from her password (this key is also referred to as Alice’s long-term key), by decrypting it and validating what is inside. Because the authentication server knows Alice’s secret key, it can evaluate the time decrypted from the received authenticator.
 
Tip: You might have noticed that the clocks on the client system and the KDC must be reasonably synchronized with each other. You can use a network time service to synchronize the clocks.
An authenticator is also used to help the server detect message replays.
Nonce is information used to identify a pair of the Kerberos request and response. You can use a time stamp or a random number generated by a client.
Tgs is the server’s identification, which is the Kerberos ticket-granting server in this case.
Because KAlice is known exclusively by Alice and the KDC, no one but Alice can extract the critical information from the response message, such as the session key KAlice,KDC used in the next phase.
When the client receives the authentication server’s response, it decrypts it using its secret key KAlice and checks to see if the nonce matches the specific request. If the nonce matches, the client caches the session key KAlice,KDC for future communications with the ticket-granting server.
4.5 Request a service ticket
Figure 4-5 Request a service ticket
Phase 2: Ticket-granting service exchange
Because in our example username=Alice and server=Bob, in Figure 4-5 the numbered steps become:
4. KAlice{timestamp}, TGT, "Bob", nonce
5. KAlice,KDC{KAlice,Bob,"Bob",nonce}, tkt_to_Bob, where tkt_to_Bob = KBob{"Alice",KAlice,Bob}
When the ticket-granting server receives the message from the client, it first deciphers the sealed ticket using its encryption key KKDC. From the deciphered ticket, the ticket-granting server obtains the session-key KAlice,KDC. It uses this session key to decipher the authenticator.
The validity checks that performed by the ticket-granting server include verifying the following:
•The client name and its realm in the ticket match the same fields in the authenticator.
•The address from which this message originates is found in the address field in the ticket, which specifies addresses from which the ticket can be used.
•The user-supplied checksum in the authenticator matches the contents of the request. This procedure guarantees the integrity of the message.
Finally, it checks the current time in the authenticator to make certain the message is recent. Again, this requires that all the clients and servers maintain their clocks within some prescribed tolerance.
 
Important: By checking the time stamp in the nanoseconds scale, replay attacks can be detected.
The ticket-granting server now looks up the server name from the message in the Kerberos database, and obtains the encryption key KBob for the specified service.
The ticket-granting server forms a new random session key KAlice,Bob for the benefit of the client (Alice) and the server (Bob), and then creates a new ticket tkt_to_Bob that includes:
•The session key KAlice,Bob
•Identities of the service and the client
•Lifetime
 
Note: The format of the ticket for a particular service is identical to one of the ticket-granting tickets.
The ticket-granting server then assembles and sends a message to the client.
4.6 Authenticate to target server
Figure 4-6 Authenticate to a target server
Phase 3: The client/server authentication exchange
Following our example, in Figure 4-6 the numbered steps become:
6. KAlice,Bob{timestamp}, tkt_to_Bob
7. KAlice,KDC{timestamp} (optional)
The client/server authentication exchange is performed by the client and the server to authenticate each other. The client has been issued credentials for the server using the authentication service or ticket-granting service exchange before the client/server exchange is initiated.
After receiving the ticket-granting server exchange response from the ticket-granting server, the client deciphers it using the ticket-granting server session key KAlice,KDC that is exclusively known by the client and the ticket-granting server. From this message it extracts a new session key KAlice,Bob that is shared with the server (Bob) and the client (Alice). The sealed ticket included in the response from the ticket-granting server cannot be deciphered by the client, because it is enciphered using the server/s secret key KBob.
Then the client builds an authenticator and seals it using the new session key KAlice,Bob. Finally, it sends a message containing the sealed ticket and the authenticator to the server (Bob) to request its service.
When the server (Bob) receives this message, it first deciphers the sealed ticket using its encryption key KBob, which is kept in secret between Bob and the KDC. It then uses the new session key KAlice,Bob contained in the ticket to validate the authenticator in the same way as the ticket-granting server does in the ticket-granting server exchange.
After the server has authenticated a client, an option exists for the client to validate the server (this procedure is called mutual authentication). This prevents an intruder from impersonating the server.
If mutual authentication is required by the client, the server has to send a response message back to the client. The message has to contain the same time stamp value as one in the client’s request message. This message is enciphered using the session key KAlice,Bob that was passed from the client to the server.
If the response is returned, the client decrypts it using the session key KAlice,Bob and verifies that the time stamp value matches one in the authenticator that was sent by the client in the preceding client/server exchange. If it matches, then the client is assured that the server is genuine.
When the client/server exchange has completed successfully, an encryption key is shared by the client and server and can be used for the on-going application protocol to provide data confidentiality.
4.7 Kerberos inter-realm trust relationship
Figure 4-7 Kerberos inter-realm trust relationship
Kerberos inter-realm trust relationship
The Kerberos protocol is designed to operate across organizational boundaries. Each organization that wants to run a Kerberos server establishes its own realm. The name of the realm in which a client is registered is part of the client’s name and can be used by the application server to decide whether to honor a request.
By establishing inter-realm keys, the administrators of two realms can allow a client authenticated in one realm to use its credentials in the other realm. The exchange of inter-realm keys registers the ticket-granting service of each realm as a principal in the other realm. A client is then able to obtain a ticket-granting ticket for the remote realm’s ticket-granting service from its local ticket-granting service. Tickets issued to a service in the remote realm indicate that the client was authenticated from another realm.
This method can be repeated to authenticate throughout an organization across multiple realms. To build a valid authentication path to a distant realm, the local realm must share an inter-realm key with the target realm or with an intermediate realm that communicates with either the target realm or with another intermediate realm.
Realms are typically organized hierarchically. Each realm shares a key with its parent and a different key with each child. If an inter-realm key is not directly shared by two realms, the hierarchical organization allows an authentication path to be easily constructed. If a hierarchical organization is not used, it might be necessary to consult some database to construct an authentication path between realms.
Although realms are typically hierarchical, intermediate realms can be bypassed to achieve cross-realm authentication through alternate authentication paths. It is important for the end-service to know which realms were transited when deciding how much faith to place in the authentication process. To facilitate this decision, a field in each ticket contains the names of the realms that were involved in authenticating the client.
4.8 Some assumptions to Kerberos
Figure 4-8 Some assumptions to Kerberos
Some assumptions to Kerberos
The following assumptions apply to the Kerberos security environment:
•Denial-of-service (DoS) attacks are not addressed by Kerberos. There are places in these protocols where an intruder can prevent an application from participating in the proper authentication steps. Detection and solution of such attacks (some of which can appear to be “usual” failure modes for the system) is usually best left to human administrators and users.
•The secret key must be kept secret by each principal (each client and server). If an attacker steals a principal’s key, it can then masquerade as that principal or impersonate any server of the legitimate principal.
•Kerberos does not address password guessing attacks. If a poor password is chosen, an attacker might be able to mount an offline dictionary attack by repeatedly attempting to decrypt messages that are encrypted with a key derived from the user’s password.
•Kerberos assumes a loosely synchronized clock in the whole system. Workstations might be required to have a synchronization tool such as the time server provided.
•Principal identifiers should not be reused on a short-term basis. Instead, access control lists (ACLs) can be used to grant permissions to particular principals.
4.9 Implementing Network Authentication Service
Figure 4-9 Implementing Network Authentication Service
Implementing Network Authentication Service
The implementation of Network Authentication Service introduces a new UNIX daemon to provide the KDC services (authentication server and ticket-granting server). RACF has been enhanced to provide KDC registry functions to store principals and keys.
This section details the setup of this UNIX daemon and the required configuration files.
SKRBKDC daemon setup
The following steps describe the setup of the Network Authentication Service UNIX daemon called SKRBKDC:
1. Copy the SKRBKDC started task procedure (JCL) from EUVF.SEUVSAM to SYS1.PROCLIB or the procedure library you use in your installation for started tasks. Example 4-1 shows an example of the SKRBKDC started task procedure.
Example 4-1 Example of the SKRBKDC started task procedure
/SKRBKDC PROC REGSIZE=256M,OUTCLASS=A,PARMS=’-kdc’
//*********************************************************************
//* *
//* Procedure for starting the Kerberos Security Server *
//* *
//*********************************************************************
//GO EXEC PGM=EUVFSKDC,REGION=&REGSIZE,TIME=1440,
// PARM=('ENVAR("LANG=En_US.IBM-1047"),TERM(DUMP) / &PARMS
// 1>DD:STDOUT 2>DD:STDERR')
//STDOUT DD SYSOUT=&OUTCLASS,DCB=LRECL=250,FREE=END,SPIN=UNALLOC
//STDERR DD SYSOUT=&OUTCLASS,DCB=LRECL=250,FREE=END,SPIN=UNALLOC
//SYSOUT DD SYSOUT=&OUTCLASS,FREE=END,SPIN=UNALLOC
//CEEDUMP DD SYSOUT=&OUTCLASS,FREE=END,SPIN=UNALLOC
2. Define a group for the started task user ID, with an OMVS segment with a GID value:
ADDGROUP SKRBGRP OWNER(STCGROUP) SUPGROUP(STCGROUP) + DATA(‘GROUP FOR KERBEROS SKRBKDC User ID’) OMVS(GID(20))
The owner that we specify in our examples is for our installation only. You might want change this owner according to your installation standards.
To verify the group is indeed defined correctly, display the group with all the attributes as follows:
LISTGRP SKRBGRP OMVS
3. Define a started task User ID with an OMVS segment with the following values:
 – UID value: 0
 – HOME (directory) value: /etc/skrb/home/kdc
 – PROGRAM value: /bin/sh
 
Attention: Both the HOME and PROGRAM values are case sensitive. You need to define them in lower case.
An example definition is as follows:
ADDUSER SKRBKDC OW(SKRBGRP) DEFLTGRP(SKRGRP) +
NAME(‘KERBEROS User ID’) OMVS(UID(0) HOME(‘/etc/skrb/home/kdc’) + PROG(‘/bin/sh’))
Use the RACF LISTUSER command to check that the user ID is correctly defined:
LISTUSER SKRBKDC OMVS
 
4. Activate the APPL class if not already active:
SETROPTS CLASSACT(APPL) RACLIST(APPL)
5. Define the SKRBKDC application universal read:
RDEFINE APPL SKRBKDC UACC(READ)
6. Activate the PTKTDATA class if not already active:
SETROPTS CLASSACT(PTKTDATA) RACLIST(PTKTDATA)
7. Define Passticket data to the SKRBKDC application.
RDEFINE PTKTDATA SKRBKDC UACC(NONE) SSIGNON(KEYMAKED(3734343237343131))
Pastickets are used internally by the Kerberos security server when the user password is changed.
8. Define a profile for the SKRBKDC SKRBWTR started tasks in the RACF STARTED class:
RDEFINE STARTED SKRBKDC.** OWNER(STCGROUP) + STDATA(USER(SKRBKDC) GROUP(SKRBGRP))
RDEFINE STARTED SKBRWTR.** OWNER(STCGROUP) +
STDATA(USER(SKBRKDC) GROUP(SKBRGRP))
Check the new defined profile by listing it:
RLIST STARTED SKRBKDC.** STDATA
RLIST STARTED SKBRWTR.** STDATA
4.10 Setting up the Kerberos environment variable files
Figure 4-10 Setting up the Kerberos environment variable files
Setting up the Kerberos environment variable files
You must customize the Kerberos environment variable files /etc/skrb/krb5.conf and /etc/skrb/home/kdc/envar for your environment. Samples of these configuration files are supplied in /usr/lpp/skrb/examples. Copy the samples to the locations indicated previously.
The krb5.conf file requires the following updates:
1. Update the default_realm parameter with your installation’s Kerberos realm for the z/OS system. Our DNS name for our z/OS system is WTSC57.KRB390.IBM.COM and our Kerberos realm is KRB390.IBM.COM
2. Update the realms parameter with your z/OS realms and any other so-called peer realms. We updated the realms parameter with our z/OS realm KRB390.IBM.COM and added the DNS name for the z/OS KDC and the z/OS kpassw_server.
3. Update the domain_realm parameter to reflect the z/OS Realm in lowercase and uppercase.
Example 4-2 displays the configuration file, /etc/skrb/krb5.conf, and displays our changes to the configuration file.
Example 4-2 Our changes to the /etc/skrb/krb5.conf file
“libdefaults¨
default_realm = KRB390.IBM.COM
kdc_req_checksum_type = rsa-md5
ap_req_checksum_type = rsa-md5
default_tgt_enctypes = des-cbc-crc,des-cbc-md5
default-tgs_enctypes = des-cbc-crc,des-cbc-nd5
kdc_default_options = 0x40000010
use_dns_lookup = 0
“realms¨
KRB390.IBM.COM = {
kdc = wtsc57.krb390.ibm.com:88
kpasswd_server = wtsc57.krb390.ibm.com:464
}
KRB2000.IBM.COM = {
kdc = pauldeg.krb2000.ibm.com:88
kpasswd_server = pauldeg.itso.ibm.com:464
}
“domain_realm¨
.krb2000.ibm.com = KRB2000.IBM.COM
.krb390.ibm.com = KRB390.IBM.COM
The next step is to configure the environment variable file /etc/skrb/home/kdc/envar with the required changes for your environment.
The defaults in this file are usually fine, except perhaps the time zone and the required logging that you want to perform for the Kerberos server (SKRBKDC).
Example 4-3 shows an example of the environment variable definitions for the Kerberos server.
Example 4-3 Example of the environment variable definitions
General server options
SKDC_DATABASE=SAF
SKDC_PORT=88
SKDC_KPASSWD_PORT=464
SKDC_NETWORK_THREADS=15
SKDC_LOCAL_THREADS=15
SKDC_LOGIN_AUDIT=FAILURE
 
System configuration options
LANG=En_US.IBM-1047
TZ=EST5EDT
NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/En_US.IBM-1047/%N
 
Message/debug options
_EUV_SVC_MSG_LOGGING=STDOUT_LOGGING
_EUV_SVC_DBG_MSG_LOGGING=1
_EUV_SVC_DBG=KRB_KDC.8,KRB_KDB.8
_EUV_EXC_ABEND_DUMPS=0
This completes the setup for the Kerberos server, but before you start the Kerberos server, some additional RACF definitions are required.
4.11 Setting up HFS for Kerberos cache files
Figure 4-11 Setting up HFS for Kerberos cache files
Setting up HFS for Kerberos cache files
The Kerberos runtime stores network credentials in so-called cache files. These are stored in an HFS directory called /var/skrb/creds. This directory structure does not exit by default and requires setup. Also, these files need to be erased periodically. There are several ways to erase the files:
•Use a temporary file system mounted at /var/skrb/creds. This results in all the credentials cache files being deleted each time the system is restarted.
•Erase all of the files in /var/skrb/creds when the /etc/rc initialization script is run. This results in all of the credentials cache files being deleted each time the system is restarted.
•Set up a cron job to run the kdestroy command with the -e option. This results in the deletion of only expired credentials cache files. This is the preferred method for managing the credentials cache files. The cron job should run with UID 0 so that it can delete the cache files.
The /var/skrb/creds directory permission bits should be set to 777 using the chmod command:
chmod 777 /var/skrb/creds
4.12 Kerberos integrated with RACF
Figure 4-12 Kerberos integrated with RACF
Kerberos integrated with RACF
The Kerberos security server supports two registry database types: SAF (for example RACF) and NDBM (Kerberos principals stored in a UNIX System Services database using HFS or zFS. IBM recommends that you use the SAF registry unless it is necessary to share the Kerberos registry with one or more KDC instances running on another operating system.
If SAF is selected then RACF provides the functions to customize and access data for use with Kerberos. Then the z/OS Network Authentication Service server will maintain registry of principal and global information, which is stored using RACF through User and General Resource Profiles.
You can administer the Network Authentication Service server through the RACF panels and commands and obtain this information through an SAF callable service. Kerberos application servers can use SAF callable services to parse Kerberos tickets to obtain principal names, and to map from principal to RACF user and vice versa.
Local Kerberos principals are defined as RACF users with a KERB segment. The information about the local and foreign realms are defined in the RACF class REALM in specific profiles. The profiles contain:
•Local realm information, the name, key, and ticket lifetime (MIN, MAX, and DEFAULT in seconds).
•Foreign realm trust relationships. These are defined in pairs, which also include a key. RACF maps foreign Kerberos principals using the KERBLINK class profiles.
The Kerberos principal’s password and the RACF user password are integrated. The Kerberos password is subject to RACF SETROPTS rules and installation-defined rules.
Principals must keep their secret keys secret. If an intruder steals a principal’s key, it can then masquerade as that principal or impersonate any server to the legitimate principal.
RACF Remote Sharing Facility (RRSF) has to be defined in local mode in order to generate the corresponding Kerberos secret key whenever the user changes their password. Kerberos uses RRSF services to make sure this happens.
Some RRSF RACF functions require a previously established user ID association. A user ID association is an association between two or more user IDs on the same or different RRSF nodes. There are two type of user ID associations:
•A peer association allows either of the associated user IDs to direct commands to the other and allows password synchronization.
•In a managed association, one of the user IDs is designated as the managing ID, and the other is designated as the managed ID. The managed ID cannot direct commands to the managing ID. There is no password synchronization in a managed association.
To use the password synchronization and command direction functions, you need to activate and define profiles in to the RRSFDATA class.
Defining RRSF in local mode
To define RRSF in local mode:
1. Activate the RACF RRSFDATA class if it is not activated already. The RRFSDATA class needs to be RACLISTed and activated for generic command processing:
SETROPTS CLASSACT(RRSFDATA)
SETROPTS GENERIC(RRSFDATA)
SETROPTS GENCMD(RRSFDATA)
SETROPTS RACLIST(RRSFDATA)
2. Define a new member IRROPT01 in SYS1.PARMLIB and include the TARGET command as shown in Example 4-4 to configure the RRSF in local mode.
Example 4-4 Define a new member
TARGET -
NODE(SC57) -
DESCRIPTION('WS57TS SYSTEM') -
PREFIX(SYS1.RACF) -
OPERATIVE LOCAL -
WORKSPACE(VOLUME(PDGTS1))
3. Modify the RACF procedure in SYS1.PROCLIB to process the updated RACF parameter library by adding PARM=’OPT=01’ to the EXEC statement. Add the RACFPARM ddname to point to SYS1.PARMLIB to identify the library that contains the RRSF parameters. Example 4-5 shows the RACF procedure in SYS1.PROCLIB.
Example 4-5 The RACF procedure in SYS1.PROCLIB
//RACF PROC
//RACF EXEC PGM=IRRSSM00,REGION=0M,PARM='OPT=01'
//RACFPARM DD DSN=SYS1.PARMLIB,DISP=SHR
4. For these changes to take effect, refresh the RACF subsystem by stopping and restarting the RACF started task using the locally defined RACF subsystem prefix.
Issue the MVS START command, specifying RACF as the procedure name:
S RACF,SUB=MSTR
5. You can check the status of the RRSF environment using the TARGET LIST command, using the locally defined RACF subsystem prefix:
#TARGET LIST
6. You can also check the RACF subsystem using the SET LIST command:
#SET LIST
RACF setup for Kerberos realms
To set up RACF for Kerberos realms:
1. Before you define the local REALM, activate (CLASSACT) and RACLIST the REALM class:
SETROPTS CLASSACT(REALM)
SETROPTS RACLIST(REALM)
2. Activate, if not already active, and RACLIST the PTKTDATA class as follows:
SETROPTS CLASSACT(PTKTDATA)
SETROPTS GENERIC(PTKTDATA)
SETROPTS GENCMD(PTKTDATA)
SETROPTS RACLIST(PTKTDATA)
 
Important: No profile is needed in the PTKTDATA class. The Kerberos server (SKRBKDC) generates a temporary passticket under the covers to change a principal’s password when the kpasswd command is issued.
3. A user must have access to the SKRBKDC application in order to use the kpasswd command to change their password. By using the RACF RDEFINE command, you can define the SKRBKDC application to the RACF APPL class:
RDEFINE APPL SKRBKDC OWNER(SYS1) UACC(READ) +
DATA(‘KERBEROS APPLID’)
 
Tip: Alternately, you can set the Universal Access to NONE and explicitly authorize individual groups or users to the SKRBKDC application.
4. Define your local realm to the REALM class, using the RACF RDEFINE command to define the KERBDFLT profile reflecting the default REALM and policy:
RDEFINE REALM KERBDFLT KERB(KERBNAME(KRB390.IBM.COM) PASSWORD(password) MINTKTFLE(15) DEFTKTFLE(36000) + MAXTKTLFE(86400)UACC=NONE
 
Attention: Our z/OS environment has a domain name of WTSC57.KRB390.IBM.COM and a REALM name of KRB390.IBM.COM
Use the RACF RLIST command to display the KERBDFLT profile in the REALM class:
RLIST REALM KERBDFLT KERB
5. Define any foreign REALMs to the RACF REALM class.
Your local Network Authentication and Privacy Service (Kerberos) server can trust authentications completed by other servers, and can be trusted by other servers, by participating in trust relationships.
To participate in trust relationships, you must define each server as a foreign realm. Then, you can allow users who are authenticated in foreign realms (foreign principals) to access protected resources on your local z/OS system by mapping one or more RACF user IDs to foreign principal names. You do not need to provide foreign principals with the ability to log on to your local z/OS system. You can simply provide mapping to one or more local user IDs so they can gain access privileges for local resources that are under the control of an z/OS application server, such as DB2.
In our example, we defined a Windows® 2000 Realm to the RACF REALM class, so that we can use it later for testing the Kerberos integration between Windows 2000 and the z/OS Network Authentication and Privacy Services using DB2.
The Windows 2000 domain is called pauldeg.krb2000.ibm.com and the REALM is called KRB2000.IBM.COM. We defined the following profiles to set up the trust relationship between the z/OS REALM and the Windows 2000 REALM:
RDEFINE REALM /.../KRB390.IBM.COM/krbtgt/KRB2000.IBM.COM + KERB(PASSWORD(xx)
RDEFINE REALM /.../KRB2000.IBM.COM/krbtgt/KRB390.IBM.COM + KERB(PASSWORD(xx)
 
Attention: You need the password that is defined here later when you define the same trust relationship on the Windows 2000 domain. This password is not associated with any user ID and is not constrained to any SETROPTS rules for passwords.
6. Define Kerberos port 88 for the KDC and port 464 for the password server to your TCP/IP profile to reflect the use of these ports, as shown in Example 4-6.
Example 4-6 Define Kerberos post 88 for the KDC and port 464 for the password server
88 TCP OMVS SAF KERB88 ; Kerberos Server
464 TCP OMVS SAF KERB464 ; Kerberos Server
7. Depending on your installation, you might or might not have started with the protection of TCP/IP ports using the RACF SERVAUTH class. Accordingly, you should authorize the SKRBKDC Started Task Userid to port 88 and 464, using the following commands:
PERMIT EZB.PORTACCESS.SC57.ITCPIP.KERB88 CLASS(SERVUATH) + ID(SKRBKDC) ACCESS(READ)
PERMIT EZB.PORTACCESS.SC57.ITCPIP.KERB464 CLASS(SERVUATH) + ID(SKRBKDC) ACCESS(READ)
The SKRBKDC started task also requires access to the TCP/IP stack itself, using a new profile in the RACF SERVAUTH class:
PERMIT EZB.STACKACCESS.SC57.ITCPIP CLASS(SERVAUTH) ID(SKRBKDC) + ACCESS(READ)
8. You are now ready to start your Kerberos server SKRBKDC. You receive the informational messages shown in Example 4-7.
Example 4-7 Start Kerberos server: Informational messages
S SKRBKDC
$HASP100 SKRBKDC ON STCINRDR
IEF695I START SKRBKDC WITH JOBNAME SKRBKDC IS ASSIGNED TO USER
SKRBKDC , GROUP SKRBGRP
$HASP373 SKRBKDC STARTED EUVF04001I Security server version 2.10, Service
level OW45102.
EUVF04002I Security runtime version 2.10, Service level OW45102.
EUVF04018I Security server initialization complete.
4.13 Define Kerberos local principals
Figure 4-13 Kerberos principals: Local principals
Define Kerberos principals
This section describes how to define Kerberos principals. We distinguish between two types of principals:
•A local principal is a Kerberos user defined to the local REALM.
•A foreign principal is a Kerberos user from another Kerberos REALM.
Local principals
You define local principals as RACF users using the ADDUSER and ALTUSER commands with the new KERB option. This creates a KERB segment for the user. Each local principal must have a RACF password. Therefore, do not use the NOPASSWORD option when defining local principals. You can specify the following information for your local principals:
•KERBNAME: Local principal name.
•MAXTKTLFE: Maximum ticket lifetime for the local principal.
 
Important: Upper and lower case letters are accepted and maintained in the case in which they are entered.
Example 4-8 shows an example of defining a Kerberos principal.
Example 4-8 Defining a Kerberos principal
ALTUSER GRAAFF KERB(KERBNAME('Paul de Graaff'))
 
Restriction: You can define the local principal name that you specify only once. If you try to define it to two RACF user IDs, you receive the following error message:
IRR52165I The value for the KERB segment KERBNAME operand must be unique. Command processing ends.
Generating keys for local principals
Each local principal must have a key registered with the local Network Authentication and Privacy Service (Kerberos) server in order to be recognized as a local principal. The user’s definition as a local principal is not complete until the key is generated. The key is generated from the principal’s RACF user password at the time of the user’s password change. If you want a key to be generated, be sure to use a password change facility that will not result in an expired password that the user must change at next logon. For example, you can use the NOEXPIRED keyword of the ALTUSER command.
A local principal’s key is revoked whenever the user’s RACF user ID is revoked or the RACF password is considered expired. If the user’s key is revoked, the server will reject ticket requests from this user.
You can change a user’s password so that a key can be generated using the ALTUSER command with the NOEXPIRED option, for example:
ALTUSER GRAAFF PASSWORD(new1pw)NOEXPIRED
 
Important: Do not use the NOPASSWORD option on the ALTUSER command.
 
Attention: You must specify a password value so that a key can be generated. All characters of the password are folded to uppercase.
Users can change their own passwords by completing their own definitions as local principals by using any standard RACF password-change facility, such as:
•TSO PASSWORD command (without the ID option)
•TSO logon
•CICS signon
 
Important: The RACF address space must be started for the password change to complete and the key to be generated.
Password change requests from applications that encrypt the password prior to calling RACF do not result in usable keys.
Automatic local principal name mapping
For each local principal that you define on your system using the KERB keyword of the ADDUSER and ALTUSER commands, RACF creates a mapping profile in the KERBLINK class automatically. When you issue the ALTUSER command with the NOKERB keyword or issue a DELUSER for a user with a KERB segment, RACF deletes the KERBLINK profile automatically.
The KERBLINK profile maps the local principal name to the user’s RACF user ID. The name of the KERBLINK profile for a local principal is the principal name specified as the KERBNAME value with the ADDUSER or ALTUSER command. We show the KERBLINK profile for user ID graaff in Example 4-9 as it was defined in Example 4-8 on page 220.
Example 4-9 The KERBLINK profile for user ID graaff
sr mask(P) class(kerblink)
Paul¢de¢Graaff
You can see in the profile Paul¢de¢Graaff that blanks are indeed replaced by the ¢ character. If you list the profile, you notice a little quirk in the RACF command processing where it does not accept mixed-case profile names, as shown in Example 4-10.
Example 4-10 Example with mixed-case profile names
rl KERBLINK Paul¢de¢Graaff
ICH13003I PAUL¢DE¢GRAAFF NOT FOUND
If you do a RLIST *, you see the output shown in Example 4-11.
Example 4-11 Output of RLIST *
RLIST *
CLASS NAME
----- ----
KERBLINK Paul¢de¢Graaff
LEVEL OWNER UNIVERSAL ACCESS YOUR ACCESS WARNING
----- -------- ---------------- ----------- -------
00 GRAAFF NONE NONE NO
INSTALLATION DATA
-----------------
NONE
APPLICATION DATA
----------------
GRAAFF
Example 4-11 shows that the local principal, Paul de Graaff, maps back to RACF user ID GRAAFF.
Considerations for local principal names
The name of the KERBLINK profile contains the local principal name that is mapped. Local principal names can contain imbedded blanks and lower case characters.
Blanks are not permitted as a part of a RACF profile name. Therefore, when building the KERBLINK profile name, as a result of specifying KERBNAME with the ADDUSER or ALTUSER command, RACF command processing will replace each blank with the X'4A' character (which often resolves to the ¢ symbol), as shown in the output from the RLIST KERBLINK * command shown in Example 4-9 on page 221 and in the output from the RACF data base unload utility (IRRDBU00).
 
Restriction: RACF command processing also prevents the X'4A' character from being specified as part of the actual local principal name.
4.14 Define Kerberos foreign principals
Figure 4-14 Kerberos principals: Foreign principals
Kerberos foreign principals
You map foreign principal names to RACF user IDs on your local z/OS system by defining general resource profiles in the KERBLINK class. You can map each principal in a foreign realm to its own user ID on your local z/OS system, or you can map all principals in a foreign realm to the same user ID on your system.
RACF user IDs that map to foreign principals do not need KERB segments. These user IDs are intended to be used only to provide local z/OS identities to associate with access privileges for local resources that are under the control of an z/OS application server, such as DB2.
Each mapping profile in the KERBLINK class is defined and modified using the RDEFINE and RALTER commands. The name of the KERBLINK profile for a foreign principal contains the principal name, fully qualified with the name of the foreign realm. The profile name uses the following format:
.../foreign_realm /[foreign-principal_name ]
If you want to map a unique RACF user ID to each foreign principal, you must specify the foreign realm name and the foreign principal name. If you want to map the same RACF user ID to every foreign principal in the foreign realm, you need only specify the foreign realm name. In each case, you specify the local user ID using the APPLDATA keyword of the RDEFINE or RALTER command.
Example of mapping foreign principal names
In the following example, the users PAUL and VAL have their foreign principal names mapped with individual user IDs on the local z/OS system. All other foreign principals presenting tickets from the KERB2000.IBM.COM REALM are mapped to the KRB2000 user ID on the local z/OS system.
RDEFINE KERBLINK /.../KERB2000.IBM.COM/PAUL APPLDATA('GRAAFF')
RDEFINE KERBLINK /.../KERB2000.IBM.COM/VAL APPLDATA('VALERIA')
RDEFINE KERBLINK /.../KERB2000.IBM.COM/ APPLDATA('KERB2000')
 
Attention: All characters of the foreign realm name and the foreign principal name are folded to uppercase.
4.15 Kerberos user commands
Figure 4-15 Kerberos user commands
Description of the Kerberos commands
The following commands are supplied:
•kinit: Obtains or renews a Kerberos ticket-granting ticket. The KCD options specified in the Kerberos configuration file are used if no ticket options are specified on the kinit command.
•klist: Displays the contents of a Kerberos credentials cache or key table.
•kdestroy: Destroys a Kerberos credentials cache file. To delete a credentials cache, the user must be the owner of the file or must be a root (uid) user.
•keytab: Used to add or delete a key from a key table or to display the entries in a key table.
•kpasswd: Changes the password for a kerberos principal using the password change service.
•kvno: Displays the current key version number for a principal.
•kadmin: Is used to manage entries in the kerberos database. It prompts you to enter one or more subcommands.
To use these commands, you must update your PATH statement in your .profile with the full path name of the directory (/usr/lpp/skrb/bin) containing the Kerberos commands. It also requires updates to the NLSPATH statement to reflect the Kerberos message catalog. Example 4-12 displays the required changes to your .profile.
Example 4-12 Required changes to .profile
# ====================================================
# Start of Kerberos section
# ====================================================
echo "--> Start of Kerberos Additions"
export PATH=$PATH:/usr/lpp/skrb/bin
echo "PATH:" $PATH
#
export NLSPATH=$NLSPATH:/usr/lpp/skrb/lib/nls/msg/%L/%N
echo "NLSPATH:" $NLSPATH
#
Kerberos command examples
This sections that follow lists some examples of Kerberos commands.
The kinit command
The kinit command obtains or renews the Kerberos ticket-granting ticket. The KDC options specified by kdc_default_options in the Kerberos configuration file are used if no ticket options are specified on the kinit command. The kinit command includes several keywords, but we show only the following examples here:
•kinit -s: Obtains a ticket-granting ticket using the current signed-on RACF user ID
•kinit: Obtains a ticket-granting ticket and the principal name is obtained from the credentials cache (if present)
•kinit -k: Obtains a ticket-granting ticket using a key table to obtain the principal information
kinit -s example
To obtain a ticket-granting ticket for a Kerberos principal, you can either use RACF services to obtain the principal associated or use a so-called key table. The kinit -s command obtains a ticket-granting ticket for the current signed-on RACF User ID, as shown in Example 4-13.
Example 4-13 Example of kinit -s to obtain ticket-granting ticket
GRAAFF @ SC57:/u/graaff/kerberos>kinit -s
EUVF06014E Unable to obtain initial credentials.
Status 0x96c73a2d - Service key is not available.
When we issue the kinit -s command for the current signed-on RACF user ID GRAAFF, we receive an error that the service key is not available. When we define the local principal for user ID GRAAFF, a key is not generated for the local principal. When we issue the LU GRAAFF KERB command, no key is generated, as shown in Example 4-14.
Example 4-14 Issuing the LU GRAFF KERB command
LU GRAAFF KERB NORACF
USER=GRAAFF
KERB INFORMATION
----------------
KERBNAME= Paul de Graaff
Keys only get generated when a RACF password change occurs. So after we change the password for the RACF user ID GRAAFF, we receive a key generated, as shown in Example 4-15.
Example 4-15 Generated key for user ID GRAAFF
LU GRAAFF KERB NORACF
USER=GRAAFF
KERB INFORMATION
----------------
KERBNAME= Paul de Graaff
KEY VERSION= 001
We can now try again to get a ticket-granting ticket issued, using the kinit -s command, as shown in Example 4-16.
Example 4-16 Using the kinit -s command to get a ticket-granting ticket
GRAAFF @ SC57:/u/graaff/kerberos>kinit -s
GRAAFF @ SC57:/u/graaff/kerberos>klist
Ticket cache: FILE:/var/skrb/creds/krbcred_a9b31900
Default principal: Paul de [email protected]
Server: krbtgt/[email protected]
Valid 2001/02/26-23:48:16 to 2001/02/27-09:48:16
kinit with no keywords example
Next, we tested the kinit command without specifying any keywords. The kinit command obtains the principal name from the credentials cache. If no credential cache exists, the command fails, as shown in Example 4-17.
Example 4-17 Failure of the kinit command without specifying keywords
GRAAFF @ SC57:/u/graaff>kinit
EUVF06010E Principal name must be specified.
Example 4-18 shows the interaction with the user when issuing the kinit command and a credential cache does exits. You are prompted for a password associated with the local principal. If you are using RACF instead of a key table for storage of local principals, then this is your RACF password associated with your RACF User ID.
Example 4-18 Using the kinit command when a credential cache does exist
GRAAFF @ SC57:/u/graaff>kinit
EUVF06017R Enter password:
GRAAFF @ SC57:/u/graaff>
 
Important: You must enter the password here in uppercase letters. RACF only accepts uppercase passwords.
kinit -k example
We then tested the use of a key table with the kinit command rather then using RACF. For this example, we assume a principal is defined called [email protected]. Example 4-19 shows using a key table with the kinit command, by using the -k keyword.
Example 4-19 Using the kinit -k command
GRAAFF @ SC57:/u/graaff>kinit -k [email protected]
GRAAFF @ SC57:/u/graaff>klist
Ticket cache: FILE:/var/skrb/creds/krbcred_b210de60
Default principal: [email protected]
Server: krbtgt/[email protected]
Valid 2001/06/08-13:39:50 to 2001/06/08-23:39:50
GRAAFF @ SC57:/u/graaff>
 
Note: You must enter the password in uppercase letters.
When using the -k keyword, you do not need to specify the name and location of the key table if you want to use the default key table. The default key table name is obtained from the default_keytab_name configuration file (krb5.conf) entry. The default name is /etc/skrb/krb5.keytab.
 
Tip: You can also change the default key table name using the environment variable KRB5_KTNAME.
The klist command
Using the klist command displays the contents of a Kerberos credentials cache or key table. We show the following examples of using the klist command:
klist Lists the tickets in the credentials cache (the default).
klist -e Displays the encryption type for the session key and the ticket.
klist -f Displays the ticket flags.
klist -k Displays the entries in the keytable.
klist -k -K Displays the encryption key value for each key table entry.
klist example
When you issue the klist command without any keywords, it actually is as though you had issued a klist -c command. Example 4-20 shows the output of a klist command after a ticket-granting ticket is obtained.
Example 4-20 The klist command example
GRAAFF @ SC57:/u/graaff/kerberos>kinit -s
GRAAFF @ SC57:/u/graaff/kerberos>klist
Ticket cache: FILE:/var/skrb/creds/krbcred_a9b31900
Default principal: Paul de [email protected]
Server: krbtgt/[email protected]
Valid 2001/02/26-23:48:16 to 2001/02/27-09:48:16
klist -e example
The klist -e command displays the encryption type for the session key and the ticket, as shown in Example 4-21.
Example 4-21 The klist -e command example
GRAAFF @ SC57:/u/graaff>klist -e
Ticket cache: FILE:/var/skrb/creds/krbcred_b210de60
Default principal: [email protected]
Server: krbtgt/[email protected]
Valid 2001/06/08-13:39:50 to 2001/06/08-23:39:50
Encryption type: DES_CBC_CRC
 
Important: The -e option is valid only when listing a credentials cache.
klist -f example
The klist -f command displays the ticket flags, as shown in Example 4-22.
Example 4-22 The klist -f command example
GRAAFF @ SC57:/u/graaff>klist -f
Ticket cache: FILE:/var/skrb/creds/krbcred_b210de60
Default principal: [email protected]
Server: krbtgt/[email protected]
Valid 2001/06/08-13:39:50 to 2001/06/08-23:39:50
Flags: FIA
In this example, the flags indicate:
F Forwardable ticket
I Initial ticket
A Preauthentication used
 
Important: The -f option is valid only when listing a credentials cache.
klist -k example
The klist -k command lists the entries in a key table, as shown in Example 4-23.
Example 4-23 The klist -k example
GRAAFF @ SC57:/u/graaff>klist -k
Key table: /etc/skrb/krb5.keytab
Key version: 1
klist -k -K example
The klist -k -K command lists the entries in a key table and displays the encryption key value for each key table entry, as shown in Example 4-24.
Example 4-24 The klist -k -K example
GRAAFF @ SC57:/u/graaff>klist -k -K
Key table: /etc/skrb/krb5.keytab
Key version: 1
Key: f1bc4fa49e4975ad
The kdestroy command
The kdestroy command deletes a Kerberos credentials cache file.
The -e option causes the kdestroy command to check all of the credentials cache files in the default cache directory (/etc/skrb/var/creds). Any file that contains only expired tickets that have expired for the time delta are deleted. The time delta is expressed as nwndnhnmns, where:
n Represents a number
w Indicates weeks
d Is days
h Is hours
m Is minutes
s Indicates seconds
The components must be specified in this order, but any component can be omitted (for example, 4h5m represents 4 hours and 5 minutes, and 1w2h represents 1 week and 2 hours). If only a number is specified, the default is hours.
 
Important: To delete a credentials cache, the user must be the owner of the file or must be a root user (uid 0).
Example 4-25 shows an example of the kdestroy command that deletes the credentials cache of principal Paul de Graaff.
Example 4-25 Example of the kdestroy command
GRAAFF @ SC57:/u/graaff>kinit -s
GRAAFF @ SC57:/u/graaff>klist
Ticket cache: FILE:/var/skrb/creds/krbcred_b2118de0
Default principal: Paul de [email protected]
Server: krbtgt/[email protected]
Valid 2001/06/08-14:26:38 to 2001/06/09-00:26:38
GRAAFF @ SC57:/u/graaff>kdestroy
EUVF06034I Credentials cache FILE:/var/skrb/creds/krbcred_b2118de0
destroyed.
The keytab command
The keytab command manages a key table. A key table can be used to define either local or foreign principals. Key tables are traditionally used in UNIX-based environment. Support for key tables here provides compatibility with these environments.
To define the local principal graaff to the default key table, issue the keytab command, as shown in Example 4-26.
Example 4-26 The keytab command example
GRAAFF @ SC57:/u/graaff>keytab add paul -p paul
GRAAFF @ SC57:/u/graaff>keytab list paul
Key table: /etc/skrb/krb5.keytab
Key version: 1
Entry timestamp: 2001/06/08-15:08:12
You can now obtain a ticket-granting ticket using the key table instead of RACF. Next, issue the kinit command to obtain a ticket-granting ticket using the key table, as shown in Example 4-27.
Example 4-27 Using the kinit command to obtain a ticket-granting ticket using the key table
GRAAFF @ SC57:/u/graaff>kinit -k paul
EUVF06014E Unable to obtain initial credentials.
Status 0x96c73a06 - Client principal is not found in security registry.
After you run this command, an error indicates that the client principal is not found in the security registry. So, what really happened here? When you look at the trace of the kinit command, the issue becomes clear, as shown in Example 4-28.
Example 4-28 Trace of the kinit command
....
kdb_racf_get_principal(): No RACF profile for paul
kdc_as_process_request(): AS_REQ: kdb_get_principal() failed for
kdc_as_process_request(): AS_REQ: KDC error 6 processing request from
As shown in the trace output, it states no RACF profile was found for paul. Local Kerberos principals are always defined in RACF, and foreign principals in their respective REALM (KDC). The messages here indicate that the Kerberos server tried to map the local principal to a RACF user ID and could not find a local principal named paul.
The next step is to define a RACF user ID with a KERB segment and a KERBNAME of paul. We change the RACF user ID GRAAFF to reflect the local Kerberos principal paul, as shown in Example 4-29.
Example 4-29 Changing the RACF user ID to GRAAFF
alu graaff kerb(kerbname(graaff) password(xxx) noexpired
We try to execute the kinit -k command again, as shown in Example 4-30.
Example 4-30 Issuing the kinit -k command again
GRAAFF @ SC57:/u/graaff>kinit -k paul
EUVF06016E Password is not correct for [email protected].
The password that we use to add the principal must match the RACF password for the RACF user ID to which it is mapped. So, we have to redefine the local principal in the key table using the correct (RACF) password. To redefine the local principal, delete and add the principal as shown in Example 4-31.
Example 4-31 Redefining the local principal
GRAAFF @ SC57:/u/graaff>keytab delete paul
GRAAFF @ SC57:/u/graaff>keytab add paul -p racfpw
GRAAFF @ SC57:/u/graaff>klist -k
Key table: /etc/skrb/krb5.keytab
Key version: 1
We can now issue the kinit -k paul command again. Example 4-32 shows that we still receive a password error because we added the principal with the correct password, but using lowercase letters.
Example 4-32 Issuing kinit -k paul again
GRAAFF @ SC57:/u/graaff>kinit -k paul
EUVF06016E Password is not correct for [email protected].
Again we need to redefine the principal, as shown in Example 4-31 on page 230, but we now add the (RACF) password in uppercase. We obtain a ticket-granting ticket successfully, as shown in Example 4-33.
Example 4-33 Receiving a ticket-granting ticket successfully
GRAAFF @ SC57:/u/graaff>kinit -k paul
GRAAFF @ SC57:/u/graaff>klist
Ticket cache: FILE:/var/skrb/creds/krbcred_b2a52720
Default principal: [email protected]
 
Server: krbtgt/[email protected]
Valid 2001/06/15-14:22:42 to 2001/06/16-00:22:42
The kadmin command
The kadmin command is used to manage entries in the Kerberos database. It prompts you to enter one or more subcommands. The kadmin command can be used with any Kerberos administration server supporting Version 2 of the Kerberos administration protocol. The command has the following format:
kadmin [-r realm ][-p principal ][-k keytab ][-w password ][-A ][-e ]
Where:
-r realm Specifies the Kerberos administration realm. If this option is not specified, the realm is obtained from the principal name. This option is meaningful only if the administration server supports multiple realms.
-p principal Specifies the administrator principal. If this option is not specified, the string /admin is appended to the principal name obtained from the default credentials cache. If there is no credentials cache, the string /admin is appended to the name obtained from the USER environment variable, or if the USER environment variable is not defined, it is appended to the name obtained from the getpwuid() function. The local realm is used if an explicit realm is not part of the principal name.
The principal name is host or host name unless the -p option is specified. The host name is the primary host name for the local system.
-k keytab Specifies the key table that contains the password for the administrator principal. The user is prompted to enter the password if neither the -k nor the -w option is specified.
-w password Specifies the password for the administrator principal. The user is prompted to enter the password if neither the -k nor the -w option is specified.
-A Specifies that the initial ticket used by the kadmin command does not contain a list of client addresses. If this option is not specified, the ticket contains the local host address list. When an initial ticket contains an address list, it can be used only from one of the addresses in the address list.
-e Echoes each command line to stdout. This is useful when stdout is redirected to a file.
 
Note: Subcommand options start with a minus (-) character and principal attributes start with a plus (+) character or a minus (-) character.
The kadmin command imposes no other restrictions on the characters used in names or passwords, although it is recommended that you do not use any of the EBCDIC variant characters. The Kerberos administration server can impose additional restrictions.
Time units
You can use time units such as dates, that are displayed as day-of-week, month, day-of-month, hour:minute:second, time zone, or year using the local time zone, as specified by the TZ environment variable. Durations are displayed as days-hours:minutes:seconds.
The kadmin command supports a number of date and duration formats and some examples are as follows:
"15 minutes" - "7 days" - "1 month" - "2 hours" - "400000 seconds" - "next year" - "this Monday"
Subcommands
The following subcommand descriptions assume that the administration server is using the standard MIT Kerberos database for the registry. Other database implementations might not support all of the subcommand options and attributes.
Principal-related commands
 
Note: In the subcommands that we describe in this section, name specifies a Kerberos principal
There is a long list of options that you can use in defining a principal, such as the types of tickets that it can use, what services it can provide, what encryption types are supported for this principal, and what pre-authentication steps might be required.
The following subcommands are supported:
•help [subcommand]
The help subcommand displays the command syntax for the specified subcommand. If no subcommand name is specified, the available subcommands are displayed.
•list_principals [expression]
The list_principals (also known as listprincs) subcommand lists all of the principals in the Kerberos database that match the specified search expression. If no search expression is provided, all principals are listed. You must have LIST authority.
•get_principal name
The get_principal (also known as getprinc) subcommand displays information for a single principal entry. You must have GET authority, or the principal entry must be your own entry.
•add_principal [options][attributes] name
The add_principal (also known as addprinc) subcommand adds a new principal entry to the Kerberos database. The options and attributes can be specified before or after the principal name and can be entered in any order. You must have ADD authority.
•delete_principal name
The delete_principal (also known as delprinc) subcommand deletes a principal entry from the Kerberos database. You must have DELETE authority.
•modify_principal [options][attributes] name
The modify_principal (also known as modprinc) subcommand modifies an existing principal entry in the Kerberos database. The options and attributes can be specified before or after the principal name and can be entered in any order. You must have MODIFY authority.
•change_password [-randkey | -pw password] name
The change_password (also known as cpw) subcommand changes the password for a principal. You must have CHANGEPW authority, or the principal entry must be your own entry.
•rename_principal oldname newname
The rename_principal (also known as renprinc) subcommand changes the name of a principal entry in the Kerberos database. You must have both ADD and DELETE authority.
Policy-related commands
 
Note: Policy is associated with a password. It specifies characteristics such as the password lifetime, length, number of character classes that must be present, and number of passwords kept in the password history. Passwords in the password history cannot be reused.
•list_policies [expression]
The list_policies (also known as listpols) subcommand lists all of the policies in the Kerberos database that match the specified search expression. All policies are listed if no search expression is provided. You must have LIST authority.
•get_policy name
The get_policy (also known as getpol) subcommand displays information for a single policy entry. You must have GET authority or the policy must be associated with your own principal entry.
•add_policy [options] name
The add_policy (also known as addpol) subcommand adds a new policy to the Kerberos database. The options can be specified before or after the policy name and can be specified in any order. You must have ADD authority.
•modify_policy [options] name
The modify_policy (also known as modpol) subcommand modifies an existing policy in the Kerberos database. The options can be specified before or after the policy name and can be specified in any order. You must have MODIFY authority.
•delete_policy name
The delete_policy (also known as delpol) subcommand deletes a policy entry from the Kerberos database. You must have DELETE authority.
•add_key [[-keytab|-k] keytab_name] principal_name
The add_key (also known as ktadd) subcommand generates a set of random encryption keys for the named principal and then adds the generated keys to the specified key table. The default key table is used if the -keytab option is not specified. A key table name prefix of FILE is changed to FILE because the add_key subcommand must update the key table.
The kpasswd command
The kpasswd command changes the password for a Kerberos principal using the password change service. You must supply the current password for the principal as well as the new password. The password change server applies any applicable password policy rules to the new password before changing the password. The command is issued as follows:
kpasswd [principal]
The principal option specifies the principal whose password is to be changed. The principal is obtained from the default credentials cache if the principal is not specified on the command line.
 
Note: You cannot change the password for a ticket-granting service principal (krbtgt/realm) using the kpasswd command.
The kvno command
The kvno command displays the current key version number for a principal and is issued as follows:
kvno [principal]
The principal option specifies the principal whose current key version number is to be displayed. The principal is obtained from the default credentials cache if the principal is not specified on the command line.
4.16 Auditing
Figure 4-16 Auditing
Auditing
SMF Type 80 records are created for login requests (Kerberos initial ticket requests). Both success and failure events can be logged as determined by the SKDC_LOGIN_AUDIT environment variable. The event code is 68 and the record includes relocate sections 333 (Kerberos principal name), 334 (request source), and 335 (KDC error code).
The Kerberos principal is stored as a global name (/.../realm-name/principal-name) and not as a Kerberos name (principal-name@realm-name). This is done to avoid code page problems caused by the at-sign variant character. If the request is received through TCP/IP, the request source is the network address (nnn.nnn.nnn.nnn:ppppp). If the request is received through Program Call, the request source is the system user ID of the requester. The KDC error code is a value between 0 and 127.
Figure 4-16 shows the smf records (truncated) generated for the kinit commands issued in Example 4-32 on page 231 and Example 4-33 on page 231. The first record shown in Figure 4-16 indicates an error code of 24, which means that the reauthentication (password) failed.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.226.251.206