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

Discussion in 'ASP .Net Security' started by Svante, Dec 8, 2004.

  1. Svante

    Svante Guest

    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
     
    Svante, Dec 8, 2004
    #1
    1. Advertising

  2. Svante

    Paul Clement Guest

    On Wed, 8 Dec 2004 01:53:02 -0800, Svante <> wrote:

    ¤ 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 ~~~
    Microsoft MVP (Visual Basic)
     
    Paul Clement, Dec 8, 2004
    #2
    1. Advertising

  3. Svante

    Svante Guest

    "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
     
    Svante, Dec 8, 2004
    #3
  4. Svante

    Paul Clement Guest

    On Wed, 8 Dec 2004 07:13:05 -0800, Svante <> wrote:

    ¤ "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 ~~~
    Microsoft MVP (Visual Basic)
     
    Paul Clement, Dec 9, 2004
    #4
  5. Svante

    Svante Guest

    (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
     
    Svante, Dec 9, 2004
    #5
  6. Svante

    Paul Clement Guest

    On Thu, 9 Dec 2004 09:27:02 -0800, Svante <> wrote:

    ¤ (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 ~~~
    Microsoft MVP (Visual Basic)
     
    Paul Clement, Dec 9, 2004
    #6
  7. 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.

    "Paul Clement" <> wrote in message
    news:...
    > On Thu, 9 Dec 2004 09:27:02 -0800, Svante
    > <> wrote:
    >
    > ¤ (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 ~~~
    > Microsoft MVP (Visual Basic)
     
    Joe Kaplan \(MVP - ADSI\), Dec 9, 2004
    #7
  8. Svante

    Svante Guest

    (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, Dec 9, 2004
    #8
  9. Svante

    Svante Guest

    "Joe Kaplan (MVP - ADSI)" wrote:

    > 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
     
    Svante, Dec 9, 2004
    #9
  10. 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.

    "Svante" <> wrote in message
    news:...
    > "Joe Kaplan (MVP - ADSI)" wrote:
    >
    >> 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\), Dec 9, 2004
    #10
  11. Svante

    Paul Clement Guest

    On Thu, 9 Dec 2004 11:19:05 -0800, Svante <> wrote:

    ¤ (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 ~~~
    Microsoft MVP (Visual Basic)
     
    Paul Clement, Dec 10, 2004
    #11
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. cameron

    User Group Membership

    cameron, Jun 9, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    2,123
    John Saunders
    Jun 10, 2004
  2. Tino Donderwinkel
    Replies:
    2
    Views:
    765
    Tino Donderwinkel
    Jun 18, 2008
  3. Rich Williams

    ASP.NET 2.0 Membership Provider - SSL alias - shared webapp

    Rich Williams, Jul 4, 2005, in forum: ASP .Net Security
    Replies:
    2
    Views:
    206
    Rich Williams
    Jul 6, 2005
  4. matt
    Replies:
    1
    Views:
    401
  5. matt
    Replies:
    8
    Views:
    224
    Mauricio Fernández
    Jun 19, 2004
Loading...

Share This Page