Introduction

Now that we have setup working DAS servers and several DAS clients, we will now take a look at user administration. How do we add users, delete users, set user policies, and modify users? This section will explain the process in a step-by-step fashion.

First, let us define a DAS user. A user of our Distributed Authentication System is a global account consisting of unique UID, a GID (possibly unique), GECOS data, a preferred shell, and a home directory. The username is unique throughout the system, and the UID must be unique throughout the system. Furthermore, the DAS user is also a Kerberos principal. A DAS user can be authenticated by any software or hardware that can use Kerberos authentication. In essence, the DAS user is NIS information combined with a Kerberos principal.

The DAS user should be able to login to any DAS client host from the console or via SSH. The person who owns the DAS account should be able to use all of the lab's shared resources with the same username, password, group membership, and UID. This has the added benefit of facilitating the use of network file systems like NFS and OpenAFS.

Assumptions

These instructions assume the following:

Step-by-step Instructions

Step 1: Create Your Policies

One of the first things you must do is setup a network-wide policy on UIDs, GIDs, and usernames. In our case, here is our policy:

We also need to have a policy on the length and complexity of passwords, as well as how many old passwords to keep in each user's password history. Password history restrictions keep users from cycling between the same passwords. Let's go ahead and create a default password policy via kadmin or kadmin.local on DAS-M:

[root@das-m root]# kadmin.local
Authenticating as principal root/admin@KERB.ORG with password.
kadmin.local:  addpol -minlength 7 -minclasses 2 -history 5 default
kadmin.local:  listpols
default
kadmin.local:  getpol default
Policy: default
Maximum password life: 0
Minimum password life: 0
Minimum password length: 7
Minimum number of password character classes: 2
Number of old keys kept: 5
Reference count: 0

The example above stipulates a minimum of 7 characters in a password, at least two different classes of characters (like letters and numbers), and a password history of 5. All new users (principals) that are added from now on will comply with the default policy, unless they are explicitly created with a different policy.

Step 2: Adding a new DAS user into NIS

The DAS-M server is also the NIS master. This is where new users, hosts, and groups are added. Once they are added, the NIS maps are updated and automatically replicated to NIS slave servers. We will add our first user, a certain Mr. Bostick, as an example. Mr. Bostick will have a UID of 6002, and be a member of two groups: bostick (GID 6002), and the already-created labuser (GID 50,000) group. We will add the new user with standard user management commands:

[root@das-m root]# id bostick
id: bostick: No such user
[root@das-m root]# grep 6002 /etc/passwd
[root@das-m root]# useradd -u 6002 -G labuser -M bostick
[root@das-m root]# chfn bostick
Changing finger information for bostick.
Name []: Charles Bostick
Office []: Lab 104
Office Phone []: 3423-3423 x1497
Home Phone []:
 
Finger information changed.
[root@das-m root]# finger bostick
Login: bostick                          Name: Charles Bostick
Directory: /home/bostick                Shell: /bin/bash
Office: Lab 104, 3423-3423 x1497
Never logged in.
No mail.
No Plan.

Note that we first checked for an existing user and UID. We did NOT create a home directory (-M) on DAS-M because regular users are not allowed on the system. We then used the chfn utility to populate the GECOS field. Finally, we checked our work with the finger command. You may also want to look at /etc/passwd and /etc/group to check what has just been added to those very important text files.

Now, we need to actually update the NIS maps. We do this with the make command as follows:

