openafs/doc/html/AdminGuide/auagd018.htm
Derrick Brashear d7da1acc31 initial-html-documentation-20010606
pull in all documentation from IBM
2001-06-06 19:09:07 +00:00

1392 lines
78 KiB
HTML

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 4//EN">
<HTML><HEAD>
<TITLE>Administration Guide</TITLE>
<!-- Begin Header Records ========================================== -->
<!-- /tmp/idwt3570/auagd000.scr converted by idb2h R4.2 (359) ID -->
<!-- Workbench Version (AIX) on 2 Oct 2000 at 11:42:14 -->
<META HTTP-EQUIV="updated" CONTENT="Mon, 02 Oct 2000 11:42:13">
<META HTTP-EQUIV="review" CONTENT="Tue, 02 Oct 2001 11:42:13">
<META HTTP-EQUIV="expires" CONTENT="Wed, 02 Oct 2002 11:42:13">
</HEAD><BODY>
<!-- (C) IBM Corporation 2000. All Rights Reserved -->
<BODY bgcolor="ffffff">
<!-- End Header Records ============================================ -->
<A NAME="Top_Of_Page"></A>
<H1>Administration Guide</H1>
<HR><P ALIGN="center"> <A HREF="../index.htm"><IMG SRC="../books.gif" BORDER="0" ALT="[Return to Library]"></A> <A HREF="auagd002.htm#ToC"><IMG SRC="../toc.gif" BORDER="0" ALT="[Contents]"></A> <A HREF="auagd017.htm"><IMG SRC="../prev.gif" BORDER="0" ALT="[Previous Topic]"></A> <A HREF="#Bot_Of_Page"><IMG SRC="../bot.gif" BORDER="0" ALT="[Bottom of Topic]"></A> <A HREF="auagd019.htm"><IMG SRC="../next.gif" BORDER="0" ALT="[Next Topic]"></A> <A HREF="auagd026.htm#HDRINDEX"><IMG SRC="../index.gif" BORDER="0" ALT="[Index]"></A> <P>
<P>
<A NAME="IDX7736"></A>
<HR><H1><A NAME="HDRWQ491" HREF="auagd002.htm#ToC_572">Administering User Accounts</A></H1>
<P>This chapter explains how to create and maintain user
accounts in your cell.
<P>The preferred method for creating user accounts is the <B>uss</B>
program, which enables you to create multiple accounts with a single
command. See <A HREF="auagd017.htm#HDRWQ449">Creating and Deleting User Accounts with the uss Command Suite</A>. If you prefer to create each account
component individually, follow the instructions in <A HREF="#HDRWQ502">Creating AFS User Accounts</A>.
<HR><H2><A NAME="HDRWQ492" HREF="auagd002.htm#ToC_573">Summary of Instructions</A></H2>
<P>This chapter explains how to perform the following tasks by
using the indicated commands:
<BR>
<TABLE WIDTH="100%">
<TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Create Protection Database entry
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>pts createuser</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Create Authentication Database entry
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>kas create</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Create volume
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>vos create</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Mount volume
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>fs mkmount</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Create entry on ACL
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>fs setacl</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Examine Protection Database entry
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>pts examine</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Change directory ownership
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>/etc/chown</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Limit failed authentication attempts
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>kas setfields</B> with <B>-attempts</B> and
<B>-locktime</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Unlock Authentication Database entry
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>kas unlock</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Set password lifetime
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>kas setfields</B> with <B>-pwexpires</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Prohibit password reuse
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>kas setfields</B> with <B>-reuse</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Change AFS password
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>kas setpassword</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">List groups owned by user
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>pts listowned</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Rename Protection Database entry
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>pts rename</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Delete Authentication Database entry
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>kas delete</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Rename volume
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>vos rename</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Remove mount point
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>fs rmmount</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Delete Protection Database entry
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>pts delete</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">List volume location
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>vos listvldb</B>
</TD></TR><TR>
<TD ALIGN="LEFT" VALIGN="TOP" WIDTH="57%">Remove volume
</TD><TD ALIGN="LEFT" VALIGN="TOP" WIDTH="43%"><B>vos remove</B>
</TD></TR></TABLE>
<P>
<A NAME="IDX7737"></A>
<HR><H2><A NAME="HDRWQ494" HREF="auagd002.htm#ToC_574">The Components of an AFS User Account</A></H2>
<P>The differences between AFS and the UNIX file system imply
that a complete AFS user account is not the same as a UNIX user
account. The following list describes the components of an AFS
account. The same information appears in a corresponding section of <A HREF="auagd017.htm#HDRWQ449">Creating and Deleting User Accounts with the uss Command Suite</A>, but is repeated here for your convenience.
<UL>
<P><LI>A <I>Protection Database entry</I> defines the username (the name
provided when authenticating with AFS), and maps it to an AFS user ID (AFS
UID), a number that the AFS servers use internally when referencing
users. The Protection Database also tracks the groups to which the user
belongs. For details, see <A HREF="auagd019.htm#HDRWQ531">Administering the Protection Database</A>.
<P><LI>An <I>Authentication Database entry</I> records the user's AFS
password in a scrambled form suitable for use as an encryption key.
<P><LI>A home <I>volume</I> stores all the files in the user's home
directory together on a single partition of a file server machine. The
volume has an associated <VAR>quota</VAR> that limits its size. For a
complete discussion of volumes, see <A HREF="auagd010.htm#HDRWQ174">Managing Volumes</A>.
<P><LI>A <I>mount point</I> makes the contents of the user's volume
visible and accessible in the AFS filespace, and acts as the user's home
directory. For more details about mount points, see <A HREF="auagd010.htm#HDRWQ183">About Mounting Volumes</A>.
<P><LI>Full access permissions on the home directory's <I>access control
list (ACL)</I> and ownership of the directory (as displayed by the UNIX
<B>ls -ld</B> command) enable the user to manage his or her files.
For details on AFS file protection, see <A HREF="auagd020.htm#HDRWQ562">Managing Access Control Lists</A>.
<P><LI>A <I>local password file entry</I> (in the <B>/etc/passwd</B> file
or equivalent) of each AFS client machine enables the user to log in and
access AFS files through the Cache Manager. A subsequent section in
this chapter further discusses local password file entries.
<P><LI>Other optional <I>configuration files</I> make the account more
convenient to use. Such files help the user log in and log out more
easily, receive electronic mail, print, and so on.
</UL>
<A NAME="IDX7738"></A>
<A NAME="IDX7739"></A>
<HR><H2><A NAME="HDRWQ495" HREF="auagd002.htm#ToC_575">Creating Local Password File Entries</A></H2>
<P>To obtain authenticated access to a cell's AFS
filespace, a user must not only have a valid AFS token, but also an entry in
the local password file (<B>/etc/passwd</B> or equivalent) of the machine
whose Cache Manager is representing the user. This section discusses
why it is important for the user's AFS UID to match to the UNIX UID
listed in the local password file, and describes the appropriate value to put
in the file's password field.
<P>One reason to use <B>uss</B> commands is that they enable you to
generate local password file entries automatically as part of account
creation. See <A HREF="auagd017.htm#HDRWQ458">Creating a Common Source Password File</A>.
<P>Information similar to the information in this section appears in a
corresponding section of <A HREF="auagd017.htm#HDRWQ449">Creating and Deleting User Accounts with the uss Command Suite</A>, but is repeated here for your convenience
<P><H3><A NAME="HDRWQ496" HREF="auagd002.htm#ToC_576">Assigning AFS and UNIX UIDs that Match</A></H3>
<P>A user account is easiest to administer and use if the AFS
user ID number (AFS UID) and UNIX UID match. All instructions in the
AFS documentation assume that they do.
<P>The most basic reason to make AFS and UNIX UIDs the same is so that the
owner name reported by the UNIX <B>ls -l</B> and <B>ls -ld</B>
commands makes sense for AFS files and directories. Following standard
UNIX practice, the File Server records a number rather than a username in an
AFS file or directory's owner field: the owner's AFS
UID. When you issue the <B>ls -l</B> command, it translates the UID
to a username according to the mapping in the local password file, not the AFS
Protection Database. If the AFS and UNIX UIDs do not match, the <B>ls
-l</B> command reports an unexpected (and incorrect) owner. The
output can even vary on different client machines if their local password
files map the same UNIX UID to different names.
<P>Follow the recommendations in the indicated sections to make AFS and UNIX
UIDs match when creating accounts for various types of users:
<UL>
<P><LI>If creating an AFS account for a user who already has a UNIX UID, see <A HREF="#HDRWQ499">Making UNIX and AFS UIDs Match</A>.
<P><LI>If some users in your cell have existing UNIX accounts but the user for
whom you are creating an AFS account does not, then it is best to allow the
Protection Server to allocate an AFS UID automatically. To avoid
overlap of AFS UIDs with existing UNIX UIDs, set the Protection
Database's <TT>max user id</TT> counter higher than the largest UNIX
UID, using the instructions in <A HREF="auagd019.htm#HDRWQ560">Displaying and Setting the AFS UID and GID Counters</A>.
<P><LI>If none of your users have existing UNIX accounts, allow the Protection
Server to allocate AFS UIDs automatically, starting either at its default or
at the value you have set for the <TT>max user id</TT> counter.
</UL>
<A NAME="IDX7740"></A>
<A NAME="IDX7741"></A>
<P><H3><A NAME="HDRWQ497" HREF="auagd002.htm#ToC_577">Specifying Passwords in the Local Password File</A></H3>
<P>Authenticating with AFS is easiest for your users if you
install and configure an AFS-modified login utility, which logs a user into
the local file system and obtains an AFS token in one step. In this
case, the local password file no longer controls a user's ability to
login in most circumstances, because the AFS-modified login utility does not
consult the local password file if the user provides the correct AFS
password. You can nonetheless use a password file entry's password
field (usually, the second field) in the following ways to control login and
authentication:
<UL>
<P><LI>To prevent both local login and AFS authentication, place an asterisk ( *
) in the field. This is useful mainly in emergencies, when you want to
prevent a certain user from logging into the machine.
<P><LI>To prevent login to the local file system if the user does not provide the
correct AFS password, place a character string of any length other than the
standard thirteen characters in the field. This is appropriate if you
want to allow only people with local AFS accounts to log into to your
machines. A single <B>X</B> or other character is the most easily
recognizable way to do this.
<P><LI>To enable a user to log into the local file system even after providing an
incorrect AFS password, record a standard UNIX encrypted password in the field
by issuing the standard UNIX password-setting command (<B>passwd</B> or
equivalent).
</UL>
<P>If you do not use an AFS-modified login utility, you must place a standard
UNIX password in the local password file of every client machine the user will
use. The user logs into the local file system only, and then must issue
the <B>klog</B> command to authenticate with AFS. It is simplest if
the passwords in the local password file and the Authentication Database are
the same, but this is not required.
<A NAME="IDX7742"></A>
<A NAME="IDX7743"></A>
<HR><H2><A NAME="HDRWQ498" HREF="auagd002.htm#ToC_578">Converting Existing UNIX Accounts</A></H2>
<P>This section discusses the three main issues you need to
consider if your cell has existing UNIX accounts that you wish to convert to
AFS accounts.
<P><H3><A NAME="HDRWQ499" HREF="auagd002.htm#ToC_579">Making UNIX and AFS UIDs Match</A></H3>
<P>As previously mentioned, AFS users must have an entry in the
local password file on every client machine from which they access the AFS
filespace as an authenticated user. Both administration and use are
much simpler if the UNIX UID and AFS UID match. When converting
existing UNIX accounts, you have two alternatives:
<UL>
<P><LI>Make the AFS UIDs match the existing UNIX UIDs. In this case, you
need to assign the AFS UID yourself by including the <B>-id</B> argument
to the <B>pts createuser</B> command as you create the AFS account.
<P>
<P>Because you are retaining the user's UNIX UID, you do not need to
alter the UID in the local password file entry. However, if you are
using an AFS-modified login utility, you possibly need to change the password
field in the entry. For a discussion of how the value in the password
field affects login with an AFS-modified login utility, see <A HREF="#HDRWQ497">Specifying Passwords in the Local Password File</A>.
<P>If now or in the future you need to create AFS accounts for users who do
not have an existing UNIX UID, then you must guarantee that new AFS UIDs do
not conflict with any existing UNIX UIDs. The simplest way is to set
the <TT>max user id</TT> counter in the Protection Database to a value
higher than the largest existing UNIX UID. See <A HREF="auagd019.htm#HDRWQ560">Displaying and Setting the AFS UID and GID Counters</A>.
<P><LI>Change the existing UNIX UIDs to match the new AFS UIDs that the
Protection Server assigns automatically.
<P>Allow the Protection Server to allocate the AFS UIDs automatically as you
create AFS accounts. You must then alter the user's entry in the
local password file on every client machine to include the new UID.
<P>There is one drawback to changing the UNIX UID: any files and
directories that the user owned in the local file system before becoming an
AFS user still have the former UID in their owner field. If you want
the <B>ls -l</B> and <B>ls -ld</B> commands to display the correct
owner, you must use the <B>chown</B> command to change the value to the
user's new UID, whether you are leaving the file in the local file system
or moving it to AFS. See <A HREF="#HDRWQ501">Moving Local Files into AFS</A>.
</UL>
<P><H3><A NAME="HDRWQ500" HREF="auagd002.htm#ToC_580">Setting the Password Field Appropriately</A></H3>
<P>Existing UNIX accounts already have an entry in the local
password file, probably with a (scrambled) password in the password
field. You possibly need to change the value in the field, depending on
the type of login utility you use:
<UL>
<P><LI>If the login utility is not modified for use with AFS, the actual password
must appear (in scrambled form) in the local password file entry.
<P><LI>If the login utility is modified for use with AFS, choose one of the
values discussed in <A HREF="#HDRWQ497">Specifying Passwords in the Local Password File</A>.
</UL>
<P><H3><A NAME="HDRWQ501" HREF="auagd002.htm#ToC_581">Moving Local Files into AFS</A></H3>
<P>New AFS users with existing UNIX accounts probably already
own files and directories stored in a machine's local file system, and it
usually makes sense to transfer them into the new home volume. The
easiest method is to move them onto the local disk of an AFS client machine,
and then use the UNIX <B>mv</B> command to transfer them into the
user's new AFS home directory.
<P>As you move files and directories into AFS, keep in mind that the meaning
of their mode bits changes. AFS ignores the second and third sets of
mode bits (group and other), and does not use the first set (the owner bits)
directly, but only in conjunction with entries on the ACL (for details, see <A HREF="auagd020.htm#HDRWQ580">How AFS Interprets the UNIX Mode Bits</A>). Be sure that the ACL protects the file or directory
at least as securely as the mode bits.
<P>If you have chosen to change a user's UNIX UID to match a new AFS UID,
you must change the ownership of UNIX files and directories as well.
Only members of the <B>system:administrators</B> group can issue the
<B>chown</B> command on files and directories once they reside in
AFS.
<HR><H2><A NAME="HDRWQ502" HREF="auagd002.htm#ToC_582">Creating AFS User Accounts</A></H2>
<P>There are two methods for creating user accounts. The
preferred method--using the <B>uss</B> commands--enables you to
create multiple accounts with a single command. It uses a template to
define standard values for the account components that are the same for each
user (such as quota), but provide differing values for more variable
components (such as username). See <A HREF="auagd017.htm#HDRWQ449">Creating and Deleting User Accounts with the uss Command Suite</A>.
<P>The second method involves issuing a separate command to create each
component of the account. It is best suited to creation of one account
at a time, since some of the commands can create only one instance of the
relevant component. To review the function of each component, see <A HREF="#HDRWQ494">The Components of an AFS User Account</A>.
<P>Use the following instructions to create any of the three types of user
account, which differ in their levels of functionality. For a
description of the types, see <A HREF="auagd007.htm#HDRWQ57">Configuring AFS User Accounts</A>.
<UL>
<P><LI>To create an authentication-only account, perform Step <A HREF="#LIWQ504">1</A> through Step <A HREF="#LIWQ507">4</A> and also Step <A HREF="#LIWQ514">14</A>. This type of
account consists only of entries in the Authentication Database and Protection
Database.
<P><LI>To create a basic account, perform Step <A HREF="#LIWQ504">1</A> through Step <A HREF="#LIWQ510">8</A> and Step <A HREF="#LIWQ512">11</A> through Step <A HREF="#LIWQ514">14</A>.
In addition to Authentication Database and Protection Database entries, this
type of account includes a volume mounted at the home directory with owner and
ACL set appropriately.
<P><LI>To create a full account, perform all steps in the following
instructions. This type of account includes configuration files for
basic functions such as logging in, printing, and mail delivery, making it
more convenient and useful. For a discussion of some useful types of
configuration files, see <A HREF="auagd007.htm#HDRWQ60">Creating Standard Files in New AFS Accounts</A>.
</UL>
<A NAME="IDX7744"></A>
<A NAME="IDX7745"></A>
<A NAME="IDX7746"></A>
<A NAME="IDX7747"></A>
<A NAME="IDX7748"></A>
<A NAME="IDX7749"></A>
<A NAME="IDX7750"></A>
<A NAME="IDX7751"></A>
<A NAME="IDX7752"></A>
<A NAME="IDX7753"></A>
<P><H3><A NAME="HDRWQ503" HREF="auagd002.htm#ToC_583">To create one user account with individual commands</A></H3>
<OL TYPE=1>
<P><LI><A NAME="LIWQ504"></A>Decide on the value to assign to each of the following account
components. If you are creating an authentication-only account, you
need to pick only a username, AFS UID, and initial password.
<UL>
<P><LI>The username. By convention, the names of many components of the
user account incorporate this name. For a discussion of restrictions
and suggested naming schemes, see <A HREF="auagd007.htm#HDRWQ58">Choosing Usernames and Naming Other Account Components</A>.
<P><LI>The AFS UID, if you want to assign a specific one. It is generally
best to have the Protection Server allocate one instead, except when you are
creating an AFS account for a user who already has an existing UNIX
account. In that case, migrating the user's files into AFS is
simplest if you set the AFS UID to match the existing UNIX UID. See <A HREF="#HDRWQ498">Converting Existing UNIX Accounts</A>.
<P><LI>The initial password. Advise the user to change this at the first
login, using the password changing instructions in the <I>IBM AFS User
Guide</I>.
<P><LI>The name of the user's home volume. The conventional name is
<B>user.</B><VAR>username</VAR> (for example,
<B>user.smith</B>).
<P><LI>The volume's site (disk partition on a file server machine).
Some cells designate certain machines or partitions for user volumes only, or
it possibly makes sense to place the volume on the emptiest partition that
meets your other criteria. To display the size and available space on a
partition, use the <B>vos partinfo</B> command, which is fully described
in <A HREF="auagd010.htm#HDRWQ185">Creating Read/write Volumes</A>.
<P><LI>The name of the user's home directory (the mount point for the home
volume). The conventional location is a directory (or one of a set of
directories) directly under the cell directory, such as
<B>/afs/</B><VAR>cellname</VAR><B>/usr</B>. For suggestions on
how to avoid the slowed directory lookup that can result from having large
numbers of user home directories in a single <B>usr</B> directory, see <A HREF="auagd017.htm#HDRWQ472">Evenly Distributing User Home Directories with the G Instruction</A>.
<P><LI>The volume's space quota. Include the <B>-maxquota</B>
argument to the <B>vos create</B> command, or accept the default quota of
5000 KB.
<P><LI>The ACL on the home directory. By default, the ACL on every new
volume grants all seven permissions to the
<B>system:administrators</B> group. After volume creation,
use the <B>fs setacl</B> command to remove the entry if desired, and to
grant all seven permissions to the user.
</UL>
<P><LI><A NAME="LIWQ505"></A>Authenticate as an AFS identity with all of the following
privileges. In the conventional configuration, the <B>admin</B>
user account has them, or you possibly have a personal administrative
account. (To increase cell security, it is best to create special
privileged accounts for use only while performing administrative
procedures; for further discussion, see <A HREF="auagd021.htm#HDRWQ584">An Overview of Administrative Privilege</A>.) If necessary, issue the <B>klog</B>
command to authenticate.
<PRE> % <B>klog</B> <VAR>admin_user</VAR>
Password: <VAR>admin_password</VAR>
</PRE>
<P>The following list specifies the necessary privileges and indicates how to
check that you have them.
<UL>
<P><LI>Membership in the <B>system:administrators</B> group. If
necessary, issue the <B>pts membership</B> command, which is fully
described in <A HREF="auagd021.htm#HDRWQ587">To display the members of the system:administrators group</A>.
<PRE> % <B>pts membership system:administrators</B>
</PRE>
<P><LI>Inclusion in the <B>/usr/afs/etc/UserList</B> file. If
necessary, issue the <B>bos listusers</B> command, which is fully
described in <A HREF="auagd021.htm#HDRWQ593">To display the users in the UserList file</A>.
<PRE> % <B>bos listusers</B> &lt;<VAR>machine name</VAR>>
</PRE>
<P><LI>The <TT>ADMIN</TT> flag on your Authentication Database entry.
However, the Authentication Server performs its own authentication, so in Step
<A HREF="#LIWQ507">4</A> you specify an administrative identity on the <B>kas</B>
command line itself.
<P><LI>The <B>i</B> (<B>insert</B>) and <B>a</B>
(<B>administer</B>) permissions on the ACL of the directory where you are
mounting the user's volume. If necessary, issue the <B>fs
listacl</B> command, which is fully described in <A HREF="auagd020.htm#HDRWQ572">Displaying ACLs</A>.
<PRE> % <B>fs listacl</B> [&lt;<VAR>dir/file path</VAR>>]
</PRE>
<P>Members of the <B>system:administrators</B> group always
implicitly have the <B>a</B> (<B>administer</B>) and by default also
the <B>l</B> (<B>lookup</B>) permission on every ACL and can use the
<B>fs setacl</B> command to grant other rights as necessary.
<P><LI>Knowledge of the password for the local superuser <B>root</B>.
</UL>
<A NAME="IDX7754"></A>
<A NAME="IDX7755"></A>
<P><LI><A NAME="LIWQ506"></A>Issue the <B>pts createuser</B> command to create an entry
in the Protection Database. For a discussion of setting AFS UIDs, see <A HREF="#HDRWQ496">Assigning AFS and UNIX UIDs that Match</A>. If you are converting an existing UNIX account into
an AFS account, also see <A HREF="#HDRWQ498">Converting Existing UNIX Accounts</A>.
<PRE> % <B>pts createuser</B> &lt;<VAR>user&nbsp;name</VAR>> [&lt;<VAR>user&nbsp;id</VAR>>]
</PRE>
<P>where
<DL>
<P><DT><B>cu
</B><DD>Is an acceptable alias for <B>createuser</B> (and <B>createu</B>
is the shortest acceptable abbreviation).
<P><DT><B><VAR>user name</VAR>
</B><DD>Specifies the user's username (the character string typed at
login). It is best to limit the name to eight or fewer lowercase
letters, because many application programs impose that limit. The AFS
servers themselves accept names of up to 63 lowercase letters. Also
avoid the following characters: colon (<B>:</B>), semicolon
(<B>;</B>), comma (<B>,</B>), at sign (<B>@</B>), space,
newline, and the period (<B>.</B>), which is conventionally used
only in special administrative names.
<P><DT><B><VAR>user id</VAR>
</B><DD>Is optional and appropriate only if the user already has a UNIX UID that
the AFS UID must match. If you do not provide this argument, the
Protection Server assigns one automatically based on the counter described in <A HREF="auagd019.htm#HDRWQ560">Displaying and Setting the AFS UID and GID Counters</A>. If the ID you specify is less than <B>1</B>
(one) or is already in use, an error results.
</DL>
<A NAME="IDX7756"></A>
<A NAME="IDX7757"></A>
<P><LI><A NAME="LIWQ507"></A>Issue the <B>kas create</B> command to create an entry in
the Authentication Database. To avoid having the user's temporary
initial password echo visibly on the screen, omit the
<B>-initial_password</B> argument; instead enter the password at the
prompts that appear when you omit the argument, as shown in the following
syntax specification.
<P>The Authentication Server performs its own authentication rather than
accepting your existing AFS token. By default, it authenticates your
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
administrator. Include the <B>-admin</B> argument to name an
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
entry. To verify that an entry has the flag, issue the <B>kas
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
<PRE> % <B>kas create</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>> \
<B>-admin</B> &lt;<VAR>admin&nbsp;principal&nbsp;to&nbsp;use&nbsp;for&nbsp;authentication</VAR>>
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
initial_password: <VAR>initial_password</VAR>
Verifying, please re-enter initial_password: <VAR>initial_password</VAR>
</PRE>
<P>where
<DL>
<P><DT><B>cr
</B><DD>Is the shortest acceptable abbreviation for <B>create</B>.
<P><DT><B><VAR>name of user</VAR>
</B><DD>Specifies the same username as in Step <A HREF="#LIWQ506">3</A>.
<P><DT><B>-admin
</B><DD>Names an administrative account that has the <TT>ADMIN</TT> flag on its
Authentication Database entry, such as <B>admin</B>. The password
prompt echoes it as <VAR>admin_user</VAR>. Enter the appropriate password
as <VAR>admin_password</VAR>.
<P><DT><B><VAR>initial_password</VAR>
</B><DD>Specifies the initial password as a string of eight characters or less, to
comply with the length restriction that some applications impose.
Possible choices for an initial password include the username, a string of
digits from a personal identification number such as the Social Security
number, or a standard string such as <B>changeme</B>. Instruct the
user to change the string to a truly secret password as soon as possible by
using the <B>kpasswd</B> command as described in the <I>IBM AFS User
Guide</I>.
</DL>
<A NAME="IDX7758"></A>
<A NAME="IDX7759"></A>
<P><LI><A NAME="LIWQ508"></A>Issue the <B>vos create</B> command to create the
user's volume.
<PRE> % <B>vos create</B> &lt;<VAR>machine&nbsp;name</VAR>> &lt;<VAR>partition&nbsp;name</VAR>> &lt;<VAR>volume&nbsp;name</VAR>> \
[<B>-maxquota</B> &lt;<VAR>initial&nbsp;quota&nbsp;(KB)</VAR>>]
</PRE>
<P>where
<DL>
<P><DT><B>cr
</B><DD>Is the shortest acceptable abbreviation of <B>create</B>.
<P><DT><B><VAR>machine name</VAR>
</B><DD>Names the file server machine on which to place the new volume.
<P><DT><B><VAR>partition name</VAR>
</B><DD>Names the partition on which to place the new volume.
<P><DT><B><VAR>volume name</VAR>
</B><DD>Names the new volume. The name can include up to 22
characters. By convention, user volume names have the form
<B>user.</B><VAR>username</VAR>, where <VAR>username</VAR> is the name
assigned in Step <A HREF="#LIWQ506">3</A>.
<P><DT><B>-maxquota
</B><DD>Sets the volume's quota, as a number of kilobyte blocks. If
you omit this argument, the default is 5000 KB.
</DL>
<A NAME="IDX7760"></A>
<A NAME="IDX7761"></A>
<P><LI><A NAME="LIWQ509"></A>Issue the <B>fs mkmount</B> command to mount the volume in
the filespace and create the user's home directory.
<PRE> % <B>fs mkmount</B> &lt;<VAR>directory</VAR>> &lt;<VAR>volume&nbsp;name</VAR>>
</PRE>
<P>where
<DL>
<P><DT><B>mk
</B><DD>Is the shortest acceptable abbreviation for <B>mkmount</B>.
<P><DT><B><VAR>directory</VAR>
</B><DD>Names the mount point to create. A directory of the same name must
not already exist. Partial pathnames are interpreted relative to the
current working directory. By convention, user home directories are
mounted in a directory called something like
<B>/afs/.</B><VAR>cellname</VAR><B>/usr</B>, and the home
directory name matches the username assigned in Step <A HREF="#LIWQ506">3</A>.
<P>Specify the read/write path to the mount point, to avoid the failure that
results when you attempt to create the new mount point in a read-only
volume. By convention, you indicate the read/write path by placing a
period before the cell name at the pathname's second level (for example,
<B>/afs/.abc.com</B>). For further discussion of the
concept of read/write and read-only paths through the filespace, see <A HREF="auagd010.htm#HDRWQ209">The Rules of Mount Point Traversal</A>.
<P><DT><B><VAR>volume name</VAR>
</B><DD>Is the name of the volume created in Step <A HREF="#LIWQ508">5</A>.
</DL>
<P><LI><B>(Optional)</B> Issue the <B>fs setvol</B> command with the
<B>-offlinemsg</B> argument to record auxiliary information about the
volume in its volume header. For example, you can record who owns the
volume or where you have mounted it in the filespace. To display the
information, use the <B>fs examine</B> command.
<PRE> % <B>fs setvol</B> &lt;<VAR>dir/file path</VAR>> <B>-offlinemsg</B> &lt;<VAR>offline message</VAR>>
</PRE>
<P>where
<DL>
<P><DT><B>sv
</B><DD>Is an acceptable alias for <B>setvol</B> (and <B>setv</B> the
shortest acceptable abbreviation).
<P><DT><B><VAR>dir/file path</VAR>
</B><DD>Names the mount point of the volume with which to associate the
message. Partial pathnames are interpreted relative to the current
working directory.
<P>Specify the read/write path to the mount point, to avoid the failure that
results when you attempt to change a read-only volume. By convention,
you indicate the read/write path by placing a period before the cell name at
the pathname's second level (for example,
<B>/afs/.abc.com</B>). For further discussion of the
concept of read/write and read-only paths through the filespace, see <A HREF="auagd010.htm#HDRWQ209">The Rules of Mount Point Traversal</A>.
<P><DT><B>-offlinemsg
</B><DD>Specifies up to 128 characters of auxiliary information to record in the
volume header.
</DL>
<P><LI><A NAME="LIWQ510"></A>Issue the <B>fs setacl</B> command to set the ACL on the
new home directory. At the least, create an entry that grants all
permissions to the user, as shown.
<P>You can also use the command to edit or remove the entry that the <B>vos
create</B> command automatically places on the ACL for a new volume's
root directory, which grants all permissions to the
<B>system:administrators</B> group. Keep in mind that even if
you remove the entry, the members of the group by default have implicit
<B>a</B> (<B>administer</B>) and by default <B>l</B>
(<B>lookup</B>) permissions on every ACL, and can grant themselves other
permissions as required.
<P>For detailed instructions for the <B>fs setacl</B> command, see <A HREF="auagd020.htm#HDRWQ573">Setting ACL Entries</A>.
<PRE> % <B>fs setacl</B> &lt;<VAR>directory</VAR>> <B>-acl</B> &lt;<VAR>user&nbsp;name</VAR>> <B>all</B> \
[<B>system:administrators</B> <VAR>desired_permissions</VAR>]
</PRE>
<P><LI><A NAME="LIWQ511"></A><B>(Optional)</B> Create configuration files and
subdirectories in the new home directory. Possibilities include
<B>.login</B> and <B>.logout</B> files, a
shell-initialization file such as <B>.cshrc</B>, files to help with
printing and mail delivery, and so on.
<P>If you are converting an existing UNIX account into an AFS account, you
possibly wish to move some files and directories into the user's new AFS
home directory. See <A HREF="#HDRWQ498">Converting Existing UNIX Accounts</A>.
<P><LI><B>(Optional)</B> In the new <B>.login</B> or shell
initialization file, define the user's $PATH environment variable to
include the directories where AFS binaries are kept (for example, the
<B>/usr/afsws/bin</B> and <B>/usr/afsws/etc</B> directories).
<P><LI><A NAME="LIWQ512"></A>In Step <A HREF="#LIWQ513">12</A> and Step <A HREF="#LIWQ514">14</A>, you must know the user's AFS
UID. If you had the Protection Server assign it in Step <A HREF="#LIWQ506">3</A>, you probably do not know it. If necessary, issue
the <B>pts examine</B> command to display it.
<PRE> % <B>pts examine</B> &lt;<VAR>user&nbsp;or&nbsp;group&nbsp;name&nbsp;or&nbsp;id</VAR>>
</PRE>
<P>where
<DL>
<P><DT><B>e
</B><DD>Is the shortest acceptable abbreviation of <B>examine</B>.
<P><DT><B><VAR>user or group name or id</VAR>
</B><DD>Is the username that you assigned in Step <A HREF="#LIWQ506">3</A>.
</DL>
<P>The first line of the output displays the username and AFS UID. For
further discussion and an example of the output, see <A HREF="auagd019.htm#HDRWQ536">Displaying Information from the Protection Database</A>.
<P><LI><A NAME="LIWQ513"></A>Designate the user as the owner of the home directory and any
files and subdirectories created or moved in Step <A HREF="#LIWQ511">9</A>. Specify the owner by the AFS UID you learned in Step
<A HREF="#LIWQ512">11</A> rather than by username. This is necessary for new
accounts because the user does not yet have an entry in your local
machine's password file (<B>/etc/passwd</B> or equivalent). If
you are converting an existing UNIX account, an entry possibly already exists,
but the UID is possibly incorrect. In that case, specifying a username
means that the corresponding (possibly incorrect) UID is recorded as the
owner.
<P>Some operating systems allow only the local superuser <B>root</B> to
issue the <B>chown</B> command. If necessary, issuing the
<B>su</B> command before the <B>chown</B> command.
<PRE> % <B>chown</B> <VAR>new_owner_ID</VAR> <VAR>directory</VAR>
</PRE>
<P>where
<DL>
<P><DT><B><VAR>new_owner_ID</VAR>
</B><DD>Is the user's AFS UID, which you learned in Step <A HREF="#LIWQ512">11</A>.
<P><DT><B><VAR>directory</VAR>
</B><DD>Names the home directory you created in Step <A HREF="#LIWQ509">6</A>, plus each subdirectory or file you created in Step <A HREF="#LIWQ511">9</A>.
</DL>
<P><LI>If the new user home directory resides in a replicated volume, use the
<B>vos release</B> command to release the volume, as described in <A HREF="auagd010.htm#HDRWQ194">To replicate a read/write volume (create a read-only volume)</A>.
<PRE>
% <B>vos release</B> &lt;<VAR>volume&nbsp;name&nbsp;or&nbsp;ID</VAR>>
</PRE>
<TABLE><TR><TD ALIGN="LEFT" VALIGN="TOP"><B>Note:</B></TD><TD ALIGN="LEFT" VALIGN="TOP">This step can be necessary even if the home directory's parent directory
is not itself a mount point for a replicated volume (and is easier to overlook
in that case). Suppose, for example, that the ABC Corporation puts the
mount points for user volumes in the <B>/afs/abc.com/usr</B>
directory. Because that is a regular directory rather than a mount
point, it resides in the <B>root.cell</B> volume mounted at the
<B>/afs/abc.com</B> directory. That volume is replicated, so
after changing it by creating a new mount point the administrator must issue
the <B>vos release</B> command.
</TD></TR></TABLE>
<P><LI><A NAME="LIWQ514"></A>Create or modify an entry for the new user in the local
password file (<B>/etc/passwd</B> or equivalent) of each machine the user
can log onto. Remember to make the UNIX UID the same as the AFS UID you
learned in Step <A HREF="#LIWQ512">11</A>, and to fill the password field appropriately (for
instructions, see <A HREF="#HDRWQ497">Specifying Passwords in the Local Password File</A>).
<P>If you use the <B>package</B> utility to distribute a common version of
the password file to all client machines, then you need to make the change
only in the common version. See <A HREF="auagd016.htm#HDRWQ419">Configuring Client Machines with the package Program</A>.
</OL>
<A NAME="IDX7762"></A>
<A NAME="IDX7763"></A>
<A NAME="IDX7764"></A>
<A NAME="IDX7765"></A>
<HR><H2><A NAME="HDRWQ515" HREF="auagd002.htm#ToC_584">Improving Password and Authentication Security</A></H2>
<P>AFS provides several optional features than can help to
protect your cell's filespace against unauthorized access. The
following list summarizes them, and instructions follow.
<UL>
<P><LI>Limit the number of consecutive failed login attempts.
<P>One of the most common ways for an unauthorized user to access your
filespace is to guess an authorized user's password. This method
of attack is most dangerous if the attacker can use many login processes in
parallel or use the RPC interfaces directly.
<P>To protect against this type of attack, use the <B>-attempts</B>
argument to the <B>kas setfields</B> command to limit the number of times
that a user can consecutively fail to enter the correct password when using
either an AFS-modified login utility or the <B>klog</B> command.
When the limit is exceeded, the Authentication Server locks the user's
Authentication Database entry (disallows authentication attempts) for a period
of time that you define with the <B>-locktime</B> argument to the <B>kas
setfields</B> command. If desired, system administrators can use the
<B>kas unlock</B> command to unlock the entry before the complete lockout
time passes.
<P>In certain circumstances, the mechanism used to enforce the number of
failed authentication attempts can cause a lockout even though the number of
failed attempts is less than the limit set by the <B>-attempts</B>
argument. Client-side authentication programs such as <B>klog</B>
and an AFS-modified login utility normally choose an Authentication Server at
random for each authentication attempt, and in case of a failure are likely to
choose a different Authentication Server for the next attempt. The
Authentication Servers running on the various database server machines do not
communicate with each other about how many times a user has failed to provide
the correct password to them. Instead, each Authentication Server
maintains its own separate copy of the auxiliary database file
<B>kaserverauxdb</B> (located in the <B>/usr/afs/local</B> directory
by default), which records the number of consecutive authentication failures
for each user account and the time of the most recent failure. This
implementation means that on average each Authentication Server knows about
only a fraction of the total number of failed attempts. The only way to
avoid allowing more than the number of attempts set by the
<B>-attempts</B> argument is to have each Authentication Server allow only
some fraction of the total. More specifically, if the limit on failed
attempts is <I>f</I>, and the number of Authentication Servers is
<I>S</I>, then each Authentication Server can only permit a number of
attempts equal to <I>f</I> divided by <I>S</I> (the Ubik
synchronization site for the Authentication Server tracks any remainder,
<I>fmodS</I>).
<P>Normally, this implementation does not reduce the number of allowed
attempts to less than the configured limit (<I>f</I>). If one
Authentication Server refuses an attempt, the client contacts another instance
of the server, continuing until either it successfully authenticates or has
contacted all of the servers. However, if one or more of the
Authentication Server processes is unavailable, the limit is effectively
reduced by a percentage equal to the quantity <I>U</I> divided by
<I>S</I>, where <I>U</I> is the number of unavailable servers and
<I>S</I> is the number normally available.
<P>To avoid the undesirable consequences of setting a limit on failed
authentication attempts, note the following recommendations:
<UL>
<P><LI>Do not set the <B>-attempts</B> argument (the limit on failed
authentication attempts) too low. A limit of nine failed attempts is
recommended for regular user accounts, to allow three failed attempts per
Authentication Server in a cell with three database server machines.
<P><LI>Set fairly short lockout times when including the <B>-locktime</B>
argument. Although guessing passwords is a common method of attack, it
is not a very sophisticated one. Setting a lockout time can help
discourage attackers, but excessively long times are likely to be more of a
burden to authorized users than to potential attackers. A lockout time
of 25 minutes is recommended for regular user accounts.
<P><LI>Do not assign an infinite lockout time on an account (by setting the
<B>-locktime</B> argument to <B>0</B> [zero]) unless there is a highly
compelling reason. Such accounts almost inevitably become locked at
some point, because each Authentication Server never resets the account's
failure counter in its copy of the <B>kaauxdb</B> file (in contrast, when
the lockout time is not infinite, the counter resets after the specified
amount of time has passed since the last failed attempt to that Authentication
Server). Furthermore, the only way to unlock an account with an
infinite lockout time is for an administrator to issue the <B>kas
unlock</B> command. It is especially dangerous to set an infinite
lockout time on an administrative account; if all administrative accounts
become locked, the only way to unlock them is to shut down all instances of
the Authentication Server and remove the <B>kaauxdb</B> file on
each.
</UL>
<P>In summary, the recommended limit on authentication attempts is nine and
lockout time 25 minutes.
<P><LI>Limit password lifetime.
<P>The longer a password is in use, the more time an attacker has to try to
learn it. To protect against this type of attack, use the
<B>-pwexpires</B> argument to the <B>kas setfields</B> command to
limit how many days a user's password is valid. The user becomes
unable to authenticate with AFS after the password expires, but has up to 30
days to use the <B>kpasswd</B> command to set a new password. After
the 30 days pass, only an administrator who has the <TT>ADMIN</TT> flag on
the Authentication Database entry can change the password.
<P>If you set a password lifetime, many AFS-modified login utilities (but not
the <B>klog</B> command) set the PASSWORD_EXPIRES environment variable to
the number of days remaining until the password expires. A setting of
zero means that the password expires today. If desired, you can
customize your users' login scripts to display the number of days
remaining before expiration and even prompt for a password change when a small
number of days remain before expiration.
<P><LI>Prohibit reuse of passwords.
<P>Forcing users to select new passwords periodically is not effective if they
simply set the new password to the current value. To prevent a user
from setting a new password to a string similar to any of the last 20
passwords, use the <B>-reuse</B> argument to the <B>kas setfields</B>
command.
<P>If you prohibit password reuse and the user specifies an excessively
similar password, the Authentication Server generates the following message to
reject it:
<PRE> Password was not changed because it seems like a reused password
</PRE>
<P>A persistent user can try to bypass this restriction by changing the
password 20 times in quick succession (or running a script to do so).
If you believe this is likely to be a problem, you can include the
<B>-minhours</B> argument to the <B>kaserver</B> initialization
command (for details, see the command's reference page in the <I>IBM
AFS Administration Reference</I>. If the user attempts to change
passwords too frequently, the following message appears.
<PRE> Password was not changed because you changed it too recently; see
your systems administrator
</PRE>
<P><LI>Check the quality of new passwords.
<P>You can impose a minimum quality standard on passwords by writing a script
or program called <B>kpwvalid</B>. If the <B>kpwvalid</B> file
exists, the <B>kpasswd</B> and <B>kas setpassword</B> command
interpreters invoke it to check a new password. If the password does
not comply with the quality standard, the <B>kpwvalid</B> program returns
an appropriate code and the command interpreter rejects the password.
<P>The <B>kpwvalid</B> file must be executable, must reside in the same
AFS directory as the <B>kpasswd</B> and <B>kas</B> binaries, and its
directory's ACL must grant the <B>w</B> (<B>write</B>) permission
only to the <B>system:administrators</B> group.
<P>If you choose to write a <B>kpwvalid</B> program, consider imposing
standards such as the following.
<UL>
<P><LI>A minimum length
<P><LI>Words found in the dictionary are prohibited
<P><LI>Numbers, punctuation, or both must appear along with letters
</UL>
<P>The AFS distribution includes an example <B>kpwvalid</B>
program. See the <B>kpwvalid</B> reference page in the <I>IBM AFS
Administration Reference</I>.
</UL>
<A NAME="IDX7766"></A>
<A NAME="IDX7767"></A>
<P><H3><A NAME="Header_585" HREF="auagd002.htm#ToC_585">To limit the number of consecutive failed authentication attempts</A></H3>
<OL TYPE=1>
<P><LI>Issue the <B>kas setfields</B> command with the <B>-attempts</B>
and <B>-locktime</B> arguments.
<P>The Authentication Server performs its own authentication rather than
accepting your existing AFS token. By default, it authenticates your
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
administrator. Include the <B>-admin</B> argument to name an
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
entry. To verify that an entry has the flag, issue the <B>kas
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
<PRE> % <B>kas setfields</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>> \
<B>-admin</B> &lt;<VAR>admin&nbsp;principal&nbsp;to&nbsp;use&nbsp;for&nbsp;authentication</VAR>> \
<B>-attempts</B> &lt;<VAR>maximum&nbsp;successive&nbsp;failed&nbsp;login&nbsp;tries&nbsp;([0..254])</VAR>> \
<B>-locktime</B> &lt;<VAR>failure&nbsp;penalty&nbsp;[hh:mm&nbsp;or&nbsp;minutes]</VAR>>
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
</PRE>
<P>where
<DL>
<P><DT><B><VAR>name of user</VAR>
</B><DD>Names the Authentication Database entry to edit.
<P><DT><B>-admin
</B><DD>Names an administrative account that has the <TT>ADMIN</TT> flag on its
Authentication Database entry, such as the <B>admin</B> account.
The password prompt echoes it as <VAR>admin_user</VAR>. Enter the
appropriate password as <VAR>admin_password</VAR>.
<P><DT><B>-attempts
</B><DD>Specifies the maximum consecutive number of times that a user can fail to
provide the correct password during authentication (via the <B>klog</B>
command or an AFS-modified login utility) before the Authentication Server
refuses further attempts for the amount of time specified by the
<B>-locktime</B> argument. The range of valid values is
<B>0</B> (zero) through <B>254</B>. If you omit this argument
or specify <B>0</B>, the Authentication Server allows an unlimited number
of failures.
<P><DT><B><B>-locktime</B>
</B><DD>Specifies how long the Authentication Server refuses authentication
attempts after the user exceeds the failure limit specified by the
<B>-attempts</B> argument.
<P>Specify a time in either hours and minutes (<VAR>hh</VAR>:<VAR>mm</VAR>)
or minutes only (<VAR>mm</VAR>), from the range <B>01</B> (one minute)
through <B>36:00</B> (36 hours). The <B>kas</B> command
interpreter automatically reduces any larger value to 36:00 and also
rounds up each nonzero value to the next-higher multiple of 8.5
minutes.
<P>It is best not to provide a value of <B>0</B> (zero), especially on
administrative accounts, because it sets an infinite lockout time. An
administrator must always issue the <B>kas unlock</B> command to unlock
such an account.
</DL>
</OL>
<P><H3><A NAME="Header_586" HREF="auagd002.htm#ToC_586">To unlock a locked user account</A></H3>
<OL TYPE=1>
<P><LI>Issue the <B>kas</B> command to enter interactive mode.
<P>The Authentication Server performs its own authentication rather than
accepting your existing AFS token. By default, it authenticates your
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
administrator. Include the <B>-admin</B> argument to name an
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
entry. To verify that an entry has the flag, issue the <B>kas
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
<PRE> % <B>kas -admin</B> &lt;<VAR>admin&nbsp;principal&nbsp;to&nbsp;use&nbsp;for&nbsp;authentication</VAR>>
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
ka>
</PRE>
<P>where <B>-admin</B> names an administrative account that has the
<TT>ADMIN</TT> flag on its Authentication Database entry, such as
<B>admin</B>. The password prompt echoes it as
<VAR>admin_user</VAR>. Enter the appropriate password as
<VAR>admin_password</VAR>.
<P><LI>Issue the <B>(kas) examine</B> command to verify that the user's
account is in fact locked, as indicated by the message shown:
<PRE> ka> <B>examine</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>>
User is locked until <VAR>time</VAR>
</PRE>
<A NAME="IDX7768"></A>
<A NAME="IDX7769"></A>
<P><LI>Issue the <B>(kas) unlock</B> command to unlock the account.
<PRE> ka> <B>unlock</B> &lt;<VAR>authentication&nbsp;ID</VAR>>
</PRE>
<P>where
<DL>
<P><DT><B>u
</B><DD>Is the shortest acceptable abbreviation of <B>unlock</B>.
<P><DT><B><VAR>authentication ID</VAR>
</B><DD>Names the Authentication Database entry to unlock.
</DL>
</OL>
<A NAME="IDX7770"></A>
<A NAME="IDX7771"></A>
<A NAME="IDX7772"></A>
<P><H3><A NAME="Header_587" HREF="auagd002.htm#ToC_587">To set password lifetime</A></H3>
<OL TYPE=1>
<P><LI>Issue the <B>kas setfields</B> command with the <B>-pwexpires</B>
argument.
<P>The Authentication Server performs its own authentication rather than
accepting your existing AFS token. By default, it authenticates your
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
administrator. Include the <B>-admin</B> argument to name an
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
entry. To verify that an entry has the flag, issue the <B>kas
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
<PRE> % <B>kas setfields</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>> \
<B>-pwexpires</B> &lt;<VAR>number&nbsp;days&nbsp;password&nbsp;is&nbsp;valid &nbsp;[0..254])</VAR>> \
<B>-admin</B> &lt;<VAR>admin&nbsp;principal&nbsp;to&nbsp;use&nbsp;for&nbsp;authentication</VAR>>
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
</PRE>
<P>where
<DL>
<P><DT><B><VAR>name of user</VAR>
</B><DD>Specifies the Authentication Database entry on which to impose a password
expiration.
<P><DT><B>-pwexpires
</B><DD>Sets the number of days after the user's password was last changed
that it remains valid. Provide an integer from the range <B>1</B>
through <B>254</B> to specify the number of days until expiration.
<P>When the password becomes invalid (expires), the user is unable to
authenticate, but has 30 more days in which to issue the <B>kpasswd</B> or
<B>kas setpassword</B> command to change the password (after that, only an
administrator can change it). Note that the clock starts at the time
the password was last changed, not when the <B>kas setfields</B> command
is issued. To avoid retroactive expiration, have the user change the
password just before issuing the command.
<P><DT><B>-admin
</B><DD>Names an administrative account that has the <TT>ADMIN</TT> flag on its
Authentication Database entry, such as <B>admin</B>. The password
prompt echoes it as <VAR>admin_user</VAR>. Enter the appropriate password
as <VAR>admin_password</VAR>.
</DL>
</OL>
<A NAME="IDX7773"></A>
<A NAME="IDX7774"></A>
<P><H3><A NAME="Header_588" HREF="auagd002.htm#ToC_588">To prohibit reuse of passwords</A></H3>
<OL TYPE=1>
<P><LI>Issue the <B>kas setfields</B> command with the <B>-reuse</B>
argument.
<P>The Authentication Server performs its own authentication rather than
accepting your existing AFS token. By default, it authenticates your
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
administrator. Include the <B>-admin</B> argument to name an
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
entry. To verify that an entry has the flag, issue the <B>kas
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
<PRE> % <B>kas setfields</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>> <B>-reuse</B> &lt;<VAR> permit&nbsp;password&nbsp;reuse&nbsp;(yes/no)</VAR>> \
<B>-admin</B> &lt;<VAR>admin&nbsp;principal&nbsp;to&nbsp;use&nbsp;for&nbsp;authentication</VAR>>
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
</PRE>
<P>where
<DL>
<P><DT><B><VAR>name of user</VAR>
</B><DD>Names the Authentication Database entry for which to set the password
reuse policy.
<P><DT><B>-reuse
</B><DD>Specifies whether the Authentication Server allows reuse of passwords
similar to any of the user's last 20 passwords. Specify the value
<B>no</B> to prohibit reuse, or the value <B>yes</B> to reinstate the
default of allowing password reuse.
<P><DT><B>-admin
</B><DD>Names an administrative account that has the <TT>ADMIN</TT> flag on its
Authentication Database entry, such as <B>admin</B>. The password
prompt echoes it as <VAR>admin_user</VAR>. Enter the appropriate password
as <VAR>admin_password</VAR>.
</DL>
</OL>
<A NAME="IDX7775"></A>
<A NAME="IDX7776"></A>
<A NAME="IDX7777"></A>
<HR><H2><A NAME="HDRWQ516" HREF="auagd002.htm#ToC_589">Changing AFS Passwords</A></H2>
<P>After setting an initial password during account creation,
you normally do not need to change user passwords, since they can use the
<B>kpasswd</B> command themselves by following the instructions in the
<I>IBM AFS User Guide</I>. In the rare event that a user forgets
the password or otherwise cannot log in, you can use the <B>kas
setpassword</B> command to set a new password.
<P>If entries in the local password file (<B>/etc/passwd</B> or
equivalent) have actual scrambled passwords in their password field, remember
to change the password there also. For further discussion, see <A HREF="#HDRWQ497">Specifying Passwords in the Local Password File</A>.
<A NAME="IDX7778"></A>
<A NAME="IDX7779"></A>
<P><H3><A NAME="Header_590" HREF="auagd002.htm#ToC_590">To change an AFS password</A></H3>
<OL TYPE=1>
<P><LI>Issue the <B>kas setpassword</B> command to change the
password. To avoid having the new password echo visibly on the screen,
omit the <B>-new_password</B> argument; instead enter the password at
the prompts that appear when you omit the argument, as shown.
<P>The Authentication Server performs its own authentication rather than
accepting your existing AFS token. By default, it authenticates your
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
administrator. Include the <B>-admin</B> argument to name an
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
entry. To verify that an entry has the flag, issue the <B>kas
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
<PRE> % <B>kas setpassword</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>> \
<B>-admin</B> &lt;<VAR>admin&nbsp;principal&nbsp;to&nbsp;use&nbsp;for&nbsp;authentication</VAR>>
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
new_password: <VAR>new_password</VAR>
Verifying, please re-enter new_password: <VAR>new_password</VAR>
</PRE>
<P>where
<DL>
<P><DT><B>sp
</B><DD>Is an acceptable alias for <B>setpassword</B> (<B>setp</B> is the
shortest acceptable abbreviation).
<P><DT><B><VAR>name of user</VAR>
</B><DD>Names the Authentication Database entry for which to set the
password.
<P><DT><B>-admin
</B><DD>Names an administrative account that has the <TT>ADMIN</TT> flag on its
Authentication Database entry, such as <B>admin</B>. The password
prompt echoes it as <VAR>admin_user</VAR>. Enter the appropriate password
as <VAR>admin_password</VAR>.
<P><DT><B><VAR>new_password</VAR>
</B><DD>Specifies the user's new password. It is subject to the
restrictions imposed by the <B>kpwvalid</B> program, if you use it.
</DL>
</OL>
<HR><H2><A NAME="HDRWQ517" HREF="auagd002.htm#ToC_591">Displaying and Setting the Quota on User Volumes</A></H2>
<P>User volumes are like all other volumes with respect to
quota. Each new AFS volume has a default quota of 5000 KB, unless you
use the <B>-maxquota</B> argument to the <B>vos create</B> command to
set a different quota. You can also use either of the following
commands to change quota at any time:
<UL>
<P><LI><B>fs setquota</B>
<P><LI><B>fs setvol</B>
</UL>
<P>You can use any of the three following commands to display a volume's
quota:
<UL>
<P><LI><B>fs quota</B>
<P><LI><B>fs listquota</B>
<P><LI><B>fs examine</B>
</UL>
<P>For instructions, see <A HREF="auagd010.htm#HDRWQ234">Setting and Displaying Volume Quota and Current Size</A>.
<A NAME="IDX7780"></A>
<A NAME="IDX7781"></A>
<A NAME="IDX7782"></A>
<A NAME="IDX7783"></A>
<A NAME="IDX7784"></A>
<HR><H2><A NAME="HDRWQ518" HREF="auagd002.htm#ToC_592">Changing Usernames</A></H2>
<P>By convention, many components of a user account incorporate
the username, including the Protection and Authentication Database entries,
the volume name and the home directory name. When changing a username,
it is best to maintain consistency by changing the names of all components, so
the procedure for changing a username has almost as many steps as the
procedure for creating a new user account.
<P><H3><A NAME="Header_593" HREF="auagd002.htm#ToC_593">To change a username</A></H3>
<OL TYPE=1>
<A NAME="IDX7785"></A>
<A NAME="IDX7786"></A>
<P><LI>Authenticate as an AFS identity with all of the following
privileges. In the conventional configuration, the <B>admin</B>
user account has them, or you possibly have a personal administrative
account. (To increase cell security, it is best to create special
privileged accounts for use only while performing administrative
procedures; for further discussion, see <A HREF="auagd021.htm#HDRWQ584">An Overview of Administrative Privilege</A>.) If necessary, issue the <B>klog</B>
command to authenticate.
<PRE> % <B>klog</B> <VAR>admin_user</VAR>
Password: <VAR>admin_password</VAR>
</PRE>
<P>The following list specifies the necessary privileges and indicates how to
check that you have them.
<UL>
<P><LI>Membership in the <B>system:administrators</B> group. If
necessary, issue the <B>pts membership</B> command, which is fully
described in <A HREF="auagd021.htm#HDRWQ587">To display the members of the system:administrators group</A>.
<PRE> % <B>pts membership system:administrators</B>
</PRE>
<P><LI>Inclusion in the <B>/usr/afs/etc/UserList</B> file. If
necessary, issue the <B>bos listusers</B> command, which is fully
described in <A HREF="auagd021.htm#HDRWQ593">To display the users in the UserList file</A>.
<PRE> % <B>bos listusers</B> &lt;<VAR>machine name</VAR>>
</PRE>
<P><LI>The <TT>ADMIN</TT> flag on the Authentication Database entry.
However, the Authentication Server performs its own authentication, so the
following instructions direct you to specify an administrative identity on the
<B>kas</B> command line itself.
<P><LI>The <B>a</B> (<B>administer</B>), <B>d</B>
(<B>delete</B>), and <B>i</B> (<B>insert</B>) permissions on the
ACL of the directory where you are removing the current mount point and
creating a new one. If necessary, issue the <B>fs listacl</B>
command, which is fully described in <A HREF="auagd020.htm#HDRWQ572">Displaying ACLs</A>.
<PRE> % <B>fs listacl</B> [&lt;<VAR>dir/file path</VAR>>]
</PRE>
<P>Members of the <B>system:administrators</B> group always
implicitly have the <B>a</B> (<B>administer</B>) and by default also
the <B>l</B> (<B>lookup</B>) permission on every ACL and can use the
<B>fs setacl</B> command to grant other rights as necessary.
</UL>
<P><LI><A NAME="LIWQ519"></A>Issue the <B>pts listowned</B> command to display the names
of the groups the user owns. After you change the username in the
Protection Database in Step <A HREF="#LIWQ520">3</A>, you must issue the <B>pts rename</B> command to change
each group's owner prefix to match the new name, because the Protection
Server does not automatically make this change. For a complete
description of the <B>pts listowned</B> command, see <A HREF="auagd019.htm#HDRWQ536">Displaying Information from the Protection Database</A>.
<PRE> % <B>pts listowned</B> &lt;<VAR>user&nbsp;or&nbsp;group&nbsp;name&nbsp;or&nbsp;id</VAR>>
</PRE>
<P><LI><A NAME="LIWQ520"></A>Issue the <B>pts rename</B> command to change the
user's name in the Protection Database.
<PRE> % <B>pts rename</B> &lt;<VAR>old&nbsp;name</VAR>> &lt;<VAR>new&nbsp;name</VAR>>
</PRE>
<P><LI>Issue the <B>pts rename</B> command to change the group names you
noted in Step <A HREF="#LIWQ519">2</A>, so that their owner prefix (the part of the group name
before the colon) accurately reflects the owner's new name.
<P>Repeat the command for each group. Step <A HREF="#LIWQ520">3</A> details its syntax.
<PRE> % <B>pts rename</B> &lt;<VAR>old&nbsp;name</VAR>> &lt;<VAR>new&nbsp;name</VAR>>
</PRE>
<P><LI>Issue the <B>kas</B> command to enter interactive mode.
<P>The Authentication Server performs its own authentication rather than
accepting your existing AFS token. By default, it authenticates your
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
administrator. Include the <B>-admin</B> argument to name an
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
entry. To verify that an entry has the flag, issue the <B>kas
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
<PRE> % <B>kas -admin</B> &lt;<VAR>admin&nbsp;principal&nbsp;to&nbsp;use&nbsp;for&nbsp;authentication</VAR>>
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
ka>
</PRE>
<P>where <B>-admin</B> names an administrative account that has the
<TT>ADMIN</TT> flag on its Authentication Database entry, such as
<B>admin</B>. The password prompt echoes it as
<VAR>admin_user</VAR>. Enter the appropriate password as
<VAR>admin_password</VAR>.
<A NAME="IDX7787"></A>
<A NAME="IDX7788"></A>
<P><LI>Issue the <B>(kas) delete</B> command to delete the user's
existing Authentication Database entry.
<P>
<PRE> ka> <B>delete</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>>
</PRE>
<P>where
<DL>
<P><DT><B>del
</B><DD>Is the shortest acceptable abbreviation for <B>delete</B>, or you can
use the alias <B>rm</B>.
<P><DT><B><VAR>name of user</VAR>
</B><DD>Names the Authentication Database entry to delete.
</DL>
<A NAME="IDX7789"></A>
<A NAME="IDX7790"></A>
<P><LI>Issue the <B>(kas) create</B> command to create an Authentication
Database entry for the new username. To avoid having the user's
password echo visibly on the screen, do not include the
<B>-initial_password</B> argument; instead enter the password at the
prompts that appear in that case, as shown in the following syntax
specification.
<PRE> ka> <B>create</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>>
initial_password: <VAR>password</VAR>
Verifying, please re-enter initial_password: <VAR>password</VAR>
</PRE>
<P>where
<DL>
<P><DT><B>cr
</B><DD>Is the shortest acceptable abbreviation for <B>create</B>.
<P><DT><B><VAR>name of user</VAR>
</B><DD>Specifies the new username.
<P><DT><B><VAR>password</VAR>
</B><DD>Specifies the password for the new user account. If the user is
willing to tell you his or her current password, you can retain it.
Otherwise, provide a string of eight characters or less to comply with the
length restriction that some applications impose. Possible choices for
an initial password include the username, a string of digits from a personal
identification number such as the Social Security number, or a standard string
such as <B>changeme</B>. Instruct the user to change the string to
a truly secret password as soon as possible by using the <B>kpasswd</B>
command as instructed in the <I>IBM AFS User Guide</I>.
</DL>
<P><LI>Issue the <B>quit</B> command to leave interactive mode.
<PRE> ka> <B>quit</B>
</PRE>
<A NAME="IDX7791"></A>
<A NAME="IDX7792"></A>
<A NAME="IDX7793"></A>
<A NAME="IDX7794"></A>
<A NAME="IDX7795"></A>
<P><LI><A NAME="LIWQ521"></A>Issue the <B>vos rename</B> command to change the name of
the user's volume. For complete syntax, see <A HREF="auagd010.htm#HDRWQ246">To rename a volume</A>.
<PRE> % <B>vos rename</B> &lt;<VAR>old&nbsp;volume&nbsp;name</VAR>> &lt;<VAR>new&nbsp;volume&nbsp;name</VAR>>
</PRE>
<A NAME="IDX7796"></A>
<A NAME="IDX7797"></A>
<A NAME="IDX7798"></A>
<A NAME="IDX7799"></A>
<A NAME="IDX7800"></A>
<P><LI><A NAME="LIWQ522"></A>Issue the <B>fs rmmount</B> command to remove the existing
mount point. For the <VAR>directory</VAR> argument, specify the
read/write path to the mount point, to avoid the failure that results when you
attempt to delete a mount point from a read-only volume.
<PRE> % <B>fs rmmount</B> &lt;<VAR>directory</VAR>>
</PRE>
<A NAME="IDX7801"></A>
<A NAME="IDX7802"></A>
<A NAME="IDX7803"></A>
<P><LI><A NAME="LIWQ523"></A>Issue the <B>fs mkmount</B> command to create a mount point
for the volume's new name. Specify the read/write path to the
mount point for the <VAR>directory</VAR> argument, as in the previous
step. For complete syntax, see Step <A HREF="#LIWQ509">6</A> in <A HREF="#HDRWQ503">To create one user account with individual commands</A>.
<PRE> % <B>fs mkmount</B> &lt;<VAR>directory</VAR>> &lt;<VAR>volume&nbsp;name</VAR>>
</PRE>
<P><LI>If the changes you made in Step <A HREF="#LIWQ522">10</A> and Step <A HREF="#LIWQ523">11</A> are to a mount point that resides in a
replicated volume, use the <B>vos release</B> command to release the
volume, as described in <A HREF="auagd010.htm#HDRWQ194">To replicate a read/write volume (create a read-only volume)</A>.
<PRE>
% <B>vos release</B> &lt;<VAR>volume&nbsp;name&nbsp;or&nbsp;ID</VAR>>
</PRE>
<TABLE><TR><TD ALIGN="LEFT" VALIGN="TOP"><B>Note:</B></TD><TD ALIGN="LEFT" VALIGN="TOP">This step can be necessary even if the home directory's parent directory
is not itself a mount point for a replicated volume (and is easier to overlook
in that case). For example, the ABC Corporation template puts the mount
points for user volumes in the <B>/afs/abc.com/usr</B>
directory. Because that is a regular directory rather than a mount
point, it resides in the <B>root.cell</B> volume mounted at the
<B>/afs/abc.com</B> directory. That volume is replicated, so
after changing it the administrator must issue the <B>vos release</B>
command.
</TD></TR></TABLE>
</OL>
<HR><H2><A NAME="HDRWQ524" HREF="auagd002.htm#ToC_594">Removing a User Account</A></H2>
<A NAME="IDX7804"></A>
<A NAME="IDX7805"></A>
<P>Before removing an account, it is best to make a backup copy of the
user's home volume on a permanent storage medium such as tape. If
you need to remove several accounts, it is probably more efficient to use the
<B>uss delete</B> command instead; see <A HREF="auagd017.htm#HDRWQ486">Deleting Individual Accounts with the uss delete Command</A>.
<P><H3><A NAME="Header_595" HREF="auagd002.htm#ToC_595">To remove a user account</A></H3>
<OL TYPE=1>
<P><LI>Authenticate as an AFS identity with all of the following
privileges. In the conventional configuration, the <B>admin</B>
user account has them, or you possibly have a personal administrative
account. (To increase cell security, it is best to create special
privileged accounts for use only while performing administrative
procedures; for further discussion, see <A HREF="auagd021.htm#HDRWQ584">An Overview of Administrative Privilege</A>.) If necessary, issue the <B>klog</B>
command to authenticate.
<PRE> % <B>klog</B> <VAR>admin_user</VAR>
Password: <VAR>admin_password</VAR>
</PRE>
<P>The following list specifies the necessary privileges and indicates how to
check that you have them.
<UL>
<P><LI>Membership in the <B>system:administrators</B> group. If
necessary, issue the <B>pts membership</B> command, which is fully
described in <A HREF="auagd021.htm#HDRWQ587">To display the members of the system:administrators group</A>.
<PRE> % <B>pts membership system:administrators</B>
</PRE>
<P><LI>Inclusion in the <B>/usr/afs/etc/UserList</B> file. If
necessary, issue the <B>bos listusers</B> command, which is fully
described in <A HREF="auagd021.htm#HDRWQ593">To display the users in the UserList file</A>.
<PRE> % <B>bos listusers</B> &lt;<VAR>machine name</VAR>>
</PRE>
<P><LI>The <TT>ADMIN</TT> flag on the Authentication Database entry.
However, the Authentication Server performs its own authentication, so the
following instructions direct you to specify an administrative identity on the
<B>kas</B> command line itself.
<P><LI>The <B>d</B> (<B>delete</B>) permission on the ACL of the
directory where you are removing the user volume's mount point. If
necessary, issue the <B>fs listacl</B> command, which is fully described
in <A HREF="auagd020.htm#HDRWQ572">Displaying ACLs</A>.
<PRE> % <B>fs listacl</B> [&lt;<VAR>dir/file path</VAR>>]
</PRE>
<P>Members of the <B>system:administrators</B> group always
implicitly have the <B>a</B> (<B>administer</B>) and by default also
the <B>l</B> (<B>lookup</B>) permission on every ACL and can use the
<B>fs setacl</B> command to grant other rights as necessary.
</UL>
<P><LI><B>(Optional)</B> If it is possible you need to restore the
user's account someday, note the username and AFS UID, possibly in a file
designated for that purpose. You can later restore the account with its
original AFS UID.
<P><LI><B>(Optional)</B> Copy the contents of the user's volume to
tape. You can use the <B>vos dump</B> command as described in <A HREF="auagd010.htm#HDRWQ240">Dumping and Restoring Volumes</A> or the AFS Backup System as described in <A HREF="auagd012.htm#HDRWQ296">Backing Up Data</A>.
<P><LI><A NAME="LIWQ525"></A><B>(Optional)</B> If you intend to remove groups that the
user owns from the Protection Database after removing the user's entry,
issue the <B>pts listowned</B> command to display them. For
complete instructions, see <A HREF="auagd019.htm#HDRWQ536">Displaying Information from the Protection Database</A>.
<PRE> % <B>pts listowned</B> &lt;<VAR>user&nbsp;or&nbsp;group&nbsp;name&nbsp;or&nbsp;id</VAR>>
</PRE>
<P><LI><A NAME="LIWQ526"></A>(<B>Optional)</B> Issue the <B>pts delete</B> command
to remove the groups the user owns. However, if it is likely that other
users have placed the groups on the ACLs of directories they own, it is best
not to remove them.
<PRE> % <B>pts delete</B> &lt;<VAR>user&nbsp;or&nbsp;group&nbsp;name&nbsp;or&nbsp;id</VAR>><SUP>+</SUP>
</PRE>
<P>where
<DL>
<P><DT><B>del
</B><DD>Is the shortest acceptable abbreviation for <B>delete</B>.
<P><DT><B><VAR>user or group name or id</VAR>
</B><DD>Specifies the name or AFS UID of each group displayed in the output from
Step <A HREF="#LIWQ525">4</A>.
</DL>
<A NAME="IDX7806"></A>
<A NAME="IDX7807"></A>
<A NAME="IDX7808"></A>
<P><LI>Issue the <B>kas delete</B> command to remove the user's
Authentication Database entry.
<P>The Authentication Server performs its own authentication rather than
accepting your existing AFS token. By default, it authenticates your
local (UNIX) identity, which possibly does not correspond to an AFS-privileged
administrator. Include the <B>-admin</B> argument to name an
identity that has the <TT>ADMIN</TT> flag on its Authentication Database
entry. To verify that an entry has the flag, issue the <B>kas
examine</B> command as described in <A HREF="auagd021.htm#HDRWQ590">To check if the ADMIN flag is set</A>.
<PRE> % <B>kas delete</B> &lt;<VAR>name&nbsp;of&nbsp;user</VAR>> \
<B>-admin</B> &lt;<VAR>admin&nbsp;principal&nbsp;to&nbsp;use&nbsp;for&nbsp;authentication</VAR>>
Administrator's (<VAR>admin_user</VAR>) password: <VAR>admin_password</VAR>
</PRE>
<P>where
<DL>
<P><DT><B>d
</B><DD>Is the shortest acceptable abbreviation for <B>delete</B>.
<P><DT><B><VAR>name of user</VAR>
</B><DD>Names the Authentication Database entry to delete.
<P><DT><B>-admin
</B><DD>Names an administrative account that has the <TT>ADMIN</TT> flag on its
Authentication Database entry, such as <B>admin</B>. The password
prompt echoes it as <VAR>admin_user</VAR>. Enter the appropriate password
as <VAR>admin_password</VAR>.
</DL>
<P><LI><A NAME="LIWQ527"></A>Issue the <B>vos listvldb</B> command to display the site
of the user's home volume in preparation for removing it. By
convention, user volumes are named
<B>user</B>.<VAR>username</VAR>.
<PRE> % <B>vos listvldb</B> &lt;<VAR>volume&nbsp;name&nbsp;or&nbsp;ID</VAR>>
</PRE>
<P>where
<DL>
<P><DT><B>listvl
</B><DD>Is the shortest acceptable abbreviation of <B>listvldb</B>.
<P><DT><B><VAR>volume name or ID</VAR>
</B><DD>Specifies the volume's name or volume ID number.
</DL>
<A NAME="IDX7809"></A>
<A NAME="IDX7810"></A>
<A NAME="IDX7811"></A>
<A NAME="IDX7812"></A>
<P><LI><A NAME="LIWQ528"></A>Issue the <B>vos remove</B> command to remove the
user's volume. It automatically removes the backup version of the
volume, if it exists. It is not conventional to replicate user volumes,
so the command usually also completely removes the volume's entry from
the Volume Location Database (VLDB). If there are ReadOnly replicas of
the volume, you must repeat the <B>vos remove</B> command to remove each
one individually.
<PRE> % <B>vos remove</B> &lt;<VAR>machine&nbsp;name</VAR>> &lt;<VAR>partition&nbsp;name</VAR>> &lt;<VAR>volume&nbsp;name&nbsp;or&nbsp;ID</VAR>>
</PRE>
<P>where
<DL>
<P><DT><B>remo
</B><DD>Is the shortest acceptable abbreviation of <B>remove</B>.
<P><DT><B><VAR>machine name</VAR>
</B><DD>Names the file server machine that houses the volume, as specified in the
output from Step <A HREF="#LIWQ527">7</A>.
<P><DT><B><VAR>partition name</VAR>
</B><DD>Names the partition that houses the volume, as specified in the output
from Step <A HREF="#LIWQ527">7</A>.
<P><DT><B><VAR>volume name or ID</VAR>
</B><DD>Specifies the volume's name or ID number.
</DL>
<A NAME="IDX7813"></A>
<A NAME="IDX7814"></A>
<A NAME="IDX7815"></A>
<A NAME="IDX7816"></A>
<P><LI><A NAME="LIWQ529"></A>Issue the <B>fs rmmount</B> command to remove the
volume's mount point.
<P>If you mounted the user's backup volume as a subdirectory of the home
directory, then this command is sufficient to unmount the backup version as
well. If you mounted the backup version at an unrelated location in the
filespace, repeat the <B>fs rmmount</B> command for it.
<PRE> % <B>fs rmmount</B> &lt;<VAR>directory</VAR>>
</PRE>
<P>where
<DL>
<P><DT><B>rmm
</B><DD>Is the shortest acceptable abbreviation of <B>rmmount</B>.
<P><DT><B><VAR>directory</VAR>
</B><DD>Names the mount point for the volume's previous name (the former home
directory). Partial pathnames are interpreted relative to the current
working directory.
<P>Specify the read/write path to the mount point, to avoid the failure that
results when you attempt to delete a mount point from a read-only
volume. By convention, you indicate the read/write path by placing a
period before the cell name at the pathname's second level (for example,
<B>/afs/.abc.com</B>). For further discussion of the
concept of read/write and read-only paths through the filespace, see <A HREF="auagd010.htm#HDRWQ208">Mounting Volumes</A>.
</DL>
<A NAME="IDX7817"></A>
<A NAME="IDX7818"></A>
<A NAME="IDX7819"></A>
<A NAME="IDX7820"></A>
<P><LI><A NAME="LIWQ530"></A>Issue the <B>pts delete</B> command to remove the
user's Protection Database entry. A complete description of this
command appears in Step <A HREF="#LIWQ526">5</A>.
<PRE> % <B>pts delete</B> &lt;<VAR>user&nbsp;or&nbsp;group&nbsp;name&nbsp;or&nbsp;id</VAR>>
</PRE>
<P><LI>If the deleted user home directory resided in a replicated volume, use the
<B>vos release</B> command to release the volume, as described in <A HREF="auagd010.htm#HDRWQ194">To replicate a read/write volume (create a read-only volume)</A>.
<PRE>
% <B>vos release</B> &lt;<VAR>volume&nbsp;name&nbsp;or&nbsp;ID</VAR>>
</PRE>
<TABLE><TR><TD ALIGN="LEFT" VALIGN="TOP"><B>Note:</B></TD><TD ALIGN="LEFT" VALIGN="TOP">This step can be necessary even if the home directory's parent directory
is not itself a mount point for a replicated volume (and is easier to overlook
in that case). For example, the ABC Corporation template puts the mount
points for user volumes in the <B>/afs/abc.com/usr</B>
directory. Because that is a regular directory rather than a mount
point, it resides in the <B>root.cell</B> volume mounted at the
<B>/afs/abc.com</B> directory. That volume is replicated, so
after changing it by deleting a mount point the administrator must issue the
<B>vos release</B> command.
</TD></TR></TABLE>
</OL>
<HR><P ALIGN="center"> <A HREF="../index.htm"><IMG SRC="../books.gif" BORDER="0" ALT="[Return to Library]"></A> <A HREF="auagd002.htm#ToC"><IMG SRC="../toc.gif" BORDER="0" ALT="[Contents]"></A> <A HREF="auagd017.htm"><IMG SRC="../prev.gif" BORDER="0" ALT="[Previous Topic]"></A> <A HREF="#Top_Of_Page"><IMG SRC="../top.gif" BORDER="0" ALT="[Top of Topic]"></A> <A HREF="auagd019.htm"><IMG SRC="../next.gif" BORDER="0" ALT="[Next Topic]"></A> <A HREF="auagd026.htm#HDRINDEX"><IMG SRC="../index.gif" BORDER="0" ALT="[Index]"></A> <P>
<!-- Begin Footer Records ========================================== -->
<P><HR><B>
<br>&#169; <A HREF="http://www.ibm.com/">IBM Corporation 2000.</A> All Rights Reserved
</B>
<!-- End Footer Records ============================================ -->
<A NAME="Bot_Of_Page"></A>
</BODY></HTML>