| Creating Local Password File Entries | ||
|---|---|---|
 | Chapter 12. Administering User Accounts |  |
| Creating Local Password File Entries | ||
|---|---|---|
| | Chapter 12. Administering User Accounts | |
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 (/etc/passwd 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.
One reason to use uss commands is that they enable you to generate local password file entries automatically as part of account creation. See Creating a Common Source Password File.
Information similar to the information in this section appears in a corresponding section of Creating and Deleting User Accounts with the uss Command Suite, but is repeated here for your convenience
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.
The most basic reason to make AFS and UNIX UIDs the same is so that the owner name reported by the UNIX ls -l and ls -ld 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 ls -l 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 ls -l 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.
Follow the recommendations in the indicated sections to make AFS and UNIX UIDs match when creating accounts for various types of users:
If creating an AFS account for a user who already has a UNIX UID, see Making UNIX and AFS UIDs Match.
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 max user id counter higher than
the largest UNIX UID, using the instructions in Displaying and Setting the AFS UID and GID
Counters.
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 max user id
counter.
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:
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.
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 X or other character is the most easily recognizable way to do this.
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 (passwd or equivalent).
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 klog 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.
| |  | |
| The Components of an AFS User Account |  | Converting Existing UNIX Accounts |