> To make it worse, any low privilege Active Directory account can request a TGS for any service, even if they are not allowed to access that service.
I have a vague understanding of Kerberos, and this is where I’m mystified. Why is the KDC or anything else willing to issue a TGS ticket encryption against a service password before the requesting user authorizes themselves? Or is the issue that authentication and authorization are split and the KDC has no idea whether the requesting user is authorized.
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
Kerberos doesn't concern itself with authorization, just authentication. It's up to the app to accept or reject a ticket, and that process is completely opaque to kerberos. It _could_ be extended since Kerberos allows pretty much any damn thing you want to happen with vendor extensions, but I'm not sure that's a situation you want AD to be handling given its track record in the rest of the security space.