Capitan Holy Hippie's ramblings

About a year ago, I wrote a whitepaper on doing Kerberos authentication with Access Manager and posted it here in my blog. Since then, the one question that has come up that I haven't been able to answer easily is: "What about cross-realm authentication?"

The problem would be like this: Imagine that you have two Kerberos realms deployed, HOLYHIPPIE.COM and CATNIPCOAST.COM. (These realm names are taken from real DNS domains I personally own.) A user is in the CATNIPCOAST.COM realm, and the Access Manager server is in the HOLYHIPPIE.COM realm. Can the user authenticate to the Access Manager server?

My answer was "Sure, there's nothing that prevents this, it's merely a matter of configuration." However, for a long time I didn't test it out (not having the test environment set up, and I'm not really paying attention to Access Manager anymore.) My curiosity finally got the better of me, and I did a quick test setup, and came to the answer - of course, it works just fine.

So, my test environment consists of two Solaris 10 servers, both acting as Kerberos KDC's using the KDC that ships with Solaris. (icebox65.catnipcoast.com and icebox75.holyhippie.com - in reality these two hosts are just zones running on one machine.) icebox75 is also running Access Manager 7. Clients are anything I can get my hands on to test with, which so far is just my laptop running Mac OS X 10.4.6, and a Ultra 60 running Solaris 10. Right now, I'm completely Windows-free, I have no machines with a working Windows install.

In order to get an understanding of why and how this works, a short trek through Kerberos principals, realm to host name mapping, and cross-realm authentication is in order.

Kerberos uses something called a principal to identify every entity that uses the Kerberos system to authenticate. Users are the first thing that you will think of in the Kerberos system, and every user has a principal in the form of "userid@REALM". However, users aren't the only type of principal in Kerberos, there also service principals, or principals in the form of "service/host@REALM". There are a class of principals for Kerberos administrative tasks and changing passwords. Finally, there are principals for the ticket granting service itself, or principals in the form of "krbtgt/REALM@REALM".

When a user authenticates themselves to the Kerberos service, the first thing they get is a ticket for the Ticket Granting Service. Or, user principal "hippie@CATNIPCOAST.COM" will get a ticket for the service principal "krbtgt/CATNIPCOAST.COM@CATNIPCOAST.COM". Then, every time the user wants to access a service (like the login service on a workstation, or a mail service, or a web service), the user goes to the Kerberos ticket granting service, and asks for a ticket for the service principal of the service they want to access. All these principals are formed using standard rules, so the user's doesn't need to know them ahead of time.

Logging into a host with Kerberos means the user gets a ticket for "host/hostname.domain@REALM". Logging into Access Manager means that the user gets a ticket for "HTTP/hostname.domain@REALM".

So, at this point, I can describe the original problem again, in a bit different way - Imagine that I am logged into the CATNIPCOAST.COM realm as principal "hippie@CATNIPCOAST.COM". I want to access the web service on icebox75.holyhippie.com. The rules I've described so far say that what my client software would do is ask the ticket granting service for a ticket to give to principal "HTTP/icebox75.holyhippie.com@CATNIPCOAST.COM". That won't work, since no such principal exists - the web service on icebox75.holyhippie.com has a principal of "HTTP/icebox75.holyhippie.com@HOLYHIPPIE.COM".

Kerberos uses DNS domains, and a local configuration file to map servers into a realm. This is done through a configuration section like this:


[domain_realm]
.catnipcoast.com = CATNIPCOAST.COM
.holyhippie.com = HOLYHIPPIE.COM


Then, there are other sections in the local configuration file that tell the client about where the KDC is for each realm.

Now my Kerberos client has enough configuration to realize that the principal it really wants is "HTTP/icebox75.holyhippie.com@HOLYHIPPIE.COM". The next problem is getting a ticket for that - it can't just go straight to the KDC for the HOLYHIPPIE.COM realm, and the KDC for the CATNIPCOAST.COM realm can't give out ticket for that principal.

