Using Root Instance of Your Kerberos Principal
Intended for:
Kerberos users.
Scenario/Use case:
This article provides instructions on how to use the root instance of your Kerberos principal.
Instructions:
What is a root instance of a principal?
A Kerberos principal has three parts and is of the form primary/instance@REALM. For a user, the instance portion is generally null, and the principal is of the form primary@REALM. If the instance is not null, the instance portion gives information that qualifies the primary, and is generally used to describe the intended use of the corresponding credentials. The root instance of a principal is also called a /root principal. The word root in <username>/root@FNAL.GOV need not have anything to do with the UNIX root account, although that is presumed to be one of the most common uses. All /root principals are created with the DISALLOW_FORWARDABLE flag set so that tickets are always unforwardable. The tickets also have a shorter default lifetime.
A root instance of your principal is only useful if your system administrator wants to make use of its restrictive ticket properties to protect sensitive accounts. Typically these accounts are set up with a .k5login file containing only /root principals. Your system administrator should inform you if you need to obtain a /root principal.
How do you use your /root principal?
To connect to such an account via a network connection from your desktop, you need to first kinit on your local machine as <user>/root (we use me/root as an example) and specify "nonforwardable ticket" with the -F flag (if the Kerberos configuration file /etc/krb5.conf specifies forwarding "on" and you leave off the -F, you'll get an error):
% kinit -F me/root[@FNAL.GOV]
Now, connect to the sensitive account on the remote host using all of the options shown here:
% ssh -k -l <sensitive_account_name> <remote_host>
where:
- - tells the program not to forward tickets (you'll get an error if you fail to include this).
- -l <sensitive_account_name> logs you in directly to the named account. If you didn't include this, the remote host would try to log you into an account with the same name as your local UNIX username.
Note that once you're logged in remotely, you have no tickets. You cannot use any Kerberized services from here to connect to other accounts or machines.
How should you NOT use it?
There are some limitations associated with the use of /root principals for access to privileged accounts, and that is why their use is not mandatory.
- You can't use ksu (or other Kerberized client) on a remote machine under your /root principal because you don't have tickets on that machine.
- Never type your /root principal password over the network except on rare, necessary occasions and only on an encrypted connection; always authenticate on your desktop machine.
How do you maintain credentials for your normal principal while using the /root principal?
To maintain tickets on your desktop machine for both instances of your principal, you must keep the ticket caches separate. First, authenticate under your normal principal, e.g.,:
% kinit [me[@FNAL.GOV]]
This gets you a ticket cache in the default area. You may find it useful to pick one of your local xterm windows to use for your /root principal (maybe give it a special title bar or color) and set a separate ticket cache file there. In that window, reset the environment variable KRB5CCNAME to a location for the /root principal ticket cache, then authenticate under your /root principal to get (nonforwardable) tickets for this instance without overwriting the ones you got as "yourself":
% setenv KRB5CCNAME /tmp/krb5cc_me_root_$$ % kinit -F me/root[@FNAL.GOV]
When you request a Kerberized service, Kerberos will look at the credential cache to which KRB5CCNAME points, and assume that the principal holding this cache is the requestor. Reset this variable to the other cache as necessary.
See Also: