The reason that the KDC doesn't decide if the user should get a ticket is that then the power requirements of the DC would be enormous. It should have to know if a user is supposed to have access to every single service in the environment. It would be a massive database. That massive database would also have to sync to all the other DCs. To alleviate this, Kerberos let's the server decide if the user has access, and if so, how much

Just to add to this, the salt (domain [realm] and username) is only used to generate the AES keys, not the RC4. The RC4 key is simply the NT hash.

And thanks for the shout out!

In Kerberos, the answer is effectively no. To generate the NT hash, the password is hashed using a single round of MD4. This is what is used to encrypt (and sign) tickets.

The attack is, guess a password, hash it, and attempt to decrypt.

With AES Kerberos keys there is a salt... but not a good one. It is just the domain (realm) and the username.

> That is why service accounts have really long complex passwords.

The sad thing is, they don't always have long complex passwords. They SHOULD, but they don't. Many orgs are scared of changing service account passwords due to the possibility of an outage.

I don't often see a day to day user with an SPN. I do see plenty of SPNs tied to service accounts where the service account password is crackable/Kerberoastable.