On Thu, 2012-08-02 at 17:54 +0200, Peter Mogensen wrote: > If the intent is that you should be able to authenticate to service1 > in > a non-kerberos way and then backend services would still be able to > use > kerberos, when 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. > If you already have a service using something like HTTP Basic auth, > then > any one compromising that service would have access to the passwords > of > users logging in anyway, so this would AFAICS only improve security > for > users not logging in after the compromise. > > I might have overlooked something, but it seems to me that allowing > services to do S4U2self with only PA-FOR-USER is practically useless > unless you want to extend the strong protection of the KDC to thoses > services. What you overlooked, I think, is that you are seeing s4u2self and 24u2proxy used in conjunction as the main use case. It is not. 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. 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. 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. Simo. -- Simo Sorce * Red Hat, Inc * New York ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
