Home > Unix(*nix) > Kerberos Realms Usage

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.
Categories: Unix(*nix) Tags: ,
Comments are closed.