Kerberos defines a way to bridge between realms using a special set of principals that you define in the KDC for each realm. I've already mentioned the special service principal "krbtgt/CATNIPCOAST.COM@CATNIPCOAST.COM", what needs to be done now is to have a pair of principals defined "krbtgt/HOLYHIPPIE.COM@CATNIPCOAST.COM" and "krbtgt/CATNIPCOAST.COM@HOLYHIPPIE.COM", and these principals need to be set up in both KDC servers with the same password in each.

Enough configuration has been done in the server, so here is what the client does. When it realizes that it wants to get a ticket for "HTTP/icebox75.holyhippie.com@HOLYHIPPIE.COM", it first asks the KDC for the CATNIPCOAST.COM realm for a ticket for "krbtgt/HOLYHIPPIE.COM@CATNIPCOAST.COM". Then, it contacts the KDC for the HOLYHIPPIE.COM realm, presents the ticket for "krbtgt/HOLYHIPPIE.COM@CATNIPCOAST.COM", and asks for a ticket for "HTTP/icebox75.holyhippie.com@HOLYHIPPIE.COM". The HOLYHIPPIE.COM KDC knows that the only way the client could have gotten the "krbtgt/HOLYHIPPIE.COM@CATNIPCOAST.COM" ticket is from the KDC at CATNIPCOAST.COM, so it hands out the ticket the client requested.

Finally! The web browser client takes this ticket, hands it to the web service at icebox75.holyhippie.com (which in this case happens to be Access Manager 7). The web service has no problem validating the ticket, and isn't bothered by the realm of the user principal being different. Now, Access Manager needs to find the user in it's LDAP user database.

Now we get into a whole different set of configuration issues. First, I'm going to establish some terminology - Access Manager 7 uses the term "realm" in a similar way to Kerberos. However, I'm not going to use that term, instead I'm going to use "organization", which is the term Access Manager 6.3 used.

Access Manager can handle multiple organizations in the LDAP server, where each organization has different users, and two users in different organizations can have the same userid. The authentication service in Access Manager isn't that great when it comes to selecting an organization to search for a user to authenticate, as it really requires that decision to have been made before an authentication module is invoked. It can't invoke a authentication module, then use information returned from that authentication module to select an organization. So, this limits our choices as to how to use multi-realm Kerberos authentication with Access Manager - the easiest way to do this is to put all users in one Access Manager organization, and use the fully qualified principal to find the specific LDAP user to authenticate, and to store that fully qualified principal in a attribute in the users entry dedicated for that purpose. Access Manager can be configured to do this, but it isn't the default behavior. Another approach would be to have a one to one mapping of Kerberos realms to Access Manager organizations, but this would require that clients in each Kerberos realm use a different URL to access the Access Manager login service. This works the smoothest with how Access Manager likes to work, but isn't a practical solution. The only way to really make it work is to insert some web forms in front of Access Manager's login module to give the user a choice of which organization they belong to - which completely breaks the value of using Kerberos authentication with Access Manager.
A couple final comments on clients - in my testing I've tried Firefox on Solaris 10 and Mac OS X, and Safari on Mac OS X. Safari 2.0.3 worked perfectly. Firefox 1.0.4 on Solaris 10 worked perfectly. Firefox 1.5.0.1 on Mac OS X did not work at all - and the reason why is a bit strange.

In order to do my testing, I grabbed a couple of zones on a machine in my lab on Sun's internal network. I set up the icebox65.catnipcoast.com and icebox75.holyhippie.com names on my external DNS to point to the IP addresses of those machines on the internal network. All this is fine so far.

Some applications like to get the IP address of a host, then do a reverse lookup of that address, and see what the hostname is as a result. If you do that on Sun's internal network, with the IP addresses of my lab machines, what you get is icebox65.red.iplanet.com and icebox75.red.iplanet.com.

Firefox 1.5.0.1 on Mac OS X seems to insist on doing this when it looks up the service principal for a Kerberos ticket, so it was looking for a principal "HTTP/icebox75.red.iplanet.com@HOLYHIPPIE.COM", even though I was trying to access the website icebox75.holyhippie.com. This is probably a bug in this version of Firefox.

Like I've said before, I don't do Windows, so I have no idea how this works (or doesn't) with Internet Explorer.