| Converting Existing UNIX Accounts | ||
|---|---|---|
 | Chapter 12. Administering User Accounts |  |
| Converting Existing UNIX Accounts | ||
|---|---|---|
| | Chapter 12. Administering User Accounts | |
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.
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:
Make the AFS UIDs match the existing UNIX UIDs. In this case, you need to assign the AFS UID yourself by including the -id argument to the pts createuser command as you create the AFS account.
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 Specifying Passwords in the Local Password File.
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
max user id counter in the Protection Database to a value higher than the largest
existing UNIX UID. See Displaying and Setting the AFS UID and GID Counters.
Change the existing UNIX UIDs to match the new AFS UIDs that the Protection Server assigns automatically.
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.
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 ls -l and ls -ld commands to display the correct owner, you must use the chown 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 Moving Local Files into AFS.
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:
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.
If the login utility is modified for use with AFS, choose one of the values discussed in Specifying Passwords in the Local Password File.
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 mv command to transfer them into the user's new AFS home directory.
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 How AFS Interprets the UNIX Mode Bits). Be sure that the ACL protects the file or directory at least as securely as the mode bits.
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 system:administrators group can issue the chown command on files and directories once they reside in AFS.
| |  | |
| Creating Local Password File Entries |  | Creating AFS User Accounts |