User information is held in two places, the standard UNIX user and group files, and the Kerberos authentication system.
To perform most of the administrative actions given here, you will need
sudo access, although changing passwords can be done with
Kerberos administration access.
First create the user in the normal Debian way, except without a password
(because this will be handled by Kerberos later). If the user is an affiliate
of Project Colo, rather than a paying member, put the sponsoring user in the
other field.
bacam@kerouac:~$sudo adduser --disabled-password mrauthtestPassword for bacam@PROJECTCOLO.ORG.UK: Adding user mrauthtest... Adding new group mrauthtest (1007). Adding new user mrauthtest (1007) with group mrauthtest. Creating home directory /home/mrauthtest. Copying files from /etc/skel Changing the user information for mrauthtest Enter the new value, or press return for the default Full Name []:Authus TestusRoom Number []: Work Phone []: Home Phone []: Other []:Sponsored by bacamIs the information correct? [y/n]y
Next you should add the user to the appropriate groups:
bacam@kerouac:~$sudo usermod -G mrauthtest,users,affiliates mrauthtestPassword for bacam@PROJECTCOLO.ORG.UK:
Finally add the user to the Kerberos database. Note that you need to authenticate yourself to Kerberos in an administrative capacity (although this only needs to be done once, if you are doing multiple operations).
bacam@kerouac:~$kinit bacam/adminbacam/admin@PROJECTCOLO.ORG.UK's Password: bacam@kerouac:~$/usr/sbin/kadminkadmin>add mrauthtestMax ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes []: mrauthtest@PROJECTCOLO.ORG.UK's Password: Verifying password - mrauthtest@PROJECTCOLO.ORG.UK's Password: kadmin>quit
The normal UNIX chfn and chsh commands can be
invoked using sudo, and passwords can be changed using the
passwd user subcommand in
/usr/sbin/kadmin.
It is often desriable for a user not to have shell access. For example,
someone who only collects mail by IMAPS should not have shell access in order
to reduce our exposure to risk. Note that this is not a mechanism for
disabling a user. You can disable shell access by changing the
user's shell to /bin/false:
bacam@kerouac:~$sudo chsh mrauthtestPassword for bacam@PROJECTCOLO.ORG.UK: Changing the login shell for mrauthtest Enter the new value, or press return for the default Login Shell [/bin/bash]: /bin/false
Should the user attempt to log then, the authentication will succeed, but the session end immediately. Note that procmail filters (and so spamassassin) and cron can still be used. You can reenable shell access by changing the user's shell back.
If you need to perform some actions on behalf of the user, you can get a login shell as that user:
bacam@kerouac:~$sudo su - -s /bin/bash mrauthtestPassword for bacam@PROJECTCOLO.ORG.UK: mrauthtest@kerouac:~$
Care should be taken when removing a user to ensure all the related files
are removed or have their owner changed (lest they end up owned by the next
user added). In the example below we remove their crontab file, home
directory, user, group and Kerberos database entry, but this is not intended
as an exhustive list. (For example, you may have to remove a mail spool file,
if something found its way there.) It may also be worth considering the
--remove-all-files and --backup options for
deluser.
bacam@kerouac:~$ sudo crontab -r -u mrauthtest Password for bacam@PROJECTCOLO.ORG.UK: bacam@kerouac:~$ kinit bacam/admin bacam/admin@PROJECTCOLO.ORG.UK's Password: bacam@kerouac:~$ /usr/sbin/kadmin kadmin> delete mrauthtest kadmin> quit bacam@kerouac:~$ sudo deluser --remove-home mrauthtest Looking for files to backup/remove... Removing files... Removing user mrauthtest... done. bacam@kerouac:~$ sudo delgroup mrauthtest Removing group mrauthtest... done.