> Oh, no problem -- just be aware that they're being answered by someone who
> hasn't run large-scale KDCs in about four years, so some of my information
> is stale. :)
Still very valuable since I haven’t been able to find answers to any of these
> If you're doing default Kerberos, the networking is UDP, so it's not going
> to spend a lot of time waiting for the network. I would expect that to be
Cool, something to verify, but not a bad guess I think.
> This is all just a wild-ass guess, though.
> Given your setup, though, it would really surprise me if you saw any
> performance issues.
Will keeping an access log slow me down much, do you know? For that matter, is
there a benchmarking tool for KDCs?
> You can use SRV records and get 3 by just listing both KDCs as equal
> weight. All Kerberos clients these days should support SRV records.
That sounds like a good idea. I can use puppet to list the kdcs in krb5.conf as
> I can only see 2 as a real option because *I think* once a TGT is
>> requested, all TGS requests would need to go to the server that gave the
> Nope, all KDCs share the same database and can answer all requests.
Ok, it’s just that I see everywhere (e.g.
<https://en.wikipedia.org/wiki/Kerberos_(protocol)>) that the initial TGT
response includes a session key that the host and the service server will
share. So that’s what got me thinking that once a TGT is retrieved, the client
should request a service ticket using the same KDC. But like I said, I’m total
The AS checks to see if the client is in its database. If it is, the AS
generates the secret key by hashing the password of the user found at the
database (e.g., Active Directory
<https://en.wikipedia.org/wiki/Active_Directory> in Windows Server) and sends
back the following two messages to the client:
Message A: Client/TGS Session Key encrypted using the secret key of the
Message B: Ticket-Granting-Ticket (TGT, which includes the client ID, client
network address <https://en.wikipedia.org/wiki/Network_address>, ticket
validity period, and the client/TGS session key) encrypted using the secret key
of the TGS.
Kerberos mailing list Kerberos@mit.edu