The Blog of Ben Rockwood

Simplifying Zone Management with Kerberos

10 Oct '05 - 23:29 by benr

Previously we discussed how to employ NIS and AutoFS to simplify zone management. By leveraging NIS and AutoFS we reduced the administrative hassle involved in managing large numbers of zones. But we can employ yet another technology to simplify our lives: Kerberos.

So what is Kerberos? You've probly heard about it but maybe you've never had time to try it out, or even more likely, you never had a use for it or enough systems to test an implementation. Besides being a mythical three headed puppy, Kerberos is a network authentication protocol. Kerberos was developed in the late 80's for MIT's infamous Project Athena, debuting as Kerberos 4. In 1993 Kerberos Version 5 came about and is what we continue to use today (some changes were made this in July of this year). Kerberos set out to solve a very real problem in a large enviroment: how do you centralize authentication and secure applications? Everyone knows why you shouldn't use Telnet, non-anonymous FTP, RSH, and Rlogin... your sending your username and password as cleartext. If you've only been using UNIX systems for 5 years or so, you probly are thinking "Ya.. duh, thats what SSH is for." But we haven't always had SSH. What Kerberos did for the world was to centralize authentication by issueing secure tickets to clients and allowing those tickets to follow you from machine to machine, as well as encrypting the communication itself. Using Keberos you can (using a "Kerberized" daemon and client) telnet, ftp, rsh, rlogin, etc, without having to login and without fear of snoopers. Because Kerberos has been around so long its avalible out of the box on just about every OS I know of, making its implementation very easy.

Some of the advantages of Kerberos include:

Single-Sign-On: Enter your password once and roam the network without repeating login and password information. No passwords, just telnet (or rsh, or ftp, even ssh, etc.) and go.
Secure Authentication: All authentication is encrypted. No more cleartext passwords flying across your network.
Session Integrity: Data transmissions can be integrity-protected by cryptographic checksum.
Encrypted Sessions: Data transmissions can be confidentiality-protected and integrity-protected by encryption.

When communicating between zones on a Solaris system all communication occurs across the loopback interface and never touches the wire. Because of this we're not interested in session integrity or encrypted sessions, both of these would simply chew up CPU time to encrypt and decrypt data that no one could see anyway. This is one of the reasons that SSH isn't a good choice for inter-zone connections.

Single-Sign-On is what we want. With that enabled we can spend less time logging in and more time working, creating a completely seemless experience. To do this we need to create a Kerberos Key Distribution Center (KDC) in our global zone and then configure each zone as a client.

Before I continue, I should point out that the Solaris distribution of Kerberos 5 is known as SEAM: “Sun Enterprise Authentication Mechanism”. You can use the terms "SEAM" and "Kerberos" effectively interchangably. In all cases below, when I say Kerberos, I actually am refering to SEAM on Solaris 10/OpenSolaris.

Basic Concepts:

If your new to Kerberos you'll need to learn some basic terminology and concepts before we begin.

Realm: The Kerberos equivilent of a domain, comprised of one or more KDCs and any number of Kerberos clients.
KDC: The Key Distribution Center, the heart of your Kerberos Realm. By way of propigation you can setup multiple KDC's (one master, multiple slaves) for redundancy.
Ticket: A temporary set of credentials that are passed across the network when preforming remote authentication.
TGT: Ticket-Granting Ticket, one that allows additional tickets (that would be used for remote authentication) without having to apply (re-authenticate to the KDC) for it.
Principal: A named user, host, or service within a realm in the form name@REALM, for instance benr@KUDDLE, or host/anysystem@REALM, or telnet/anysystem@REALM.
Admin Principal: A pricipal with administrative privs within a realm, in the form user/admin@REALM, for instance benr/admin@KUDDLE.
Keytab: A file that includes an unencrypted list of principals and their keys. Two keytabs are commonly used on the KDC: one for the administrative server (/etc/krb5/kadm5.keytab) and the Kerberos default (/etc/krb5/krb5.keytab).

To implement Kerberos we first need to setup two services in our global zone (this could actually be done anywhere, but I do it in the global zone): the KDC, which distributes keys, and Kadmin which is the interface for managaing Kerberos to add/remove principles, etc.

Configuring the KDC in the Global Zone

