Administration Guide

Managing authentication information

This section includes the following tasks for managing user's authenticated identities:

Adding users
Integrating login with AIX
Displaying information about users
Changing user passwords
Changing user ticket expiration
Removing users

Adding users for DCE

See "Creating a New User", "Creating and Maintaining Principals, Groups, and Organizations", and "Creating and Maintaining Accounts" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components.

Adding users for Kerberos V4

You can add general user principals and Kerberos V4 authentication administrators.

Adding principals and assigning initial passwords

With PSSP Kerberos V4 authentication

To add a principal and set the initial password in the Kerberos V4 authentication database, a database administrator with an admin principal that is listed in the admin_acl.add file can use kadmin or add_principal.

To use kadmin:

Enter the kadmin command:
```
kadmin
```
A welcome message and explanation of how to ask for help are displayed.
Enter the add_new_key or ank subcommand:
```
ank name[.instance]
```
The only required argument for the subcommand is the principal's name.
At the prompt, enter your admin password
At the prompt, enter the principal's new password
At the prompt, reenter the principal's new password.

add_principal operates like kadmin, but allows an arbitrarily large number of principals to be added at one time. Whereas kadmin always prompts for your administrative password, add_principal will use tickets you have already obtained as login-name.admin. This makes add_principal suitable for use in scripts or background processes where a password cannot be provided interactively.

Create an ASCII file containing a list of principals and their initial passwords. Make sure it is readable only by you.
Enter the add_principal command.
```
add_principal filename
```
Immediately remove the file containing the initial passwords.

The following script fragment shows one way to add a user to the database without interactively editing a file, and keeping the initial password on disk for a minimal amount of time:

#( OMASK=$(umask); umask 077; INITIALPW=changeme$RANDOM; \
   print "johndoe $INITIALPW">/tmp/Addp$$; \
   /usr/kerberos/bin/add_principal /tmp/Addp$$; \
   /bin/rm /tmp/Addp$$; umask $OMASK; \
   print "johndoe's initial password is $INITIALPW"; )
johndoe's initial password is changeme28745
#

On the system which is the primary Kerberos V4 authentication server, the root user can use the kdb_edit command to add principals. The steps are:

Enter the command, which operates interactively, prompting for requests.
```
kdb_edit -n
```
Reply to the prompt for a principal name by entering the user name of the new principal and then the instance.
```
Principal name: joeuser
Instance:
```
Reply y to confirm that you want to add the principal.
Enter the initial password, when prompted.
Reenter the password, when prompted.
Accept the default expiration date by pressing Enter or type an alternate date in the format shown by the prompt.
Accept the default maximum ticket lifetime value or enter another.
Press enter when prompted for attributes.
The command will respond Edit OK and begin prompting for another principal to add. Repeat the same sequence or press enter to terminate the command.

For a complete example and more information, refer to kdb_edit in the book PSSP: Command and Technical Reference.

You can use the mkkp command to add Kerberos V4 principals to the Kerberos V4 authentication database instead of kdb_edit.

When logged into a system that is a Kerberos V4 authentication server, the root user can run the mkkp command directly. Additionally, any users who are Kerberos V4 database administrators listed in the /var/kerberos/database/admin_acl.add file can invoke this command remotely through a Sysctl procedure of the same name. The administrator need not be logged in on the server host to run mkkp through Sysctl, but must have a Kerberos V4 ticket for that admin principal (name.admin).

Like kdb_edit (and unlike the kadmin command), mkkp can set attributes other than the password. Because it is not interactive mkkp cannot set an initial password. To complete that step so users can login with the new principals using k4init, use the cpw subcommand of kadmin.

In the following example, these steps are used to add two new principals and then assign passwords to enable Kerberos V4 logins. The Kerberos V4 server host name is control2. The user has previously obtained a ticket as name.admin, for whom an entry exists in the admin_acl.add file:

$sysctl -h control2 mkkp -e 1998-06-30 jack jill
 
$kadmin -m
 
