ASP.NET - Basic/SSL - Changes in user group membership delayed

[Svante]

Background: An ASP.NET application, using Basic/SSL authentication with users
residing in an Active Directory in the same domain as the web server, pages
and resources protected with NTFS ACL's and ASP.NET configured for
impersonation works fine.

Observation: But, it appears that the ASP.NET worker process, once it has
impersonated a user, will re-use that same user token when when the same user
is re-authenticated after having started a new browser.

The problem, as it appears: A user is given changed permissions by an
administrator by changing group memberships in Active Directory. This change
has no effect in the ASP.NET application until IIS is restarted (or possibly
ASP.NET worker process dies out of boredom by itself).

The question: How to make user group memberships changes effective, at least
after the user has restarted a browser?

Svante

 

[Paul Clement]

¤ Background: An ASP.NET application, using Basic/SSL authentication with users
¤ residing in an Active Directory in the same domain as the web server, pages
¤ and resources protected with NTFS ACL's and ASP.NET configured for
¤ impersonation works fine.
¤
¤ Observation: But, it appears that the ASP.NET worker process, once it has
¤ impersonated a user, will re-use that same user token when when the same user
¤ is re-authenticated after having started a new browser.
¤
¤ The problem, as it appears: A user is given changed permissions by an
¤ administrator by changing group memberships in Active Directory. This change
¤ has no effect in the ASP.NET application until IIS is restarted (or possibly
¤ ASP.NET worker process dies out of boredom by itself).
¤
¤ The question: How to make user group memberships changes effective, at least
¤ after the user has restarted a browser?

Is there any chance your network configuration implements load balancing domain controllers, or are
you using a single domain controller.?

Based upon my understanding of authenticated credentials and the checking of permissions with
respect to resources and IIS, I don't think the description in your observation is possible.


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)

 

[Svante]

:

(snip)

¤ Observation: But, it appears that the ASP.NET worker process, once it has
¤ impersonated a user, will re-use that same user token when when the same user
¤ is re-authenticated after having started a new browser. (snip)
Is there any chance your network configuration implements load balancing domain controllers, or are
you using a single domain controller.?

Single in this case. Production is load balancing, and there's a known
propagation delay between them in that case. That's not the problem here.

Based upon my understanding of authenticated credentials and the checking of permissions with
respect to resources and IIS, I don't think the description in your observation is possible.

The suggested model for explanation may well be wrong, but the basic
observation is certainly possible....

0 - I log on via Basic Authentication/SSL after browsing to my app. The app
impersonates the authenticated user, and access a file wherafter I close the
browser.
1 - I remove the user from a group in Active Directory.
2- I log on via Basic Authentication/SSL after browsing to my app. The app
impersonates the authenticated users.
3 - The app can access files that provably require membership in the just
removed-from group, until I restart IIS (or probably restart ASP.NET worker
process, I can't definitely say though since it takes too long time to wait,
and I can't seem to just kill it manually).

Svante

 

[Paul Clement]

¤ "Paul Clement" wrote:
¤
¤ (snip)
¤ > ¤ Observation: But, it appears that the ASP.NET worker process, once it has
¤ > ¤ impersonated a user, will re-use that same user token when when the same user
¤ > ¤ is re-authenticated after having started a new browser.
¤ (snip)
¤ > Is there any chance your network configuration implements load balancing domain controllers, or are
¤ > you using a single domain controller.?
¤ Single in this case. Production is load balancing, and there's a known
¤ propagation delay between them in that case. That's not the problem here.
¤
¤ > Based upon my understanding of authenticated credentials and the checking of permissions with
¤ > respect to resources and IIS, I don't think the description in your observation is possible.
¤ >
¤
¤ The suggested model for explanation may well be wrong, but the basic
¤ observation is certainly possible....
¤
¤ 0 - I log on via Basic Authentication/SSL after browsing to my app. The app
¤ impersonates the authenticated user, and access a file wherafter I close the
¤ browser.
¤ 1 - I remove the user from a group in Active Directory.
¤ 2- I log on via Basic Authentication/SSL after browsing to my app. The app
¤ impersonates the authenticated users.
¤ 3 - The app can access files that provably require membership in the just
¤ removed-from group, until I restart IIS (or probably restart ASP.NET worker
¤ process, I can't definitely say though since it takes too long time to wait,
¤ and I can't seem to just kill it manually).
¤
¤ Svante

What is the Application Protection for this application? Low (IIS), Medium (Pooled) or High
(Isolated)?


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)

 

[Svante]

(snip)

What is the Application Protection for this application? Low (IIS), Medium (Pooled) or High
(Isolated)?

(snip)
Medium. I thought you said that it could not possibly have to do with
thread/token re-use by the ASP.NET worker process... ;-)

