X-Git-Url: https://git.openafs.org/?p=openafs.git;a=blobdiff_plain;f=doc%2Fxml%2FAdminGuide%2Fauagd014.xml;h=70dbde2a9c3a700623597709052d0ea08db031b0;hp=961181a285f873becc04b67710c9134fabf19ffa;hb=2f435309c75dfd8ffe0cfb3e1a54749437cba3be;hpb=da9f42d044725ae128feffcfbeaab67b31aaab44 diff --git a/doc/xml/AdminGuide/auagd014.xml b/doc/xml/AdminGuide/auagd014.xml index 961181a..70dbde2 100644 --- a/doc/xml/AdminGuide/auagd014.xml +++ b/doc/xml/AdminGuide/auagd014.xml @@ -1095,158 +1095,27 @@ Database and the KeyFile file on every server machine, so that the TGS and all server processes again share the same key. - Handling key emergencies requires some unusual actions. The reasons for these actions are explained in the following - sections; the actual procedures appear in the subsequent instructions. - - - Prevent Mutual Authentication - - It is necessary to prevent the server processes from trying to mutually authenticate with you as you deal with a key - emergency, because they possibly cannot decrypt your token. When you do not mutually authenticate, the server processes assign - you the identity anonymous. To prevent mutual authentication, use the unlog command to discard your tokens and include the -noauth flag on - every command where it is available. - - - - Disable Authorization Checking by Hand - - Because the server processes recognize you as the user anonymous when you do not - mutually authenticate, you must turn off authorization checking. Only with authorization checking disabled do the server - processes allow the anonymous user to perform privileged actions such as key creation. - - In an emergency, disable authorization checking by creating the file /usr/afs/local/NoAuth by hand. In normal circumstances, use the bos - setauth command instead. - - - - Work Quickly on Each Machine - - Disabling authorization checking is a serious security exposure, because server processes on the affected machine - perform any action for anyone. Disable authorization checking only for as long as necessary, completing all steps in an - uninterrupted session and as quickly as possible. - - - - Work at the Console - - Working at the console of each server machine on which you disable authorization checking ensures that no one else logs - onto the console while you are working there. It does not prevent others from connecting to the machine remotely (using the - telnet program, for example), which is why it is important to work quickly. The only way to - ensure complete security is to disable network traffic, which is not a viable option in many environments. You can improve - security in general by limiting the number of people who can connect remotely to your server machines at any time, as - recommended in Improving Security in Your Cell. - - - - Change Individual KeyFile Files - - If you use the Update Server to distribute the contents of the /usr/afs/etc directory, - an emergency is the only time when it is appropriate to change the KeyFile file on individual - machines instead. Updating each machine's file is necessary because mismatched keys can prevent the system control machine's - upserver process from mutually authenticating with upclientetc processes on other server machines, in which case the upserver process refuses to distribute its KeyFile file to - them. - - Even if it appears that the Update Server is working correctly, the only way to verify that is to change the key on the - system control machine and wait the standard delay period to see if the upclientetc processes - retrieve the key. During an emergency, it does not usually make sense to wait the standard delay period. It is more efficient - simply to update the file on each server machine separately. Also, even if the Update Server can distribute the file - correctly, other processes can have trouble because of mismatched keys. The following instructions add the new key file on the - system control machine first. If the Update Server is working, then it is distributing the same change as you are making on - each server machine individually. - - If your cell does not use the Update Server or you always change keys on server - machines individually. The following instructions are also appropriate for you. - - - - Two Component Procedures - - There are two subprocedures used frequently in the following instructions: disabling authorization checking and - reenabling it. For the sake of clarity, the procedures are detailed here; the instructions refer to them as necessary. - - - Disabling Authorization Checking in an Emergency - - - - Become the local superuser root on the machine, if you are not already, by - issuing the su command. - % su root - Password: <root_password> - - - - NoAuth file - - creating in emergencies - - - - - Create the file /usr/afs/local/NoAuth to disable - authorization checking. - # touch /usr/afs/local/NoAuth - - - - unlog command - - when handling key emergency - - - - - Discard your tokens, in case they were sealed with an incompatible key, which can prevent some commands from - executing. - # unlog - - - - - - - Reenabling Authorization Checking in an Emergency - - - - Become the local superuser root on the machine, if you are not already, by - issuing the su command. - % su root - Password: <root_password> - - - - - Remove the /usr/afs/local/NoAuth file. - # rm /usr/afs/local/NoAuth - - - - klog command - - when handling key emergency - - - - - Authenticate as an administrative identity that belongs to the system:administrators group and is listed in the /usr/afs/etc/UserList file. - # klog <admin_user> - Password: <admin_password> - - - - - If appropriate, log out from the console (or close the remote connection you are using), after issuing the - unlog command to destroy your tokens. - - - + Installing a new server encryption key involves logging in to each + server machine as root and confirming that the correct (i.e., new) key + are in place in the KeyFileExt or + rxkad.keytab (for OpenAFS 1.8.x + releases). The same keys must be installed on all servers in the cell, + and when Kerberos is used for authentication, must match the key in the + Kerberos database. + + While the keys are being installed, remote operations using + regular authentication mechanisms, even with administrator credentials, + may (continue to) fail. Similarly, the ubik synchronization protocol + among database servers may fail to synchronize due to the servers not + being able to authenticate each other, making write operations to the + database impossible. In order to interact with individual server + processes, the -localauth flag is used, + allowing commands that are run on a system that has the cell's key (such + as the server itself) to successfully authenticate as an administrator. + Once the new keys are installed on all database servers and the + 90-second ubik recovery time has passed, the database servers should have + elected a new coordinator, allowing write transactions to proceed + again.