On 2012-08-02 21:21, Simo Sorce wrote: > On Thu, 2012-08-02 at 17:54 +0200, Peter Mogensen wrote: >> why does the S4U2self req. not contain any options to >> actually prove that the named user has been authenticated, like - in >> the most simple case, like HTTP Basic Auth - just embed the user/pass >> in >> the PA data send along with the S4U2self req. ? > If you have a username/password you can simply use them to perform an AS > request and get a user TGT, s4u2self would be useless in that case.
Ah yes... of course... silly me. Too simple a case. But then say the web server used HTTP Digest with a nonce and computed hash result provided by the KDC. Then the password (and access to requesting TGTs) would still only be shared by the user and KDC. > > What you overlooked, I think, is that you are seeing s4u2self and > 24u2proxy used in conjunction as the main use case. It is not. You're probably right. I saw this promoted somewhere as a way to let non-kerberos client into a kerberos infrastructure. Men I concluded that the price of having to protect a (say) webserver as strongly as the KDC was making it not that great an idea. > In general s4u2self is used on AD machines to get the user MS-PAC so > that local authorization can be done, but generally those services are > not allowed to also do s4u2proxy. Ok... makes sense. > S4u2proxy should be used instead when a real user connects to a service > that need to access a 3rd service on its behalf, this is where the > evidence ticket comes in play. > > Of course you can configure your realm so that a service can both do a > s4u2self operation *and* s4u2proxy operation. It would be better for you > to have proper access control in the KDC in that case in order to be > able to limit which user the service is allowed to perform s4u2self as > and which services it is allowed to get a ticket for with s4u2proxy, but > yeah such a service can basically impersonate any allowed user to any > allowed service w/o real authentication, so you better make sure it is > not compromised. Yes, That was my conclusion. And it seems like to high a price to pay in many scenarios. > In the end s4u2proxy is generally *a lot* better than forwarding TGTs if > your KDC support ACLs as then you can limit what other services a > potentially compromised service can get access to. > > s4u2self is generally best used in very trusted service or only to fetch > authorization data in the form of a MS-PAC in AD environments and not > much else. > > In the end these are very useful tools, is how you use/combine them that > makes them more or less powerful and or risky. > Thanks for the explanation. I agree it's still useful. /Peter ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
