Administration Guide

Managing authentication credentials

This section discusses how to obtain, display, and delete authentication credentials and how to change authentication passwords.

When your Kerberos V4 realm is set up to use PSSP authentication servers, the PATH variable for these users should include /usr/kerberos/bin. When AFS authentication servers are used, the PATH variable should include /usr/afsws/bin:/usr/kerberos/bin.

Obtaining DCE authentication credentials for an interactive AIX session

To identify yourself to the security services when you are logged in to an interactive AIX session, use the dce_login or dce_login_noexec command. See the book IBM DCE Version 3.1 for AIX: Administration Commands Reference.

Obtaining Kerberos V4 authentication credentials for an interactive AIX session

This section describes how to identify yourself to the security services and obtain credentials, when you are logged in to AIX as an interactive user.

The first step in using the PSSP Kerberos V4 authentication services is to log in to the Kerberos V4 authentication system. Logging in to the SP Kerberos V4 authentication services is how you obtain a ticket-granting ticket. The ticket-granting ticket permits the client programs you invoke, such as sysctl, to obtain service tickets they can use to certify your identity to the servers with which they communicate.

Logging in to Kerberos V4 authentication services is a separate step from logging in to your AIX system; the Kerberos V4 principal name space is separate from the AIX user name space. The administrator can assign principal names and passwords that are the same as AIX login names and passwords.

With PSSP Kerberos V4 authentication

Use the k4init command to login to the SP Kerberos V4 authentication services. You can either enter the command interactively as needed, or you could add the command to your login script (.login or .profile file). If you use Kerberos V4 authenticated services infrequently, you might prefer the first option. Another alternative for frequent users of Kerberos V4 authenticated management tools is to have the SP system or security administrator set up Kerberos V4 as an authentication method to be invoked automatically at AIX login. See Integrating login for Kerberos V4 with AIX.

Use the k4init command to specify your Kerberos V4 principal identifier as the only argument with no options.

k4init principal-identifier

For the principal identifier, specify your Kerberos V4 user name, followed by a period and the instance, if you have more than one Kerberos V4 identity and the instance you want to use is not null. Append an "at" sign (@) and a realm name if the realm you are logging into is not the local realm. Since the entire SP system is in a single realm, you will probably never need to specify a realm. Examples of this form of k4init are:

k4init joeuser
k4init root.admin
k4init ben@XYZ.ABC.COM

You might also choose to invoke the command without arguments. It responds by prompting for your Kerberos V4 name, but only for the name portion of the fully qualified identifier.

k4init
Kerberos name: ben

A common error is to omit the identifier on the command line and try to enter both name and instance in response to the prompt for the name. The result is:

k4init
Kerberos name: root.admin
2502-003 Bad Kerberos name format

Instead, you can enter the instance separately by specifying the -i flag on the command line and responding to the prompt:

Kerberos instance:

Similarly, the realm qualifier can only be entered as part of the command-line identifier unless you use the optional -r flag.

You can also use the -l option to request a ticket with a lifetime shorter than the maximum allowed for your principal by the database administrator. If you specify this flag, k4init prompts you:

Kerberos ticket lifetime (minutes):

After you enter the k4init command and respond to these optional prompts, the command contacts the Kerberos V4 authentication server to obtain a ticket. If no Kerberos V4 authentication server can be contacted, you are notified of a time-out and the command fails. Reasons for failure could be a missing or invalid configuration file or a networking problem.

When a ticket is obtained, k4init prompts you for your Kerberos V4 password. If you enter it correctly, k4init saves the ticket-granting-ticket in the ticket file specified by your KRBTKFILE environment variable. If this variable is undefined, your ticket is stored in the file /tmp/tktuid, where uid specifies your AIX user identification number.

When the ticket-granting ticket expires, subsequent attempts to be authenticated to use a Kerberos V4-supported service will fail. If the ticket-granting-ticket has expired, use k4init again to obtain a new ticket. There is no automatic renewal of tickets upon their expiration.

