|
|
You're in the
dotnet security
group:IsInRole & SID/Token Caching in .NET v1.1
dotnet security:
("targets") other than the thread-executing user (the "operator"). The class I'm building will be used by ASP.NET apps and also by Windows Services. I know about using protocol transition to get an unauthenticated WindowsIdentity from the target UPNName, then getting the corresponding WindowsPrincipal and doing an IsInRole on that. Works great, if a little slow. But if I then change the target user's group membership in AD on our DC and re-execute the code, the update isn't reflected in the results. Apparently my local server is caching the underlying SID / token data someplace. Stopping & restarting my WinService app does NOT trigger a refresh. Eventually, usually after several minutes, the update propagates & I get correct results again. (Presumably after the entry gets flushed from aforesaid cache due to age / LRU??). So I conclude the issue is somewhere in the bowels of Win2003 SID / LSSAS processing, about which I have no clue. Is there an accessible cache-flush function I could wrap and then call from ..NET? Or at least something to force a fresh look at the particluar target WindowIdentity / WindowsPrincipal I'm interested in? Would calling it destroy the performance of the IIS server my app is running on? Thanks in advance, Mark Seward, MCAD .NET
Joe,
Thank you for your prompt reply. I'll check with the PlatformSDK folks directly. I had searched the archives here and seen & evaluated Todd's article. I'll probably implement something like that for speedup, but, as you say, it still doesn't solve my problem. Our group roster is on the order of 1000 groups, with each user (out of several thousand) a member of 2 to 10 groups directly and between 3x & 8x more by inheritance. Mark [quoted text, click to view] "Joe Kaplan (MVP - ADSI)" wrote:
> I'm going to guess and say that with a WindowsIdentity created via Protocol > Transition, the SIDs are caches in the Kerberos ticket and the kerberos > ticket is cached by the LSA. You might be able to get more insight into the > behavior by doing some network sniffing on Port 88 when making these calls > and possibly using the KerbTray utility. > > Whether or not you can force a Kerberos ticket to be updated is something I > have no idea on. You might try reposting this stuff on the > platformsdk.security newsgroup as only some of this is .NET-specific and > none of the relevant aspects are. > > Here is another cool article that discusses some issues with > WindowsIdentity/Principal and IsInRole performance that might give you some > ideas to make things faster (though not fix the caching issue): > http://blogs.msdn.com/toddca/archive/2005/04/28/413033.aspx > > Joe K. > "Mark Seward" <mark.seward.spamkiller@convergence-comm.com> wrote in message > news:A2FD6D08-3875-4CEA-9E60-DF6F5CF463DB@microsoft.com... > >I have a win2003 server that needs to do IsInRole queries aganist users > > ("targets") other than the thread-executing user (the "operator"). The > > class > > I'm building will be used by ASP.NET apps and also by Windows Services. > > > > I know about using protocol transition to get an unauthenticated > > WindowsIdentity from the target UPNName, then getting the corresponding > > WindowsPrincipal and doing an IsInRole on that. Works great, if a little > > slow. > > > > But if I then change the target user's group membership in AD on our DC > > and > > re-execute the code, the update isn't reflected in the results. > > Apparently > > my local server is caching the underlying SID / token data someplace. > > Stopping & restarting my WinService app does NOT trigger a refresh. > > > > Eventually, usually after several minutes, the update propagates & I get > > correct results again. (Presumably after the entry gets flushed from > > aforesaid cache due to age / LRU??). So I conclude the issue is somewhere > > in > > the bowels of Win2003 SID / LSSAS processing, about which I have no clue. > > > > Is there an accessible cache-flush function I could wrap and then call > > from > > .NET? Or at least something to force a fresh look at the particluar > > target > > WindowIdentity / WindowsPrincipal I'm interested in? Would calling it > > destroy the performance of the IIS server my app is running on? > > > > Thanks in advance, > > Mark Seward, MCAD .NET > > > >
I'm going to guess and say that with a WindowsIdentity created via Protocol
Transition, the SIDs are caches in the Kerberos ticket and the kerberos ticket is cached by the LSA. You might be able to get more insight into the behavior by doing some network sniffing on Port 88 when making these calls and possibly using the KerbTray utility. Whether or not you can force a Kerberos ticket to be updated is something I have no idea on. You might try reposting this stuff on the platformsdk.security newsgroup as only some of this is .NET-specific and none of the relevant aspects are. Here is another cool article that discusses some issues with WindowsIdentity/Principal and IsInRole performance that might give you some ideas to make things faster (though not fix the caching issue): http://blogs.msdn.com/toddca/archive/2005/04/28/413033.aspx Joe K. [quoted text, click to view] "Mark Seward" <mark.seward.spamkiller@convergence-comm.com> wrote in message news:A2FD6D08-3875-4CEA-9E60-DF6F5CF463DB@microsoft.com... >I have a win2003 server that needs to do IsInRole queries aganist users > ("targets") other than the thread-executing user (the "operator"). The > class > I'm building will be used by ASP.NET apps and also by Windows Services. > > I know about using protocol transition to get an unauthenticated > WindowsIdentity from the target UPNName, then getting the corresponding > WindowsPrincipal and doing an IsInRole on that. Works great, if a little > slow. > > But if I then change the target user's group membership in AD on our DC > and > re-execute the code, the update isn't reflected in the results. > Apparently > my local server is caching the underlying SID / token data someplace. > Stopping & restarting my WinService app does NOT trigger a refresh. > > Eventually, usually after several minutes, the update propagates & I get > correct results again. (Presumably after the entry gets flushed from > aforesaid cache due to age / LRU??). So I conclude the issue is somewhere > in > the bowels of Win2003 SID / LSSAS processing, about which I have no clue. > > Is there an accessible cache-flush function I could wrap and then call > from > .NET? Or at least something to force a fresh look at the particluar > target > WindowIdentity / WindowsPrincipal I'm interested in? Would calling it > destroy the performance of the IIS server my app is running on? > > Thanks in advance, > Mark Seward, MCAD .NET >
Hello Joe,
the tickets are indeed cached - in the ticket cache :) you can programmatically purge the cache - like kerbtray or tlist does. Don't know the API off my head, though --------------------------------------- Dominick Baier - DevelopMentor http://www.leastprivilege.com [quoted text, click to view] > I'm going to guess and say that with a WindowsIdentity created via > Protocol Transition, the SIDs are caches in the Kerberos ticket and > the kerberos ticket is cached by the LSA. You might be able to get > more insight into the behavior by doing some network sniffing on Port > 88 when making these calls and possibly using the KerbTray utility. > > Whether or not you can force a Kerberos ticket to be updated is > something I have no idea on. You might try reposting this stuff on > the platformsdk.security newsgroup as only some of this is > .NET-specific and none of the relevant aspects are. > > Here is another cool article that discusses some issues with > WindowsIdentity/Principal and IsInRole performance that might give you > some ideas to make things faster (though not fix the caching issue): > http://blogs.msdn.com/toddca/archive/2005/04/28/413033.aspx > > Joe K. > "Mark Seward" <mark.seward.spamkiller@convergence-comm.com> wrote in > message > news:A2FD6D08-3875-4CEA-9E60-DF6F5CF463DB@microsoft.com... >> I have a win2003 server that needs to do IsInRole queries aganist >> users >> ("targets") other than the thread-executing user (the "operator"). >> The >> class >> I'm building will be used by ASP.NET apps and also by Windows >> Services. >> I know about using protocol transition to get an unauthenticated >> WindowsIdentity from the target UPNName, then getting the >> corresponding WindowsPrincipal and doing an IsInRole on that. Works >> great, if a little slow. >> >> But if I then change the target user's group membership in AD on our >> DC >> and >> re-execute the code, the update isn't reflected in the results. >> Apparently >> my local server is caching the underlying SID / token data someplace. >> Stopping & restarting my WinService app does NOT trigger a refresh. >> Eventually, usually after several minutes, the update propagates & I >> get >> correct results again. (Presumably after the entry gets flushed from >> aforesaid cache due to age / LRU??). So I conclude the issue is >> somewhere >> in >> the bowels of Win2003 SID / LSSAS processing, about which I have no >> clue. >> Is there an accessible cache-flush function I could wrap and then >> call >> from >> .NET? Or at least something to force a fresh look at the particluar >> target >> WindowIdentity / WindowsPrincipal I'm interested in? Would calling >> it >> destroy the performance of the IIS server my app is running on? >> Thanks in advance, >> Mark Seward, MCAD .NET
Remember also that if you update group membership on a domain, it takes
time for that membership information to propogate to all the physical domain controllers, thus when you restart your service (login the service account) it is most likely not creating a login session with the same physical box. [quoted text, click to view] Mark Seward wrote:
> I have a win2003 server that needs to do IsInRole queries aganist users > ("targets") other than the thread-executing user (the "operator"). The class > I'm building will be used by ASP.NET apps and also by Windows Services. > > I know about using protocol transition to get an unauthenticated > WindowsIdentity from the target UPNName, then getting the corresponding > WindowsPrincipal and doing an IsInRole on that. Works great, if a little > slow. > > But if I then change the target user's group membership in AD on our DC and > re-execute the code, the update isn't reflected in the results. Apparently > my local server is caching the underlying SID / token data someplace. > Stopping & restarting my WinService app does NOT trigger a refresh. > > Eventually, usually after several minutes, the update propagates & I get > correct results again. (Presumably after the entry gets flushed from > aforesaid cache due to age / LRU??). So I conclude the issue is somewhere in > the bowels of Win2003 SID / LSSAS processing, about which I have no clue. > > Is there an accessible cache-flush function I could wrap and then call from > ..NET? Or at least something to force a fresh look at the particluar target > WindowIdentity / WindowsPrincipal I'm interested in? Would calling it > destroy the performance of the IIS server my app is running on? > > Thanks in advance, > Mark Seward, MCAD .NET
Don't see what you're looking for? Try a search.
|
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
| home · blog · groups | Questions? Comments? Contact the dn |