> 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 
questions elsewhere.

> 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
>> TGT?
> 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

Reply via email to