Note: In the following examples a hash prompt (#) denotes actions performed as root, whereas a dollar prompt ($) denotes actions performed as a regular user.

Start by ensuring that the Kerberos daemons aren't currently running:

# svcs krb5kdc kadmin
STATE          STIME    FMRI
disabled        3:43:46 svc:/network/security/krb5kdc:default
disabled        3:43:46 svc:/network/security/kadmin:default

In /etc/krb5/ edit krb5.conf, kdc.conf, and kadm5.acl. In each file change "___default_realm___" to the name you've chosen for your realm (typically your domain name, but you can use anything, realm names are always in caps). Also change "___master_kdc___" to the hostname of your KDC, in our case this would be the hostname of your global zone.

Typically Kerberos is used in conjunction with DNS, however it doesn't have to be. On my systems I use a host name (supplied by either /etc, or NIS) instead of a fully qualified DNS name. If you do not use DNS however, please note that the hostname you supply as your master_kdc must be the first hostname on the host line, if its not you'll get an error when creating the databases. For this example, I'll use the realm "CUDDLETECH" and the master_kdc "anysystem".

If you are not using Kerberos in conjunction with DNS, please remove the entire [domain_realm] section.

An example of my krb5.conf:

[libdefaults]
        default_realm = CUDDLETECH

[realms]
        CUDDLETECH = {
                kdc = anysystem
                admin_server = anysystem
        }

[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log
        kdc_rotate = {
                period = 1d
                versions = 10
        }

[appdefaults]
        kinit = {
                renewable = true
                forwardable= true
        }
        gkadmin = {
                help_url = http://docs.sun.com:80/ab2/coll.384.1/SEAM/@AB2PageView/1195
        }

An example of my kadm5.acl:

*/admin@CUDDLETECH *

An example of my kdc.conf:

[kdcdefaults]
        kdc_ports = 88,750

[realms]
        CUDDLETECH = {
                profile = /etc/krb5/krb5.conf
                database_name = /var/krb5/principal
                admin_keytab = /etc/krb5/kadm5.keytab
                acl_file = /etc/krb5/kadm5.acl
                kadmind_port = 749
                max_life = 8h 0m 0s
                max_renewable_life = 7d 0h 0m 0s
                default_principal_flags = +preauth
        }

Initialize the Kerberos database using kdb5_util:

# kdb5_util create -s

Initializing database '/var/krb5/principal' for realm 'CUDDLETECH',
master key name 'K/M@CUDDLETECH'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: (pass)
Re-enter KDC database master key to verify: (pass)

The databases and Kerberos KDC log are stored in /var/krb5.

Create a principle for yourself:

# kadmin.local

Authenticating as principal benr/admin@CUDDLETECH with password.

kadmin.local:   addprinc benr/admin
WARNING: no policy specified for benr/admin@CUDDLETECH; defaulting to no policy
Enter password for principal "benr/admin@CUDDLETECH": (pass)
Re-enter password for principal "benr/admin@CUDDLETECH": (pass)
Principal "benr/admin@CUDDLETECH" created.

Add Kadmin keytab entries for "kadmin/(admin_host)" and "kadmin/changepw".
```
kadmin.local:  ktadd -k /etc/krb5/kadm5.keytab kadmin/anysystem kadmin/changepw

...
kadmin.local:  quit
```
NOTE: You will find that in many other Kerberos tutorials and books they will only add keytab entries (ktadd) for kadmin/changepw, sometimes they'll also add kadmin/admin, however almost none of them say to add a keytab entry for kadmin/(admin_host). If you fail to add this keytab entry you'll have no end of frustrating problems which generally manifests itself as a GSS-API error. You must add this entry. (I'm not sure if this is a SEAM-ism or what.) If you've tried setting up Kerberos using a non-Solaris/SEAM tutorial and had problems, this is likely the source.

You can now start the Kerberos daemons:

# svcadm enable krb5kdc kadmin

# svcs krb5kdc kadmin
STATE          STIME    FMRI
online          3:48:45 svc:/network/security/krb5kdc:default
online          3:48:45 svc:/network/security/kadmin:default

Initialize (authenticate and retrieve a TGT) for your admin principal:
```
$ kinit benr/admin
Password for benr/admin@CUDDLETECH: (pass)
```
You can use the klist command to examine the tickets you have. If you can't authenticate ensure that you properly added the two keytab entries earlier, and look at log information in both syslog (/var/adm/messages) and the KDC log (/var/krb5/kdc.log).

Create a user principal for yourself (and any other users you want to use Kerberos as well):

$ kadmin
Authenticating as principal benr/admin@CUDDLETECH with password.
Password for benr/admin@CUDDLETECH: (pass)
kadmin:  addprinc benr

...

Copy the KDC's (your globalzone's) krb5.conf to each of the zones that you'll add to your realm:
```
# cp /etc/krb5/krb5.conf /export/zones/test1/root/etc/krb5/
```
You could SSH it into the zones if you'd like but this "backdoor" method works best for me. In the example above my zones are installed in /export/zones, "test1" is the name of the zone I'm adding to the realm.
Now, login to the zone your adding to the realm (zlogin -C zone, or whichever method you like) and initialize yourself using the user pricipal you added in step 8, do this while your logged into the zone as root.
```
zone# kinit benr
Password for benr@CUDDLETECH: (pass)
```
You can check your tickets again by using the klist command. If you have problems make sure that you moved over the krb5.conf file properly and that the hostnames listed in it can be properly resolved.
Using the kadmin tool in the zone, add a host principal for the zone and then create a keytab entry for the new principal:
```
zone# kadmin
Authenticating as principal benr/admin@CUDDLETECH with password.
Password for benr/admin@CUDDLETECH: (pass)

kadmin:  addprinc -randkey host/test1
...
kadmin:  ktadd host/test1

...
kadmin:  quit
```
Two things to note here. First, we use the "-randkey" argument when adding service or host principals because we don't need to know the passwords for them, "-randkey" picks something nice and secure (ie: insanely long and complicated) for us since we don't care what it is anyway. Secondly, notice that when we added key entries (ktadd) on the KDC we specified a path, while this time we don't; thats because by default keys are added to the /etc/krb5/krb5.keytab, which is what we want in this case. In the step 5 we specifically needed to add keys into /etc/krb5/kadm5.keytab.
That's it! Now leave the zone (client) and go back to the globalzone (KDC). You can now initialize yourself as a plain ol' (non-admin) Kerberos principal and test whether things are working properly by using a Kerberized application (telnet in this case) to connect to your client zone:
```
$ kinit benr

Password for benr@CUDDLETECH: (pass)

$ telnet -a test1
Trying 10.0.0.43...
Connected to test1.
Escape character is '^]'.
[ Kerberos V5 accepts you as ``benr@CUDDLETECH'' ]
Last login: Wed Oct  5 02:45:38 from 10.0.0.42
Sun Microsystems Inc.   SunOS 5.10      Generic January 2005
zone$ 
```
You'll notice that when we telnet to the client zone we use the "-a" option, which means "automatic login". Telnet, FTP, RSH, Rlogin, and other Kerberized applications all have additional options that leverage Kerberos functionality, such as "-a" for auto-login, "-x" for encrypted sessions, etc. Please see the man page for each app to see exactly which args it takes and how to turn on and off Kerberos features.

This might look a little scary at first, but its not difficult at all. In all that we did above look at how little green there is; considering the fact that you are implementing a single-sign-on infrastructure you have to do supprisingly little typing. Never-the-less, I consider the downside to Kerberos being the fact that very rarely do the error messages make sense to anyone but a Kerberos/GSS-API guru, here is an example error message:


kadmin: GSS-API (or Kerberos) error while initializing kadmin interface

If you think that message is vauge, wait untill you see what messages it sent to the syslog. Good luck (and check your keytabs!) But short of this, Kerberos is amazingly simple to use once you've dabbled your toes in it. And it sure makes life much easier.

I encourage you to learn more about Kerberos and how to leverage all of its features and functionality. Here are some places to learn more:

Solaris 10 System Administration Guide: Security Services: Part VI Kerberos Service. The definative Solaris documentation for SEAM (Kerberos), including introduction, tasks, and error message/troubleshooting chapter. If you need help go here first.
The Sun Kerberos Page: Highly recommended.
"Kerberos Network Security and the Solaris Operating Environment": White Paper by Wyllys Ingersoll, 2001. This paper sucks ass and may confuse new Kerberos users, please refer instead to the Security Services book noted above.
The Official MIT Kerberos Page
RFC 4120: "The Kerberos Network Authentication Service (V5)", July 2005.
Kerberos Wikipedia entry: Including an excellent background on the project and links to several excellent resources.
The Moron's Guide to Kerberos
Kerberos: The Definitive Guide: Book by O'Reilly. I certainly do not consider this book "definitive" by any definition of the word, but its still a decent book to have in your library. Honestly, "The Moron's Guide" is just as good.

Side-Note for OpenSolaris Users: On several builds of OpenSolaris you'll have problems when trying to use GSS-API/Kerberos. When you look in syslog you'll see something about PKCS11, blah blah. What you need to do is edit /etc/crypto/pkcs11.conf and change "pkcs11_softtoken_extra.so" to "pkcs11_softtoken.so" (just remove the _extra). That'll solve the problem. (You probly also have seen these PKCS messages when booting... those will go away too.) Find more information about this issue in the Release Notes of your specific OpenSolaris build.

- - C O M M E N T S - -
free porn movies
free porn videos
gay porn
hairy pussy
hardcore porn
hot lesbians
hot teens
huge tits
lesbian porn
anime porn

tits (Email) (URL) - 12 June '06 - 13:58

Hi you have a nice homepage

karen (Email) (URL) - 12 June '06 - 21:33

I like your website alot…its lots of fun… you have to help me out with mine…

agueda (Email) (URL) - 13 June '06 - 00:53

I like your website alot…its lots of fun… you have to help me out with mine…

pauletta (Email) (URL) - 13 June '06 - 15:44

Your site is amaizing. Can I share some resources with you?

pennie (Email) (URL) - 13 June '06 - 15:44

Your site is amaizing. Can I share some resources with you?

christie (Email) (URL) - 13 June '06 - 18:39

Your pictures are great.

velma (Email) (URL) - 14 June '06 - 01:59