[root@das-m root]# make -C /var/yp
make: Entering directory `/var/yp'
gmake[1]: Entering directory `/var/yp/KERB.ORG'
gmake[1]: `ypservers' is up to date.
gmake[1]: Leaving directory `/var/yp/KERB.ORG'
gmake[1]: Entering directory `/var/yp/KERB.ORG'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
gmake[1]: Leaving directory `/var/yp/KERB.ORG'
make: Leaving directory `/var/yp'

If you don't like having to remember and type in the make -C /var/yp command, you can easily make an alias or bash script to deal with this. I named mine nisupdate, and placed it in /usr/local/sbin. Here is what it looks like:

#!/bin/bash
# This is essentially an alias for the make -C /var/yp command used to update the NIS maps
                                                                                                                                                             
/usr/bin/make -C /var/yp

Don't forget to modify the permissions so that it is an executable:

[root@das-m sbin]# chmod 0700 /usr/local/sbin/nisupdate

The simplest way to check the NIS maps on both DAS servers is like this:

[root@das-m root]# ypcat passwd
kitty:x:6000:50000:Kit Cat,Lab 104,1234-1234 x1457,(216)485-3383:/home/kitty:/bin/bash
bostick:x:6002:6002:Charles Bostick,Lab 104,3423-3423 x1497:/home/bostick:/bin/bash

[root@das-m root]# ypcat group
labuser:x:50000:bostick
bostick:x:6002:

[root@das-m root]# ypcat -h das-s.kerb.org passwd
kitty:x:6000:50000:Kit Cat,Lab 104,1234-1234 x1457,(216)485-3383:/home/kitty:/bin/bash
bostick:x:6002:6002:Charles Bostick,Lab 104,3423-3423 x1497:/home/bostick:/bin/bash

[root@das-m root]# ypcat -h das-s.kerb.org group

labuser:x:50000:bostick
bostick:x:6002:

You can see that our new entries have been added to the NIS maps.

Step 3: Adding the Kerberos Principal for our new user

All we have accomplished so far is to add the user information portion of our DAS user into NIS. We must now add a Kerberos principal. Adding a principal and assigning an initial password is very simple. Make sure that you use the same name that you just added into NIS. Once again, you can use kadmin or kadmin.local:

[root@das-m root]# kadmin.local
kadmin.local:  addprinc -expire "5/31/2009" bostick
NOTICE: no policy specified for bostick@KERB.ORG; assigning "default"
Enter password for principal "bostick@KERB.ORG":
Re-enter password for principal "bostick@KERB.ORG":
Principal "bostick@KERB.ORG" created.
kadmin.local:  getprinc bostick
Principal: bostick@KERB.ORG
Expiration date: Sun May 31 00:00:00 CST 2009
Last password change: Tue Nov 04 15:43:20 CST 2003
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Tue Nov 04 15:43:20 CST 2003 (root/admin@KERB.ORG)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: default

The account expiration date is an optional argument. There are many other options, which you can read in the kadmin manpage.

Step 4: Test the new user account

You should test the new DAS user. On one of your DAS client machines, login as the new DAS user and make sure that you can gain access, and that you have been given a Kerberos ticket. Here is an example:

[root@das-m home]# ssh -l bostick labdemo2.kerb.org
bostick@labdemo2.kerb.org's password:
 
######################
#                    #
#      NV - 1        #
#                    #
######################
 
 
[bostick@labdemo2 bostick]$ id
uid=6002(bostick) gid=6002(bostick) groups=6002(bostick),50000(labuser)
[bostick@labdemo2 bostick]$ whoami
bostick
[bostick@labdemo2 bostick]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_6002_T2wbrv
Default principal: bostick@KERB.ORG
 
Valid starting     Expires            Service principal
11/04/03 16:05:50  11/05/03 02:05:49  krbtgt/KERB.ORG@KERB.ORG
        renew until 11/04/03 16:05:50, Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
 
 
Kerberos 4 ticket cache: /tmp/tkt6002
klist: You have no tickets cached

[bostick@labdemo2 bostick]$ pwd
/home/bostick
[bostick@labdemo2 bostick]$ ls -ald /home/bostick
drwxrwx---    3 bostick  bostick      4096 Nov  4 15:55 /home/bostick

Another useful option to the klist command is -f . This shows the specific flags associated with the tickets.

Note:   The first time you login, you must be at the console for the makehomedir PAM module to automatically create the home directory and copy the skeleton files. ***

Scriptable kadmin commands:

In order to facilitate bash scripting in the creation of new user accounts, you can also invoke kadmin from the command line instead of the interactive kadmin prompt. Here is how we would have created a user from the bash prompt:

[root@das-m home]# kadmin.local -q "addprinc -expire "5/31/2009" bostick"
Authenticating as principal root/admin@KERB.ORG with password.
NOTICE: no policy specified for bostick@KERB.ORG; assigning "default"
Enter password for principal "bostick@KERB.ORG":
Re-enter password for principal "bostick@KERB.ORG":
Principal "bostick@KERB.ORG" created.
[root@das-m home]# kadmin.local -q "getprinc bostick"
Authenticating as principal root/admin@KERB.ORG with password.
Principal: bostick@KERB.ORG
Expiration date: Sun May 31 00:00:00 CST 2009
Last password change: Tue Nov 04 16:12:24 CST 2003
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Tue Nov 04 16:12:24 CST 2003 (root/admin@KERB.ORG)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 1, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt
Attributes:
Policy: default

Now, go back and repeat steps 2-4 for all of the users you would like to add.


Common User Administration Procedures

Change a user's password:

[root@das-m root]# kadmin.local
Authenticating as principal root/admin@KERB.ORG with password.
kadmin.local:  cpw bostick
Enter password for principal "bostick":
Re-enter password for principal "bostick":
Password for "bostick@KERB.ORG" changed.

Lock and unlock a user's account:

This prevents a user from authenticating (and thereby logging in), but does not delete the Kerberos principal, password, or NIS data:

kadmin.local:  modprinc -expire now bostick
Principal "bostick@KERB.ORG" modified.

When user bostick tries to login, he will get an error message stating "Account expired. Please contact your system administrator." To unlock the user account, do this:

kadmin.local:  modprinc -expire never bostick
Principal "bostick@KERB.ORG" modified.

You could also give a specific expiration date in the future, instead of using "never".

Modify an account:

This task has two elements: modification of the Kerberos principal, and modification of NIS information for the user. In the case of modifying NIS information, you would simply use any existing group, user, or password management utility ranging from usermod and chfn to Webmin. In order to modify Kerberos principals, we use the modprinc subcommand of the kadmin utility. The following shows the syntax and a simple modification, the removal of a password policy from user bostick's account:

kadmin.local:  modprinc
usage: modify_principal [options] principal
        options are:
                [-expire expdate] [-pwexpire pwexpdate] [-maxlife maxtixlife]
                [-kvno kvno] [-policy policy] [-clearpolicy]
                [-maxrenewlife maxrenewlife] [{+|-}attribute]
        attributes are:
                allow_postdated allow_forwardable allow_tgs_req allow_renewable
                allow_proxiable allow_dup_skey allow_tix requires_preauth
                requires_hwauth needchange allow_svr password_changing_service

kadmin.local:  modprinc -clearpolicy bostick
Principal "bostick@KERB.ORG" modified.

Note:   Remember, if you want to add, modify, or delete entries from the "hosts" NIS map, just edit the /var/yp/hosts file. Then you can run the "nisupdate" script (or make -C /var/yp).

Delete an Account

In order to delete an account from the Distributed Authentication System, you will need to delete the Kerberos principal, then delete the NIS data. Here is how we would do that:

[root@das-m root]# kadmin.local
Authenticating as principal root/admin@KERB.ORG with password.
kadmin.local:  delprinc bostick
Are you sure you want to delete the principal "bostick@KERB.ORG"? (yes/no): yes
Principal "bostick@KERB.ORG" deleted.
Make sure that you have removed this principal from all ACLs before reusing.
kadmin.local:  quit

[root@das-m root]# userdel bostick
[root@das-m root]# make -C /var/yp
make: Entering directory `/var/yp'
gmake[1]: Entering directory `/var/yp/KERB.ORG'
gmake[1]: `ypservers' is up to date.
gmake[1]: Leaving directory `/var/yp/KERB.ORG'
gmake[1]: Entering directory `/var/yp/KERB.ORG'
Updating passwd.byname...
Updating passwd.byuid...
Updating group.byname...
Updating group.bygid...
gmake[1]: Leaving directory `/var/yp/KERB.ORG'
make: Leaving directory `/var/yp'