Welcome to the Kerberos Administration Program, version 2
Type "help" if you need it.
admin: cpw jack
Admin password:
New password for jack:
Verifying, please re-enter New password for jack:
Password changed for jack.
admin: cpw jill
New password for jill:
Verifying, please re-enter New password for jill:
Password changed for jill.
 
admin: quit
 
Cleaning up and exiting.
 
$

With AFS authentication

To add a principal and set a password in an AFS authentication database:

Enter the kas command:
```
kas create -name user [-cell cellname]
```
At the prompt, enter your AFS password
At the prompt, enter the principal's new password
At the prompt, reenter the principal's new password to verify

Adding a Kerberos V4 authentication administrator

With PSSP Kerberos V4 authentication

To perform the tasks involved in administering SP authentication services, the system administrator must be authorized to do so. The administrator must be a user with an admin instance whose name appears on one of the Kerberos V4 authentication administration access control lists (ACLs).

For example, to perform Kerberos V4 authentication administration, the administrator gail must have a principal gail.admin in the Kerberos V4 authentication database. In addition, gail.admin must be in the access control list file for the task she wants to perform. There are three ACL files:

/var/kerberos/database/admin_acl.add: The list of principals authorized to add entries to the Kerberos V4 authentication database
/var/kerberos/database/admin_acl.get: The list of principals authorized to retrieve entries from the Kerberos V4 authentication database
/var/kerberos/database/admin_acl.mod: The list of principals authorized to modify entries in the Kerberos V4 authentication database

Adding a Kerberos V4 authentication database administrator requires two steps:

Adding the principal with the admin instance, as described previously.
Adding the principal identifier to one or more of the ACL files, which must be done by the root user on the primary database system.

With AFS authentication

AFS administration does not use an admin instance or ACL files. You, an AFS administrator, can authorize another AFS user to perform administrative tasks by assigning it the admin attribute:

Follow the steps described above to add the user, if not already defined.

Enter the kas command:

kas setfields -name user -flags admin [-cell cell]

At the prompt, enter your AFS password

Integrating login for DCE with AIX

You can limit the impact of SP security features on nonroot users by eliminating their having to log in separately to DCE in order to perform routine tasks. AIX provides software which integrates its login process with that of DCE, if you choose to use it. IBM suggests you do integrate login if you plan on submitting parallel jobs with DCE and the AIX and DCE user ids are different.

See "AIX/DCE Security Integration" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components

Integrating login for Kerberos V4 with AIX

The system administrator can make using the authenticated services easier for nonroot users by setting up their user accounts so that Kerberos V4 credentials are obtained whenever they log in to the system. Kerberos V4 login cannot take the place of AIX login, but you can automate the process. To set up Kerberos V4 login to run automatically when the user logs in to AIX, do the following:

Add a stanza to the /etc/security/login.cfg file that names a program that will perform the required Kinit processing on the user's behalf. The name of the method (shown in the following example as KERBEROS) can be anything you want. The rest of the stanza should be entered exactly as shown:
```
KERBEROS:
   program = "/usr/bin/ksh /usr/ssp/lpp/kerberos/etc/Kinit"
```
Use SMIT to update either the auth1 or auth2 attribute in the user account for each user you want to use this capability. Add this method after the default SYSTEM method in the auth1 attribute, if you want to require the user to obtain Kerberos V4 credentials in order to successfully login to the system. Specify this method separately in the auth2 attribute if you want to allow (but not require) the user to obtain Kerberos V4 credentials at AIX login. The Kerberos V4-principal must be the user's AIX login name, optionally followed by a period and an instance (for example, foo or foo.admin). Note the placement of the comma (,) and the semicolon (;) in this syntax.
The following is an example of an auth1 attribute for AIX user foo. When foo logs in, the k4init foo command is executed after the AIX password for principal foo. If k4init fails, foo is not logged into the system.
```
auth1 = "SYSTEM,KERBEROS;foo"
```
The following is an example of an auth2 attribute for AIX user bar. When bar logs in, the k4init bar.admin command is executed after the AIX password is validated. The user is prompted for the Kerberos V4 password for bar.admin. In this case, if k4init fails, bar remains logged into the AIX system, but has no Kerberos V4 credentials.
```
auth2 = "KERBEROS;bar.admin"
```

