second keytab for similar service (but different SPN/IP) breaks the first

[Ken Raeburn]

On Jun 2, 2009, at 19:12, Chris wrote:
> So it seems that with both Active Directory's Kerberos and Open
> Directory's (MIT) Kerberos I cannot have two instances of "fooservice"
> kerberized on different IP addresses against distinct SPN's associated
> with the same service account... but there are numerous examples on
> the web of this being done e.g. with a single "http" account and
> multiple "http/ip-addr..." SPN's for multiple web servers on your
> network.
>
> Am I right in thinking what I'm trying should be possible, and if so
> is there some nuance of generating the keytab that I'm not following
> that causes the first keytab to stop working?

It sounds like it ought to work fine, in general.

Is the first machine also the KDC?  Could you perhaps be overwriting  
its keytab file when you generate the keytab for the second machine?

You mention "a different machine" in one place, but everywhere else  
you're only talking about different IP addresses.  If in fact it's the  
same machine, you need to merge the keytab files with the ktutil  
program (read from one, read from the other, write out the combined  
result), or extract keys for both services at once into one keytab  
file.  (And, BTW, I assume you're aware that the principal names are  
supposed to use host names and not literal IP addresses?)  Or, use  
environment variables to point the two instances of the service at  
different keytab files.

If these aren't the problems, try narrowing it down: If a client gets  
credentials for talking to the service at ip-addr-1 and uses them  
successfully before the keytab for ip-addr-2 is created, can it use  
those same credentials after the keytab is created?  If not, it's the  
service on ip-addr-1 that's been broken, because the KDC is not  
involved with the second authentication attempt to ip-addr-1 at that  
point.  If it can use them, but you can't get new working credentials  
for the service at ip-addr-1, that's a different problem....

-- 
Ken Raeburn / raeburn at mit.edu / no longer at MIT Kerberos Consortium