second keytab for similar service (but different SPN/IP) breaks the first
Ken Raeburn
raeburn at MIT.EDU
Wed Jun 3 12:06:55 EDT 2009
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
More information about the Kerberos
mailing list