Displaying information about users for DCE

See "Showing User Information" in the book IBM DCE 3.1 for AIX: Administration Guide-Core Components.

Displaying information about users for Kerberos V4

This involves the following:

Listing principals in the Kerberos V4 authentication database.
Displaying information about principals.

Listing principals in the Kerberos V4 authentication database

With PSSP Kerberos V4 authentication

Use the lskp command to list all or some principals in the local Kerberos V4 authentication database. Information displayed for each principal includes the name and instance, the maximum ticket lifetime, the key version number, and the expiration date (local time on the server).

The command allows you to select principals to list in several different ways:

The entire Kerberos V4 authentication database
Individual entries by name
Entries with a specific name
Entries with a specific instance
Client (user) principals
Service principals
Principals pre-defined by Kerberos V4

The following example lists all principals who are Kerberos V4 administrators plus all instances of the rcmd service principal, used by the SP remote commands and the Sysctl facility:

#lskp .admin rcmd.
 
mary.admin tkt-life: 30d key-vers: 3 expires: 2000-12-31 23:59
root.admin tkt-life: 30d key-vers: 5 expires: 2004-05-31 23:59
rcmd.cwsta tkt-life: Unlimited key-vers: 1 expires: 2037-12-31 23:59
rcmd.node1 tkt-life: Unlimited key-vers: 1 expires: 2037-12-31 23:59
rcmd.node2 tkt-life: Unlimited key-vers: 1 expires: 2037-12-31 23:59
rcmd.node3 tkt-life: Unlimited key-vers: 1 expires: 2037-12-31 23:59
 
#

When logged into a system that is a Kerberos V4 authentication server, the root user can run the lskp command directly. Additionally, any users who are Kerberos V4 database administrators listed in the /var/kerberos/database/admin_acl.get file can invoke this command remotely through a Sysctl procedure of the same name. The administrator need not be logged in on the server host to run lskp through Sysctl, but must have a Kerberos V4 ticket for that admin principal (name.admin).

In the following example, control2 is the Kerberos V4 server host name. The user has previously obtained a ticket as name.admin, for whom an entry exists in the admin_acl.get file:

$sysctl -h control2 lskp default
 
default tkt-life: 30d key-vers: 1 expires: 2037-12-31 23:59
 
$

For more information, see lskp in the book PSSP: Command and Technical Reference.

With AFS authentication

To list the authentication database information, an AFS administrator uses the kas list command. It lists all entries in the database. For example (other entries have similar format):

$kas list -l -admin_user afsadm
 
Administrator's (afsadm) Password:
User data for afsadm (ADMIN)
   key (0) cksum is 1479418564, last cpw: no date
   entry never expires. Max ticket lifetime 720.00 hours.
   last mod on Fri Jun 28 09:12:56 1996 by afsadm
User data for joseph
   key (0) cksum is 1852746310, last cpw: Mon Mar 25 14:45:00 1996
   entry never expires. Max ticket lifetime 720.00 hours.
   last mod on Fri Jun 28 09:15:09 1996 by afsadm
...
 
$

Displaying information about principals

With PSSP Kerberos V4 authentication

There are two ways for to examine information about principals. The kadmin command offers any administrator listed in the admin_acl.get file access from any network-connected system running PSSP Kerberos V4 authentication services. The root user on the primary Kerberos V4 authentication database system can also directly examine the database content by viewing the database backup file in /var/kerberos/database/slavesave.

Using kadmin, for example:

kadmin
Welcome to the Kerberos Administration Program, version 2
Type "help" if you need it.
admin: get ben
Admin password:
Info in Database for ben.:
   Max Life: 255   Exp Date: Fri Dec 31 23:59:00 1999
 
   Attribs:  00  key: 0 0
admin: quit
Cleaning up and exiting

Using the database backup file:

grep "^rcmd node3sw" /var/kerberos/database/slavesave
rcmd node3sw 255 1 2 0 a49bf286 d45c6560 200001010459 199503301502 root admin