Now that the DAS account is gone, there is still one minor detail: any DAS client that Mr. Bostick had a home directory on still has his directory and his data. When it is listed, it now shows up with nothing but a UID. It is best to delete these local accounts. This is a good reason not to re-use UIDs and GIDs when assigning new accounts, because you may be giving a new user access to old account data that he should not have. Perhaps one way to deal with this would be to run a script on the DAS clients that periodically checks for "orphaned" directories in /home and /tmp. See the deletion example below:

[root@labdemo2 home]# ls -ld bostick
drwxrwx---    3 6002     6002         4096 Nov  4 15:55 bostick
[root@labdemo2 home]# rm -rf /home/bostick

Using kadmin Remotely

On GNU/Linux DAS clients using the MIT Kerberos packages, you can administer the Kerb5 principals' database via the kadmin program, which establishes a secure connection from the DAS Client to the DAS Master Server. Logged into the DAS client, you should be able to run the kadmin command. If you are not logged in as root, you can still use it by entering the full path: /usr/kerberos/sbin/kadmin . You will also have to specify one of the administrative principals that you created with the -p switch. Example:

[root@labdemo2 RPM]# kadmin -p super/admin
Authenticating as principal super/admin with password.
Enter password:
kadmin:  

You can use multiple administrative accounts, and those accounts can have different privileges. The privileges are based on the /var/kerberos/krb5kdc/kadm5.acl file. In our system, there are two administrative users, "super/admin" and "user/admin". The two accounts have different privileges.


Conclusion

User administration is fairly straightforward. NIS info is added or deleted from the DAS-M NIS master server with regular tools, then updated with make -C /var/yp. Kerberos principal administration is done with kadmin or kadmin.local. Backups of old NIS source files and Kerberos databases are kept in this directory:

/home/Backups

It should be a fairly simple exercise to write bash or perl scripts for adding and deleting users. This would make user management a simpler process for administrators, especially in keeping UID and GID values unique and sane.

NOTES: Kerberos policies can also specify password aging. This is not being addressed right now because some Linux distributions' PAM configs do not support password aging well or at all. Also, the current versions of sshd shipping with the tested systems does not support changing your password upon password expiration. This will be revisited, as password aging is a long-term requirement of the system.


References

MIT Kerberos Admin Guide
man useradd
man userdel
man usermod
man chfn
man kadmin