| Managing Authentication and Authorization Requirements | ||
|---|---|---|
 | Chapter 3. Administering Server Machines |  |
| Managing Authentication and Authorization Requirements | ||
|---|---|---|
| | Chapter 3. Administering Server Machines | |
This section describes how the AFS server processes guarantee that only properly authorized users perform privileged commands, by checking authorization checking and mutually authenticating with their clients. It explains how you can control authorization checking requirements on a per-machine or per-cell basis, and how to bypass mutual authentication when issuing commands.
Many AFS commands are privileged in that the AFS server process invoked by the command performs it only for a properly authorized user. The server process performs the following two tests to determine if someone is properly authorized:
In the authentication test, the server process mutually authenticates with the command interpreter, Cache Manager, or other client process that is acting on behalf of a user or application. The goal of this test is to determine who is issuing the command. The server process verifies that the issuer really is who he or she claims to be, by examining the server ticket and other components of the issuer's token. (Secondarily, it allows the client process to verify that the server process is genuine.) If the issuer has no token or otherwise fails the test, the server process assigns him or her the identity anonymous, a completely unprivileged user. For a more complete description of mutual authentication, see A More Detailed Look at Mutual Authentication.
Many individual commands enable you to bypass the authentication test by assuming the anonymous identity without even attempting to mutually authenticate. Note, however, that this is futile if the command is privileged and the server process is still performing the authorization test, because in that case the process refuses to execute privileged commands for the anonymous user.
In the authorization test, the server process determines if the issuer is authorized to use the command by consulting a list of privileged users. The goal of this test is to determine what the issuer is allowed to do. Different server processes consult different lists of users, as described in Managing Administrative Privilege. The server process refuses to execute any privileged command for an unauthorized issuer. If a command has no privilege requirements, the server process skips this step and executes and immediately.
Never place the anonymous user or the system:anyuser group on a privilege list; it makes authorization checking meaningless.
You can use the bos setauth command to control whether the server processes on a server machine check for authorization. Other server machines are not affected. Keep in mind that turning off authorization checking is a grave security risk, because the server processes on that machine perform any action for any user.
Disabling authorization checking is a serious breach of security because it means that the AFS server processes on a file server machine performs any action for any user, even the anonymous user.
The only time it is common to disable authorization checking is when installing a new file server machine (see the IBM AFS Quick Beginnings). It is necessary then because it is not possible to configure all of the necessary security mechanisms before performing other actions that normally make use of them. For greatest security, work at the console of the machine you are installing and enable authorization checking as soon as possible.
During normal operation, the only reason to disable authorization checking is if an error occurs with the server encryption keys, leaving the servers unable to authenticate users properly. For instructions on handling key-related emergencies, see Handling Server Encryption Key Emergencies.
You control authorization checking on each file server machine separately; turning it on or off on one machine does not affect the others. Because client machines generally choose a server process at random, it is hard to predict what authorization checking conditions prevail for a given command unless you make the requirement the same on all machines. To turn authorization checking on or off for the entire cell, you must repeat the appropriate command on every file server machine.
The server processes constantly monitor the directory /usr/afs/local on their local disks to determine if they need to check for authorization. If the file called NoAuth appears in that directory, then the servers do not check for authorization. When it is not present (the usual case), they perform authorization checking.
Control the presence of the NoAuth file through the BOS Server. When you disable authorization checking with the bos setauth command (or, during installation, by putting the -noauth flag on the command that starts up the BOS Server), the BOS Server creates the zero-length NoAuth file. When you reenable authorization checking, the BOS Server removes the file.
Verify that you are listed in the /usr/afs/etc/UserList file. If necessary, issue the bos listusers command, which is fully described in To display the users in the UserList file.
% bos listusers <machine name>
Issue the bos setauth command to disable authorization checking.
% bos setauth <machine name> off
where
Is the shortest acceptable abbreviation of setauth.
Specifies the file server machine on which server processes do not check for authorization.
Reenable authorization checking. (No privilege is required because the machine is not currently checking for authorization.) For detailed syntax information, see the preceding section.
% bos setauth <machine name> on
Several of the server processes allow any user (not just system administrators) to disable mutual authentication when issuing a command. The server process treats the issuer as the unauthenticated user anonymous.
The facilities for preventing mutual authentication are provided for use in emergencies (such as the key emergency discussed in Handling Server Encryption Key Emergencies). During normal circumstances, authorization checking is turned on, making it useless to prevent authentication: the server processes refuse to perform privileged commands for the user anonymous.
It can be useful to prevent authentication when authorization checking is turned off. The very act of trying to authenticate can cause problems if the server cannot understand a particular encryption key, as is likely to happen in a key emergency.
Provide the -noauth flag which is available on many of the commands in the suites. To verify that a command accepts the flag, issue the help command in its suite, or consult the command's reference page in the OpenAFS Administration Reference (the reference page also specifies the shortest acceptable abbreviation for the flag on each command). The suites' apropos and help commands do not themselves accept the flag.
You can bypass mutual authentication for all kas commands issued during an interactive session by including the -noauth flag on the kas interactive command. If you have already entered interactive mode with an authenticated identity, issue the (kas) noauthentication command to assume the anonymous identity.
| |  | |
| Maintaining the Server CellServDB File |  | Adding or Removing Disks and Partitions |