Determening the number of clients per KDC

[Sergei Gerasenko]

> 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 well.

> 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) <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 newb.

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 client/user.
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.