When you use k4init, it is valid for all processes running with your AIX user ID. It is not necessary to run this command for each window you open, as long as you have no background processes that require Kerberos V4 authentication. Note, however, that if you run authenticated applications as root in background processes or login under a shared user ID, you can potentially destroy the tickets of someone who logged in prior to you using the shared ID. In those cases you should use the KRBTKFILE environment variable to specify multiple ticket cache files. If you are uncertain of the current ticket cache file, use the k4list command to display the name and content of the file.

With AFS authentication

In most situations, users of your SP system are able to use the same k4init command described previously without regard to which type of authentication servers are being used. The k4init command can always be used whenever a user is logged in to an SP node or the control workstation. When the user is logged in to another |IBM pSeries or RS/6000 node which has been set up as an authenticated services client system, k4init can be used if the user has the SP_NAME environment variable set to the network name of the control workstation in the local realm.

Users who do not have the SP_NAME variable set, or who wish to use more familiar AFS commands, should use the klog.krb command. The following example shows the format of this command:

klog.krb -pr root.admin -li 48:00

When the admin instance is included in the principal identifier, klog.krb responds with a warning message:

Non-null instance (admin) may cause strange behavior.

You can ignore this message, since these principals are not used with the AFS file system.

As with k4init, you can specify a lifetime but in a more reasonable hh:mm format.

Obtaining DCE authentication credentials within scripts

This section describes how a script running not interactively, like from a crontab entry, can establish an identity as an authorized user of SP trusted services or AIX remote commands.

Creating a DCE key file

See "Working with Keytabs and Key Files" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components. See also the dce_login command in the book IBM DCE Version 3.1 for AIX: Administration Commands Reference.

Logging in to DCE from a ksh script

The following is an example of using the key file /home/tom/dcekey to log in as DCE principal tom from within a ksh script:

# Get DCE credentials, if DCE is being used for authentication
nkrb5=$(/bin/dsrvtgt tom /home/tom/dcekey)
if [[ $? ne 0 ]] then
   print "Failed to get DCE credentials"
   exit 1
fi
 
# dsrvtgt produces no output if DCE is not being used for authentication
if [["$nkrb5" != "" ]] then
   okrb5=$KRB5CCNAME
   export KRB5CCNAME=$nkrb5
fi

  ·
  ·
  ·

# Use AIX remote commands or SP trusted services

  ·
  ·
  ·

# Delete the credentials and reset the environment, if necessary
if [[ "$nkrb5" != "" ]] then
   /bin/kdestroy >/dev/null 2>&1
   if [[ "$okrb5" != "" ]] then
      export KRB5CCNAME=$okrb5
   else
      unset KRB5CCNAME
   fi
fi 

Logging in to DCE from a perl script

The following is an example of using the key file /home/tom/dcekey to log in as DCE principal tom from within a perl script:

/* Get DCE credentials, if DCE authentication is being used */
chop($nkrb5= `/bin/dsrvtgt tom /home/tom/dcekey `);
if($? > 0) {
   print (STDERR "Failed to get DCE credentials\n");
   exit(1);
}
/* dsrvtgt produces no output if DCE is not being used for authentication */
if ("$nkrb5" ne "") {
   $okrb5 = $ENV('KRB5CCNAME');
   $ENV{'KRB5CCNAME'} = $nkrb5;
}

  ·
  ·
  ·

/* Use AIX remote commands or trusted services */

  ·
  ·
  ·

/* Delete DCE credentials and reset environment if necessary */
if ("$nkrb5" ne "") {
    `/bin/kdestroy > /dev/null `;
   if ("$okrb5" ne "") {
      $ENV('KRB5CCNAME') = $okrb5;
   } else {
      delete $ENV{'KRB5CCNAME'};
   }
} 

Logging in to DCE from a Tcl script

The following is an example of using the key file /home/tom/dcekey to log in as DCE principal tom from within a Tcl script:

# Get DCE credentials, if DCE is being used for authentication
set rc [catch {exec /bin/dsrvtgt dce-user-name dce-key-file} nkrb5]
if { $rc != 0 } {
   puts stderr "$nkrb5"
   error "Failed to get DCE credentials"
}
 
# dsrvtgt produces no output if DCE is not being used for authentication
if {"$nkrb5" != "" } {
   set k5env [catch {set okrb5 $env(KRB5CCNAME)}]
   set env(KRB5CCNAME) $nkrb5
}

  ·
  ·
  ·

