Kerberos Realms Usage
November 18th, 2010
In order to authenticate against Kerberos realms and perform remote administration, the system must have the krb5-workstation package installed.
Adding principals with kadmin
Use kadmin to add and manage principals. The example below creates a principal for testuser@MYREALM:
[root@kdc ~]# /usr/kerberos/sbin/kadmin -p root/admin@MYREALM \
-q 'add_principal testuser@MYREALM'
Authenticating as principal root/admin@MYREALM with password.
Password for root/admin@MYREALM:principalpass
WARNING: no policy specified for testuser@MYREALM; defaulting to no policy
Enter password for principal "testuser@MYREALM":testuser
Re-enter password for principal "testuser@MYREALM":testuser
Principal "testuser@MYREALM" created.
[root@kdc ~]#
Note: The password for the root/admin@MYREALM principal was defined at the time of it’s creation in the previous subsection.
Authenticating a principal
Use kinit to request a Ticket-Granting Ticket (TGT), klist to list current tickets, and kdestroy to destroy the credential cache:
[root@host ~]# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@host ~]# kinit testuser@MYREALM Password for testuser@MYREALM:principalpass [root@host ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: testuser@MYREALM Valid starting Expires Service principal 10/03/08 09:34:06 10/04/08 09:34:06 krbtgt/MYREALM@MYREALM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@host ~]# kdestroy [root@host ~]# klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_0) Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached [root@host ~]#
Note: The password for the testuser@MYREALM principal was defined in the previous section. The example above can be executed on any host that was previously configured as a client for the MYREALM realm.
Configuring the system for Single Sign-on using Kerberos
The configuration for a Single Sign-on solution using Kerberos is not the primary objective of this writing, but there are a few points that are worth noting when pursuing such environment, listed:
- For complete instructions, refer to the RedHat Enterprise Linux 5 Deployment Guide, section 42.6.6 – Configuring a Kerberos 5 Client onwards (http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/s1-kerberos-clients.html)
- Kerberos passwords (or keys) are independent of the standard Unix password database (/etc/passwd or /etc/shadow). There is generally no automated way of migrating between each other.
- The best way of implementing Single Sign-on is by using the pam_krb5. so PAM module (provided in the pam_krb5 package). The pam_krb5 module can be both stacked as sufficient authentication with other authentication modules or enforced as required authentication. By authenticating against pam_krb5, the user should receive valid Kerberos credentials which will be cached per-session in the client (as if kinit was invoked).
- In a Kerberos Single Sign-on environment, it is of utter importance that the users are not allowed to perform authentication (using their Kerberos password) in non-Kerberos systems, such as telnet and ftp. Instead, the Kerberized versions for these basic services (bundled with the krb5-workstation package) should be used.
- For other services such as SSH and IMAP, use the GSS (General Security Services) enabled servers. SSH in particular needs GSS-API enabled in both client and server configurations, and the ability to reverse-resolve IP addresses to hostnames.
Parent topic: Setting up the Kerberos KDC Server
