S4U2 security

Peter Mogensen apm at mutex.dk
Thu Aug 2 16:14:25 EDT 2012


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





More information about the Kerberos mailing list