# Use AIX remote commands or SP trusted services

  ·
  ·
  ·

# Delete the credentials and reset the environment, if necessary
if {"$nkrb5" != "" } {
   catch {exec /bin/kdestroy}
   if {"$okrb5" != ""} {
      set env(KRB5CCNAME) $okrb5
   } else {
      unset env(KRB5CCNAME)
   }
} 

Obtaining Kerberos V4 authentication credentials within scripts

This section describes how a script running noninteractively, such as from a crontab entry, can establish an identity as an authorized user of SP trusted services or AIX remote commands.

Creating a Kerberos V4 key file

There are several steps involved in creating a Kerberos V4 key file:

• The Kerberos V4 administrator must create a principal which has an instance part (k4user.k4instance@k4realm).
• The root user on the Kerberos V4 authentication server host must use the ext_srvtab command to extract the user's key from the database and create the key file named k4instance-new-srvtab in the current directory:

  ext_srvtab -n k4instance

• The root user must change the file ownership to the user, using the chown command, and move or copy it to k4keyfilepath where k4user expects to find it.

Logging in to Kerberos V4 from a ksh script

The following is an example of how to log in to Kerberos V4 from a ksh script, where k4keyfilepath is /home/tom/k4key, k4user is tom, k4instance is operator, and the user principal is tom.operator:

# Get Kerberos V4 credentials, if Kerberos V4 is being used for authentication
okrb4=$KRBTKFILE
export KRBTKFILE=/tmp/tkt$$
/bin/ksrvtgt tom operator /home/tom/key
if [[ $? -ne 0 ]] then
   print "Failed to get Kerberos V4 credentials"
   exit 1
fi

  ·
  ·
  ·

# Use AIX remote commands or trusted services

  ·
  ·
  ·

# Delete the credentials and reset the environment, if necessary
/bin/k4destroy 1>/dev/null
if [[ "$okrb4" != "" ]]
then KRBTKFILE=$okrb4
else unset KRBTKFILE
fi 

Logging in to Kerberos V4 from a perl script

The following is an example of how to log in to Kerberos V4 from a perl script, where k4keyfilepath is /home/tom/k4key, k4user is tom, k4instance is operator, and the user principal is tom.operator:

/* Get Kerberos V4 credentials, if Kerberos V4 authentication is being used */
$okrb4 = $ENV('KRBTKFILE');
$ENV{'KRB5CCNAME'} = "/tmp/tkt$$";
 `/bin/ksrvtgt tom operator /home/tom/key `;
if($? > 0) {
   print (STDERR "Failed to get Kerberos V4 credentials\n");
   exit(1);
}

  ·
  ·
  ·

/* Use AIX remote commands or SP trusted services */

  ·
  ·
  ·

/* Delete Kerberos V4 credentials and reset environment if necessary*/
 `/bin/k4destroy 1>/dev/null `;
if ("$okrb4" != "") {
   $ENV('KRBTKFILE') = $okrb4;
} else {
   delete $ENV{'KRBTKFILE'};
} 

Logging in to Kerberos V4 from a Tcl script

The following is an example of how to log in to Kerberos V4 from a tcl script, where k4keyfilepath is /home/tom/k4key, k4user is tom, k4instance is operator, and the user principal is tom.operator

# Get Kerberos V4 credentials, if Kerberos V4 is being used for authentication
set k4env [catch {set okrb4 $env(KRBTKFILE)}]
set env(KRBTKFILE) "/tmp/tktvsd.[pid]"
set rc [catch {exec /bin/ksrvtgt tom operator /home/tom/k4key} nkrb4]
if { $rc != 0 } {
   puts stderr "$nkrb4"
   error "Failed to get Kerberos V4 credentials"
}
set nkrb4 [catch {exec /bin/k4list -t}]

  ·
  ·
  ·

# Use AIX remote commands or trusted services

  ·
  ·
  ·

# Delete the credentials and reset the environment if necessary
if { $nkrb4 == 0 } {
   catch {exec /bin/k4destroy}
}
if { $k4env == 0 } {
   set env(KRBTKFILE) $okrb4
} else {
   unset env(KRBTKFILE)
} 

Displaying your DCE credentials

Use the klist command. See the book IBM DCE Version 3.1 for AIX: Administration Commands Reference.

Displaying your Kerberos V4 credentials

This section describes how to see your Kerberos V4 authentication credentials.

With PSSP authentication

Use the k4list command to display a list of currently held authentication tickets and their expiration time. The output would appear like the following, for example, if the user ben enters the k4list command after using the k4init command followed by any of the remote command services on four other hosts:

Ticket file:    /tmp/tkt12763
Principal:  ben@XYZ.ABC.COM
 
  Issued           Expires          Principal
Aug 12 16:26:11  Sep 11 16:26:11  krbtgt.XYZ.ABC.COM@XYZ.ABC.COM
Aug 12 16:45:15  Sep 11 16:45:15  rcmd.spcwkst@XYZ.ABC.COM
Aug 15 09:02:42  Sep 14 09:02:42  rcmd.spnode3@XYZ.ABC.COM
Aug 15 09:02:43  Sep 14 09:02:43  rcmd.spnode5@XYZ.ABC.COM
Aug 15 09:02:43  Sep 14 09:02:43  rcmd.spnode6@XYZ.ABC.COM

With AFS authentication

You may also use the k4list command to display tickets obtained from an AFS authentication server. The format of the output is the same as shown above, except that a service ticket for the "afs" service will appear, if you used the AFS klog.krb command to identify yourself. This additional service ticket is not used by SP authentication services. As an AFS user, you may prefer to use the tokens.krb command to display your tickets. Its output will appear like:

Tokens held by the Cache Manager:
 
User's (AFS ID 12763) tokens for afs@afs.abc.com [Expires May 31 03:24]
User ben's tokens for krbtgt.AFS.ABC.COM@afs.abc.com [Expires Jun 25 19:49]
User ben's tokens for rcmd.wksta2@afs.abc.com [Expires Jun 25 19:50]
   --End of list--

Notice that tokens.klog shows the AFS cell name in place of the Kerberos V4 realm name.

Deleting your DCE credentials

Use the kdestroy command. See the book IBM DCE Version 3.1 for AIX: Administration Commands Reference.

Deleting your Kerberos V4 credentials

This section describes how to delete your Kerberos V4 credentials.

With PSSP authentication

Use the k4destroy command to destroy Kerberos V4 tickets in the current ticket cache file. Depending on your local security policy, you may want to destroy your tickets whenever you end your AIX login session. k4destroy overwrites the ticket cache file with nulls before removing the file, so storage containing credentials cannot be reused. When you enter this command, the system will respond:

Tickets destroyed.

If the ticket cache file does not exist, you will get the response:

No tickets destroyed.

With AFS authentication

You may also use the k4destroy command to delete tickets obtained from an AFS authentication server and stored in a ticket cache file. The responses are the same as shown previously. k4destroy will not remove the token held by the AFS Cache Manager, however, that was also obtained if you used klog.krb instead of k4init to obtain your initial ticket.

The AFS unlog command will remove your tokens held by the AFS Cache Manager, but will not remove tickets from the Kerberos V4 ticket cache file.

Changing your DCE authentication password

If you are using integrated login, use the passwd command. Otherwise, use the dce_login command. See the book IBM DCE Version 3.1 for AIX: Administration Commands Reference.

Changing your Kerberos V4 authentication password

With PSSP authentication

To change your password, use the kpasswd command:

1. Enter the kpasswd command:
2. At the prompt, enter your old password
3. At the prompt, enter your new password
4. At the prompt, reenter your new password

For example:

kpasswd
Old password for ben:
New Password for ben:
Verifying, please re-enter New Password for ben:
Password changed.

With AFS authentication

To change a password for a principal in AFS:

1. Enter the AFS kpasswd command. Be sure you have the directory for the AFS commands, /usr/afsws/bin ahead of the directory path for the Kerberos V4 command, /usr/kerberos/bin in your search order, or specify the full path name:
2. At the prompt, enter your old AFS password
3. At the prompt, enter your new password
4. At the prompt, reenter your new password to verify

For example:

kpasswd
Changing password for 'ben' in cell 'abc.com'
Old password:
New password (RETURN to abort):
Retype new password:
Password changed.