Expired Tickets - Delegation vs S4U

[Nicholas Hadlee]

I was reading the article "Exploring S4U Kerberos Extensions in Windows
Server 2003" and I have a question regarding the use of the kerberos protocol
in an ASP.NET application for delegation. I was thinking that perhaps using
once of the Service-for (S4U2Self) protocol transitions may get around an
issue we seem to have if S4U is not constrained by ticket lifetimes of the
standard kerberos tickets.

Basically the case is: We have an internal web application using an n-tier
architecture (Application Server and SQL Server are the only tiers at this
stage). Standard Kerberos delegation is being used for the authentication of
the ASP 2.0 application - the impersonation is being handled by the app using
the appropriate web.config settings...

The lifetime of the ticket which is being used by the application server is
set to the the defaut (10 hours) and this works fine for users who log on and
off each day. However for users that are logged in for longer periods (and
who need to be) their tickets expire and because they were not renewed 5
minutes before then end of that 10 hour period they cannot renew them at all.

Is it possible to force a renewal somehow? I have done some extensive
research on this issue and have not found anything that discusses credential
expiration in any detail. One scenario I considered (If S4U credentiasl do
not expire as readily as the standard kerberos tickets) would be to use
intregated authentication in the app but to have impersonation off in the
web.config and then manually impersonate using a S4U ticket - esentaily a mix
of protocol transition and delegation technicques.

Any ideas or comments from anyone that has figured this out or taken a
different approprach would be appreciated.

Nicholas

 

[Joe Kaplan]

I don't see a reason why you couldn't get this to work. I'm not aware of
any other mechanism available to deal with the ticket expiration issue
(which is one I haven't run into either). Most of the work I've done with
S4U has been to compensate for use cases where Kerberos authentication with
the client is available, but that should prevent you from using it.

There are a couple of things to know:
- You must use constrained delegation (which hopefully you are anyway)
- Depending on how things actually work in the SQL client software, you may
need an impersonation level token locally and thus may need to give the
worker process "act as part of the operating system" privilege. That in
turn compromises your security, so it should be considered carefully. You
technically don't need an impersonation level token to delegate to a remote
resource, by my experience is that many of the .NET remote access stacks
will access a resource locally during their normal processing such as a
config file or something that will trigger a local kernel mode access check.
- You may need to look up the UPN from somewhere using the TranslateName
API, an LDAP call or the DsCrackNames API.

Let us know if it works.

Joe K.

 

[Nicholas Hadlee]

I haven't as yet tried this method of mixing the two delegation models
together, I was interested if anyone had actually tried this. the real
question is will it get round the ticket lifetime of ten hours - do S4U
tickets have the same lifetime restriction? From a security perspective I
suppose there may be an issue that you are almost circumventing the purpose
of kerberos having the short lifetime if you find a way to keep the tickets
alive through multiple S4U requests.

Also, it doesnt really seem like a legitimate use of protocol transition to
go from integrated authentication (with impersonation disabled at the
application level in the web.config) to integrated authentication (with
impersonation through code). However if it works I will certainly use this
method.

 

[Joe Kaplan]

The S4U ticket for the user is generated "fresh" on the server, so you
shouldn't have any issues with the user's ticket having expired. The only
possible issue I could see here is if the server itself actually caches the
user's ticket in the LSA and that expired, but that seems farfetched to me.
I've never heard of that happening, so I think it is unlikely. It should
circumvent the issue.

I wouldn't worry about the legitimacy of the approach. If it works for you,
then use it. The API is there for a reason.

The security issues are dictated by the AD admin giving the service the
rights to do protocol transition logon for delegation and by the local admin
on the server giving the account "act as part of the operating system
privilege" (if needed). You generally wouldn't have either of these by
default.

Joe K.