2

Two typical forms for Kerberos (v5) principal names seem to be:

username[/instance]@REALM
service/fully-qualified-domain-name@REALM

I've also seen something like this for services which could exist on multiple ports:

service/fully-qualified-domain-name:port@REALM

I have an in-house application which is now being Kerberized, and would like to understand how the service principal(s) should be named. The service is distributed, with several instances running on each of several machines in each of several sub-domains.

For example, let's say my domain name is zombo.com, and my Kerberized service, "tenaciousd", runs on machines "www1" through "www5". Further, each machine has ten instances on well-known ports, say 25001 through 25010.

So I have fifty instances of the server, all basically the same, which lets me balance load, deploy new versions gradually, and so on.

Now, how should I name the service principal(s) in Kerberos? Should there be one for each host running the service, as there would be in what seems the most common form?

tenaciousd/www1.zombo.com@ZOMBO.COM
tenaciousd/www2.zombo.com@ZOMBO.COM
tenaciousd/www3.zombo.com@ZOMBO.COM
tenaciousd/www4.zombo.com@ZOMBO.COM
tenaciousd/www5.zombo.com@ZOMBO.COM

Or is it better practice (and why) to have one service principal per service instance?

tenaciousd/www1.zombo.com:25001@ZOMBO.COM
tenaciousd/www1.zombo.com:25002@ZOMBO.COM
tenaciousd/www1.zombo.com:25003@ZOMBO.COM
...
tenaciousd/www5.zombo.com:25010@ZOMBO.COM

Finally, what about having just one service principal, which seems simpler but less commonly done?

tenaciousd@ZOMBO.COM

If it matters, the Kerberized service (and clients) use Cyrus SASL, GNU GSSAPI, and MIT Kerberos 5. The SASL API takes a "fully-qualified domain name" parameter in addition to the service name, but I suspect that's because it supports more than just Kerberos, and we could probably pass things other than actual FQDNs.

Most of the documentation I've found assumes that each service runs on a single host in a realm, or at least that clients care deeply which service instance they connect to. In my case the services are all pretty much the same from the client's perspective, so what would be the best practice here?

John Zwinck
  • 281
  • 2
  • 4
  • 17

1 Answers1

2

For things that are not unique (that is, replicated services, performing exactly the same duties) I usually share one common server principal. This works well if external entities see the same domain name for instance, as it maintains that illusion.

It also means that if a user switches from instance-1 to instance-49 they won't have to perform another Kerberos handshake, as they already have a valid, working ticket. They will use that ticket to authenticate to any of the instances without needing to fetch a new one per instance.

Thus, I would use:

tenaciousd/www.example.com@EXAMPLE.COM

as your principal name for this service, assuming www.example.com is how this service is addressed by clients.

Michael Graff
  • 6,588
  • 1
  • 23
  • 36
  • Clients (which are on the local network, not external at all) access the services explicitly with a hostname and port (each client instance is configured to use a specific service). Does that change things any? There really is no "canonical" hostname to use in my case, as it's not really www1-9, but rather a collection of hosts I happen to run the Kerberized service on. – John Zwinck Jan 24 '10 at 22:31
  • 1
    Then yes, I would issue a unique principal to each instance. I tend to choose based on how the client sees the world, and if it sees each individual host, then I'd do it the likely harder but more correct way. – Michael Graff Jan 25 '10 at 06:02