I agree, Tim: Being able to store one host's keys in different realms would be nice - in my simple opinion.
I think you understand my question exactly - your example is just what I'm trying to do. Unfortunately, I still don't know how to do it. Truly, the confusing part is how the kerberos client obtains a cross realm TGT for the correct realm.
Since your example is precisely what I'm trying to do, suppose I'm connecting to service2 on server1.domain.com - my principle resides in REALM0, say. How does my kerberos client know whether to request a cross realm TGT for REALM1, 2, or 3? It seems domain_realm will only map server1.domain.com - and all of its instances - to one realm ...
I'd be very happy to find a way around this!
Jack
On Mar 9, 2004, at 9:36 AM, Tim Alsop wrote:
Hi,
Perhaps I missunderstand the question, but it is possible to use multiple realms on a specific host. The naming of the service principals (keys for which would be stored in a key table) would look something like :
host/[EMAIL PROTECTED] service1/[EMAIL PROTECTED] service2/[EMAIL PROTECTED] service3/[EMAIL PROTECTED]
Essentially, the key in the key table which would be acquired by a specific application (a Kerberos service) maintains the shared-secret between the service and the realm.
A user can be in one realm with one password. The services can be in multiple realms. When an application is run by a user and requests a service ticket it will get the ticket from the appropriate KDC for the realm.
The part which is perhaps a little confusing is the approach used by a kerberos client to determine the KDC that issues the service ticket. Normally, the service ticket request is sent to the realm where the initial user's ticket (tgt) was issued, and then a cross realm tgt is returned for the service realm so that a service ticket can then be requested from the correct realm. The service ticket is then sent to the service and decrypted with the key in the key table in order to determine the principal name of the user.
So, in summary - having multiple realms works well, but is more complex. The simplest approach is to use one realm for everthing, but this does not have the granularity that some implementations require. It is nice to have the option to use either approach to protect multiple applications on a specific host !!
Regards, Tim.
-----Original Message----- From: Sam Hartman [mailto:[EMAIL PROTECTED] Sent: 09 March 2004 17:09 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Different Services, Different Realms, but One Host
>>>>> "ms419" == ms419� <[EMAIL PROTECTED]> writes:
��� ms419> Pardon this newbish question, but here's the setup: I want ��� ms419> to distribute the keys for one host among two ��� ms419> realms. Basically, I've got a sensitive service running on ��� ms419> a couple of hosts, and a less secure service running on the ��� ms419> same hosts. I want to store the keys for the sensitive ��� ms419> service in one realm, and the keys for the others in ��� ms419> another. Any problems with these premises?
Yes.� Current Kerberos implementations assume a host belongs to one realm.� You'll find it difficult to actually do this.
Also, users will end up having multiple passwords which will be annoying.
I recommend having one KDC which is more secure than your most sensitive service.
________________________________________________ Kerberos mailing list���������� [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