I have not tried changing this setting, nor do I want to - I want to know
what is happening and how I can handle it regardless of this or any other
similar settings which as more far ranging effects.

Svante

 

[Paul Clement]

¤ (snip)
¤ > What is the Application Protection for this application? Low (IIS), Medium (Pooled) or High
¤ > (Isolated)?
¤ (snip)
¤ Medium. I thought you said that it could not possibly have to do with
¤ thread/token re-use by the ASP.NET worker process... ;-)
¤

I don't believe that it does, but lacking another explanation as to why declarative security isn't
working as expected, it certainly doesn't hurt to consider that the web server, for some reason
unknown to me, is caching credentials.

Have you verified that impersonation is working properly. I'm assuming that you're impersonating the
user authenticated via the browser and not an account specified in the web.config file?


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)

 

[Joe Kaplan \(MVP - ADSI\)]

I actually wouldn't be surprised if the token on the server was getting
reused and that would be a good explanation for the problem. If the
kerberos ticket is cached on the server, it might not get refreshed right
away. I'm pretty sure the server isn't going to make a round trip to the
KDC for every single authentication. This is probably a better question for
the Windows server guys though to get the details of how the LSA is handling
this.

Joe K.

 

[Svante]

(snip)

Have you verified that impersonation is working properly. I'm assuming that you're impersonating the
user authenticated via the browser and not an account specified in the web.config file?

(snip)
Yes and yes and no.

Svante

 

[Svante]

I actually wouldn't be surprised if the token on the server was getting
reused and that would be a good explanation for the problem. If the
kerberos ticket is cached on the server, it might not get refreshed right
away. I'm pretty sure the server isn't going to make a round trip to the
KDC for every single authentication. This is probably a better question for
the Windows server guys though to get the details of how the LSA is handling
this.

(snip)

Thank you for your support The only problem I have with your suggestion
of going to the server guys is that it appears to be strictly related to IIS
(ASP.NET Worker Process?). If I restart IIS the changes are effective
immediately.

How would that affect the server's basic caching of credentials?

Svante

 

[Joe Kaplan \(MVP - ADSI\)]

It could be that IIS is caching token handles in its own process memory and
reusing those or might be that killing IIS causes the token to get removed
from the box.

I'd still ask the server guys, but this question might need to go to the
guys who do IIS specifically. Like I said, I was just guessing. It
definitely appears that somewhere in the chain, a slightly outdated version
of the user's token is being used, so it must be getting cached somewhere.
We just don't know the details.

If you find the real answer, please let us know.

Joe K.

 

[Paul Clement]

¤ (snip)
¤ > Have you verified that impersonation is working properly. I'm assuming that you're impersonating the
¤ > user authenticated via the browser and not an account specified in the web.config file?
¤ (snip)
¤ Yes and yes and no.

Have you tried checking the group membership programmatically via ADSI or DirectoryServices (from
the web app) to ensure that the change is being reflected? This would eliminate AD as the culprit if
the change is reflected (user no longer in group).


Paul ~~~ (e-mail address removed)
Microsoft MVP (Visual Basic)