"Jeremy Lew" <js***@hotmail.com> wrote in message
news:u8QgnObVFHA.2572@TK2MSFTNGP14.phx.gbl...
> I've got an ASP.NET application which is impersonating the client and does
> some role-based acess control internally. The application doesn't see
> changes in role membership made through the Windows Local Users/Group
editor
> until IIS is reset.  WindowsIdentity is apparently caching role
membership,
> but I would expect to get a different WindowsIdentity with a flushed cache
> on every request or at least every new session.  Is there any way I can
> force this to happen?
>
> Thanks,
> Jeremy
>
>

"Jeremy Lew" <js***@hotmail.com> wrote in message
news:uUDO6SbVFHA.1404@TK2MSFTNGP09.phx.gbl...
> Sorry, I obiously meant WindowsPrincipal, not WindowsIdentity.
>
> "Jeremy Lew" <js***@hotmail.com> wrote in message
> news:u8QgnObVFHA.2572@TK2MSFTNGP14.phx.gbl...
>> I've got an ASP.NET application which is impersonating the client and
>> does
>> some role-based acess control internally. The application doesn't see
>> changes in role membership made through the Windows Local Users/Group
> editor
>> until IIS is reset.  WindowsIdentity is apparently caching role
> membership,
>> but I would expect to get a different WindowsIdentity with a flushed
>> cache
>> on every request or at least every new session.  Is there any way I can
>> force this to happen?
>>
>> Thanks,
>> Jeremy
>>
>>
>
>

"Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
in message news:OMnMBLwVFHA.1148@tk2msftngp13.phx.gbl...
> My guess is that the LSA is caching the token, not the WindowsPrincipal.
> Those are generally created new with each ASP.NET request in the pipeline.
>
> Joe K.
>
> "Jeremy Lew" <js***@hotmail.com> wrote in message
> news:uUDO6SbVFHA.1404@TK2MSFTNGP09.phx.gbl...
> > Sorry, I obiously meant WindowsPrincipal, not WindowsIdentity.
> >
> > "Jeremy Lew" <js***@hotmail.com> wrote in message
> > news:u8QgnObVFHA.2572@TK2MSFTNGP14.phx.gbl...
> >> I've got an ASP.NET application which is impersonating the client and
> >> does
> >> some role-based acess control internally. The application doesn't see
> >> changes in role membership made through the Windows Local Users/Group
> > editor
> >> until IIS is reset.  WindowsIdentity is apparently caching role
> > membership,
> >> but I would expect to get a different WindowsIdentity with a flushed
> >> cache
> >> on every request or at least every new session.  Is there any way I can
> >> force this to happen?
> >>
> >> Thanks,
> >> Jeremy
> >>
> >>
> >
> >
>
>

"Jeremy Lew" <js***@hotmail.com> wrote in message
news:%23mRi$uwVFHA.4076@TK2MSFTNGP14.phx.gbl...
>I have verified that it is not the WindowsPrincipal, however it is
>certainly
> not the case that every new request is getting a new token.   Nor every
> new
> session.  These are the steps to reproduce:
>
> 1. Make a request that authenticates as a user who is NOT a member of the
> role.  IsInRole returns false and an appropriate error is thrown.
> 2. On the server, add that user to the role in the group editor.
> 3. Refresh the browser.  IsInRole still returns false.
> 4. Close the browser and open a new browser instance, authenticating
> again.
> IsInRole continues to return false.
> 5. Stop and start W3SVC, IsInRole now correctly returns true.
>
> I have noticed that allowing enough time to pass (maybe 30 minutes) also
> seems to correct the situation, I think this may be because the ASP.NET
> app
> is being recycled, but I'm not sure about this.  At any rate, I have done
> some tests and determined that the token is cached for the lifetime of a
> Logon session, and that Logon sessions for a particular user seem to
> persist
> between requests and sessions.
>
> "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
> in message news:OMnMBLwVFHA.1148@tk2msftngp13.phx.gbl...
>> My guess is that the LSA is caching the token, not the WindowsPrincipal.
>> Those are generally created new with each ASP.NET request in the
>> pipeline.
>>
>> Joe K.
>>
>> "Jeremy Lew" <js***@hotmail.com> wrote in message
>> news:uUDO6SbVFHA.1404@TK2MSFTNGP09.phx.gbl...
>> > Sorry, I obiously meant WindowsPrincipal, not WindowsIdentity.
>> >
>> > "Jeremy Lew" <js***@hotmail.com> wrote in message
>> > news:u8QgnObVFHA.2572@TK2MSFTNGP14.phx.gbl...
>> >> I've got an ASP.NET application which is impersonating the client and
>> >> does
>> >> some role-based acess control internally. The application doesn't see
>> >> changes in role membership made through the Windows Local Users/Group
>> > editor
>> >> until IIS is reset.  WindowsIdentity is apparently caching role
>> > membership,
>> >> but I would expect to get a different WindowsIdentity with a flushed
>> >> cache
>> >> on every request or at least every new session.  Is there any way I
>> >> can
>> >> force this to happen?
>> >>
>> >> Thanks,
>> >> Jeremy
>> >>
>> >>
>> >
>> >
>>
>>
>
>

"Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com> wrote
in message news:eYRCqKxVFHA.3764@TK2MSFTNGP15.phx.gbl...
> I wasn't suggesting that every new request was getting a new token, just
> that they were getting a new .NET WindowsIdentity and WindowsPrincipal to
> wrap the token.  Sorry if I was unclear.
>
> I think your analysis is correct, although it isn't totally clear to me
what
> governs the behavior.  From what you report, it does look like it has
> something to do with the worker process lifetime though.
>
> Just out of curiosity, do you get different results with Basic auth. vs.
> IWA?  My guess is that you would, but I'm not certain about that.
>
> Joe K.
>
> "Jeremy Lew" <js***@hotmail.com> wrote in message
> news:%23mRi$uwVFHA.4076@TK2MSFTNGP14.phx.gbl...
> >I have verified that it is not the WindowsPrincipal, however it is
> >certainly
> > not the case that every new request is getting a new token.   Nor every
> > new
> > session.  These are the steps to reproduce:
> >
> > 1. Make a request that authenticates as a user who is NOT a member of
the
> > role.  IsInRole returns false and an appropriate error is thrown.
> > 2. On the server, add that user to the role in the group editor.
> > 3. Refresh the browser.  IsInRole still returns false.
> > 4. Close the browser and open a new browser instance, authenticating
> > again.
> > IsInRole continues to return false.
> > 5. Stop and start W3SVC, IsInRole now correctly returns true.
> >
> > I have noticed that allowing enough time to pass (maybe 30 minutes) also
> > seems to correct the situation, I think this may be because the ASP.NET
> > app
> > is being recycled, but I'm not sure about this.  At any rate, I have
done
> > some tests and determined that the token is cached for the lifetime of a
> > Logon session, and that Logon sessions for a particular user seem to
> > persist
> > between requests and sessions.
> >
> > "Joe Kaplan (MVP - ADSI)" <joseph.e.kap***@removethis.accenture.com>
wrote
> > in message news:OMnMBLwVFHA.1148@tk2msftngp13.phx.gbl...
> >> My guess is that the LSA is caching the token, not the
WindowsPrincipal.
> >> Those are generally created new with each ASP.NET request in the
> >> pipeline.
> >>
> >> Joe K.
> >>
> >> "Jeremy Lew" <js***@hotmail.com> wrote in message
> >> news:uUDO6SbVFHA.1404@TK2MSFTNGP09.phx.gbl...
> >> > Sorry, I obiously meant WindowsPrincipal, not WindowsIdentity.
> >> >
> >> > "Jeremy Lew" <js***@hotmail.com> wrote in message
> >> > news:u8QgnObVFHA.2572@TK2MSFTNGP14.phx.gbl...
> >> >> I've got an ASP.NET application which is impersonating the client
and
> >> >> does
> >> >> some role-based acess control internally. The application doesn't
see
> >> >> changes in role membership made through the Windows Local
Users/Group
> >> > editor
> >> >> until IIS is reset.  WindowsIdentity is apparently caching role
> >> > membership,
> >> >> but I would expect to get a different WindowsIdentity with a flushed
> >> >> cache
> >> >> on every request or at least every new session.  Is there any way I
> >> >> can
> >> >> force this to happen?
> >> >>
> >> >> Thanks,
> >> >> Jeremy
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>