The fields in each entry are:

The principal's name
The principal's instance
The maximum ticket lifetime
The key version of the master key used to encrypt the entry.
The key version of the principal's secret key.
The two halves of the encrypted private key.
The expiration date (in Universal Coordinated Time) as YYYYMMDDHHMM
The date the entry was created or modified
The name and instance of the administrator who made the last update

With AFS authentication

To display the database information for a user of AFS, an AFS administrator uses the kas examine command. For example:

kas ex -na ben -admin_user afsadm
Administrator's (afsadm) Password:
 
User data for ben
  key (0) cksum is 1004957312, last cpw: Mon May 22 10:12:50 1995
  password will never expire.
  An unlimited number of unsuccessful authentications is permitted.
  entry never expires.  Max ticket lifetime 25.00 hours.
  last mod on Mon May 22 10:12:50 1995 by afsadm

Changing user passwords for DCE

If you are using integrated login, see "Changing Passwords" in the "AIX/DCE Security Integration" chapter of the book IBM DCE 3.1 for AIX: Administration Guide-Core Components. Otherwise, see "Modifying Accounts" in that book.

Changing user passwords for Kerberos V4

To change a password for a principal in the Kerberos V4 authentication database, a PSSP Kerberos V4 authentication database administrator can use either the kpasswd command or the kadmin program's change_password subcommand. You can issue these commands from any system running PSSP Kerberos V4 authentication services and do not require a prior k4init.

To use the kpasswd command:

Enter the kpasswd command with the name of the principal whose password is being changed:
```
kpasswd -n name
```
At the prompt, enter the old password
At the prompt, enter the new password
At the prompt, reenter the new password

To use the kadmin program:

Enter the kadmin command:
```
kadmin
```
A welcome message and explanation of how to ask for help are displayed.
Enter the change_password or cpw subcommand with the name of the principal whose password is being changed:
```
cpw name
```
The only required argument for the subcommand is the principal's name.
At the prompt, enter your admin password
At the prompt, enter the principal's new password
At the prompt, reenter the principal's new password

To change your own admin instance password, you can use either the kpasswd command or the kadmin program's change_admin_password subcommand.

To use the kpasswd command:

Enter the kpasswd command with your admin instance name:
```
kpasswd -n name -i admin
```
where name is usually replaced with root.
At the prompt, enter your old admin password
At the prompt, enter your new admin password
At the prompt, reenter your new admin password

To use the kadmin program:

Enter the kadmin command:
```
kadmin
```
A welcome message and explanation of how to ask for help are displayed.
Enter the change_admin_password or cap subcommand:
```
cap
```
At the prompt, enter your old admin password
At the prompt, enter your new admin password
At the prompt, reenter your new admin password

Changing user ticket expiration for DCE

In addition to changing the password, you might want to change either the expiration date of the principal or its maximum ticket lifetime, though these are not as likely to be necessary. If DCE is to be used with parallel jobs run under LoadLeveler and Parallel Environment, the ticket lifetime needs to be long enough to allow for the expected longest running job to complete.

See "Setting Ticket Lifetimes" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components.

Changing user ticket expiration for Kerberos V4

In addition to changing the password, you might want to change either the expiration date of the principal or its maximum ticket lifetime, though these are not as likely to be necessary.

With PSSP Kerberos V4 authentication

To change the ticket expiration, the root user on the primary Kerberos V4 authentication database system must use the kdb_edit command, just as when adding new principals locally. Instead of not finding the specified principal, the command finds it already exists, and prompts for changes to all its attributes, starting with the password, followed by the expiration date and maximum ticket lifetime.

The following example shows the use of the kdb_edit command to change a user principal's maximum ticket lifetime from the default value (30 days) to approximately 7 days:

#/usr/kerberos/etc/kdb_edit -n
Opening database...
Previous or default values are in [brackets] ,
enter return to leave the same, or new value.
 
Principal name: johndoe
Instance:
 
