On Thu, 2012-08-02 at 22:14 +0200, Peter Mogensen wrote: > 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.
Then you need to have a way to share the digest with the KDC, that's not easy. > > > > 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. I leave that consideration to admins. Sometimes it is better to trust just one service with the keys to the kingdom than to trust many clients with the same :-) > > 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. You are welcome. Simo. -- Simo Sorce * Red Hat, Inc * New York ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