Principal: johndoe, Instance: , kdc_key_ver: 1
Change password [n] ?
Expiration date (enter yyyy-mm-dd) [ 1996-09-01 ] ?
Max ticket lifetime [ 255 ] ? 171
Attributes [ 0 ] ?
Edit O.K.
Principal name:
#

Use the chkp command to change the maximum ticket lifetime and expiration date for Kerberos V4 principals in the Kerberos V4 authentication database.

When logged into a system that is a Kerberos V4 authentication server, the root user can run the chkp command directly. Additionally, any users who are Kerberos V4 database administrators listed in the /var/kerberos/database/admin_acl.mod file can invoke this command remotely through a Sysctl procedure of the same name. The administrator need not be logged in on the server host to run chkp through Sysctl, but must have a Kerberos V4 ticket for that admin principal (name.admin).

In the following example, chkp is used by root to set the expiration date to the end of the year 2000 and the lifetime to approximately two weeks for several existing principals:

#chkp -e 2000-12-31 -l 181 joeuser joe.admin harry.admin user12
 
#

In the following example, the maximum ticket lifetime for new users (those added subsequently) is set to approximately a week. control2 is the Kerberos V4 server host name. The user has previously obtained a ticket as name.admin, for whom an entry exists in the admin_acl.mod file:

$sysctl -h control2
 
Sysctl (Version 1.1) on control2.abc.com
sysctl> chkp -l 170 default
sysctl> lskp default
default tkt-life: 7d+08:50 key-vers: 1 expires: 2037-12-31 23:59
sysctl> quit
 
$

For more information, see chkp in the book PSSP: Command and Technical Reference.

With AFS authentication

To change the attributes of AFS user principals, use the kas setfields command. For example, to change the maximum ticket lifetime to two days:

kas setfields -name ben -lifetime 48:00 -admin_user afsadm
administrator's (afsadm) Password:

Removing users for DCE

See "Deleting a User" in the book IBM DCE Version 3.1 for AIX: Administration Guide-Core Components.

Removing users for Kerberos V4

With PSSP Kerberos V4 authentication

Use the rmkp command to remove Kerberos V4 principals from the Kerberos V4 authentication database.

When logged into a system that is a Kerberos V4 authentication server, the root user can run the rmkp command directly. Additionally, any users who are Kerberos V4 database administrators listed in the /var/kerberos/database/admin_acl.add file can invoke this command remotely through a Sysctl procedure of the same name. The administrator need not be logged in on the server host to run rmkp through Sysctl, but must have a Kerberos V4 ticket for that admin principal (name.admin).

Normally, this command requires you to confirm your intention to remove each principal as it is processed. An option is provided (-n) to allow the command to suppress prompting and run non-interactively. Running rmkp through Sysctl requires non-interactive execution; and doing so forces that option to be applied. When running rmkp interactively, the root user can select multiple principals by name or instance using the operand notation name. or .instance as for the lskp command.

Removed entries are preserved in an ASCII text file, in the format produced by the kdb_util dump command. If a principal must be recovered after having been removed, the line in that file containing its entry can be appended to a current database backup file (see Backing up and restoring Kerberos V4 authentication information) to be restored using kdb_util load. The following example shows how rmkp could be used by root to remove obsolete entries after the host name on the control workstation has been changed from cwksta to cwksta2:

#rmkp -v .cwksta
 
Confirm removal of principal hardmon.cwksta? (y or n): y
hardmon.cwksta was removed
Confirm removal of principal rcmd.cwksta? (y or n): y
rcmd.cwksta was removed
Removed entries were saved in /var/kerberos/database/rmkp.save.3036
 
#

In the following example rmkp is used to remove two principals. control2 is the Kerberos V4 server host name. The user has previously obtained a ticket as name.admin, for whom an entry exists in the admin_acl.add file:

$sysctl -h control2 rmkp -v pauline frank
 
pauline was removed
frank was removed
Removed entries were saved in /var/kerberos/database/rmkp.save.18365
 
$

With AFS authentication

An AFS administrator can delete principals directly by using the kas delete command. For example:

kas delete -name ben -admin_user afsadm
Administrator's (afsadm) Password:

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]