RE: [ActiveDir] Sticky group membership - Solved
Hey Tony (you're alive :-), Correct, the cache is used exclusively for authentication purposes, nothing more. PS - How's life 'Down Under' and to the right a bit (well, quite a lot actually :)? -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Sunday, May 22, 2005 5:40 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved Hi Dean :-) So if I've understood your first point correctly, there is no benefit at all to caching Global Groups, not even performance, e.g for LDAP searches? They're simply lumped in there because they cannot be differentiated form UGs. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Monday, 23 May 2005 2:25 a.m. To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved How strange, you're the 2nd person that's asked me that in as many days :-/ No particular ordering - 1. Caching Global Groups - sugar coatedcauses additional admin. requirements/sugar coated - non-sugar coatedridiculous, why cache what the DC already has explicit knowledge of?non-sugar coated - answer, unable to sufficiently differentiate group types at the time the cache is populated. I've suggested approaches ... I guess we'll see. 2. Cache is NOT replicated within the site (bad thing) or out of the site (good thing), as such, each DC within a caching site independently updates its own cache at a controllable interval - if the site contains more than 1 DC, they all update their cache independently instead of 'bridgeheading' the operation and locally replicating 3. If site contains more than 500 users (or sub-class derivatives) containing a non-stale cached membership - the DC(s) will only update the first 500 objects (which can be increased). During the next pass, the DCs will NOT iterate though the list thereby covering all relevant objects. Instead, the DCs update the objects based on (IIRC) their natural ordering within the DIT (which may differ from DC to DC). 4. No automated failover capability (not critical may prove useful) - place a GC in the site = GC used and cache is populated locally from it - GC in site not found, cache is used 5. No interface to view, manage, update or pre-populate the cache - under-the-hood mechanisms do exist but weren't exposed - Eric wrote a CLI tool to view it some time ago - Scripts are available for manual update and can be bolted into the interface 6. DScrackNames API requires a GC when instructed to resolve locally-unknown SPNs used when computers apply policy (may have long-since been resolved ... haven't checked) That's all I can think of ... hope it proves useful! Dean -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, May 21, 2005 2:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved Dean, Would you be as kind as to elaborate on the other issues with Group Membership Crashing? I know you're not into the 'joe' model of writing novels, but I'm interested in what you've noted and why it occurs. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, May 21, 2005 1:10 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot
RE: [ActiveDir] Sticky group membership - Solved
How strange, you're the 2nd person that's asked me that in as many days :-/ No particular ordering - 1. Caching Global Groups - sugar coatedcauses additional admin. requirements/sugar coated - non-sugar coatedridiculous, why cache what the DC already has explicit knowledge of?non-sugar coated - answer, unable to sufficiently differentiate group types at the time the cache is populated. I've suggested approaches ... I guess we'll see. 2. Cache is NOT replicated within the site (bad thing) or out of the site (good thing), as such, each DC within a caching site independently updates its own cache at a controllable interval - if the site contains more than 1 DC, they all update their cache independently instead of 'bridgeheading' the operation and locally replicating 3. If site contains more than 500 users (or sub-class derivatives) containing a non-stale cached membership - the DC(s) will only update the first 500 objects (which can be increased). During the next pass, the DCs will NOT iterate though the list thereby covering all relevant objects. Instead, the DCs update the objects based on (IIRC) their natural ordering within the DIT (which may differ from DC to DC). 4. No automated failover capability (not critical may prove useful) - place a GC in the site = GC used and cache is populated locally from it - GC in site not found, cache is used 5. No interface to view, manage, update or pre-populate the cache - under-the-hood mechanisms do exist but weren't exposed - Eric wrote a CLI tool to view it some time ago - Scripts are available for manual update and can be bolted into the interface 6. DScrackNames API requires a GC when instructed to resolve locally-unknown SPNs used when computers apply policy (may have long-since been resolved ... haven't checked) That's all I can think of ... hope it proves useful! Dean -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, May 21, 2005 2:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved Dean, Would you be as kind as to elaborate on the other issues with Group Membership Crashing? I know you're not into the 'joe' model of writing novels, but I'm interested in what you've noted and why it occurs. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, May 21, 2005 1:10 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens are only updated during authentication. This means that if you have a group membership change and then connect to a remote resources you can get that new token if you completely break any previous sessions with the remote resource, then purge your kerberos tickets, and then reconnect to the resource. For interactive logons (i.e. you have a desktop associated with the logon) you need to log off and log on. joe -Original Message
RE: [ActiveDir] Sticky group membership - Solved
I like it when Dean posts longer answers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Sunday, May 22, 2005 10:25 AM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved How strange, you're the 2nd person that's asked me that in as many days :-/ No particular ordering - 1. Caching Global Groups - sugar coatedcauses additional admin. requirements/sugar coated - non-sugar coatedridiculous, why cache what the DC already has explicit knowledge of?non-sugar coated - answer, unable to sufficiently differentiate group types at the time the cache is populated. I've suggested approaches ... I guess we'll see. 2. Cache is NOT replicated within the site (bad thing) or out of the site (good thing), as such, each DC within a caching site independently updates its own cache at a controllable interval - if the site contains more than 1 DC, they all update their cache independently instead of 'bridgeheading' the operation and locally replicating 3. If site contains more than 500 users (or sub-class derivatives) containing a non-stale cached membership - the DC(s) will only update the first 500 objects (which can be increased). During the next pass, the DCs will NOT iterate though the list thereby covering all relevant objects. Instead, the DCs update the objects based on (IIRC) their natural ordering within the DIT (which may differ from DC to DC). 4. No automated failover capability (not critical may prove useful) - place a GC in the site = GC used and cache is populated locally from it - GC in site not found, cache is used 5. No interface to view, manage, update or pre-populate the cache - under-the-hood mechanisms do exist but weren't exposed - Eric wrote a CLI tool to view it some time ago - Scripts are available for manual update and can be bolted into the interface 6. DScrackNames API requires a GC when instructed to resolve locally-unknown SPNs used when computers apply policy (may have long-since been resolved ... haven't checked) That's all I can think of ... hope it proves useful! Dean -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, May 21, 2005 2:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved Dean, Would you be as kind as to elaborate on the other issues with Group Membership Crashing? I know you're not into the 'joe' model of writing novels, but I'm interested in what you've noted and why it occurs. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, May 21, 2005 1:10 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens are only updated during authentication. This means that if you have a group membership change and then connect to a remote resources you can get that new token if you completely break any
RE: [ActiveDir] Sticky group membership - Solved
Yes, I am strange - thank you very much. And, Bob's your Uncle, I know have the information that I needed. Thanks, Dean! -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Sunday, May 22, 2005 9:25 AM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved How strange, you're the 2nd person that's asked me that in as many days :-/ No particular ordering - 1. Caching Global Groups - sugar coatedcauses additional admin. requirements/sugar coated - non-sugar coatedridiculous, why cache what the DC already has explicit knowledge of?non-sugar coated - answer, unable to sufficiently differentiate group types at the time the cache is populated. I've suggested approaches ... I guess we'll see. 2. Cache is NOT replicated within the site (bad thing) or out of the site (good thing), as such, each DC within a caching site independently updates its own cache at a controllable interval - if the site contains more than 1 DC, they all update their cache independently instead of 'bridgeheading' the operation and locally replicating 3. If site contains more than 500 users (or sub-class derivatives) containing a non-stale cached membership - the DC(s) will only update the first 500 objects (which can be increased). During the next pass, the DCs will NOT iterate though the list thereby covering all relevant objects. Instead, the DCs update the objects based on (IIRC) their natural ordering within the DIT (which may differ from DC to DC). 4. No automated failover capability (not critical may prove useful) - place a GC in the site = GC used and cache is populated locally from it - GC in site not found, cache is used 5. No interface to view, manage, update or pre-populate the cache - under-the-hood mechanisms do exist but weren't exposed - Eric wrote a CLI tool to view it some time ago - Scripts are available for manual update and can be bolted into the interface 6. DScrackNames API requires a GC when instructed to resolve locally-unknown SPNs used when computers apply policy (may have long-since been resolved ... haven't checked) That's all I can think of ... hope it proves useful! Dean -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, May 21, 2005 2:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved Dean, Would you be as kind as to elaborate on the other issues with Group Membership Crashing? I know you're not into the 'joe' model of writing novels, but I'm interested in what you've noted and why it occurs. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, May 21, 2005 1:10 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens are only updated during authentication. This means that if you have a group membership change and then connect
RE: [ActiveDir] Sticky group membership - Solved
I think that you just like when Dean posts answers - period. ;o) -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, May 22, 2005 12:06 PM To: 'Send - AD mailing list' Subject: RE: [ActiveDir] Sticky group membership - Solved I like it when Dean posts longer answers. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Sunday, May 22, 2005 10:25 AM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved How strange, you're the 2nd person that's asked me that in as many days :-/ No particular ordering - 1. Caching Global Groups - sugar coatedcauses additional admin. requirements/sugar coated - non-sugar coatedridiculous, why cache what the DC already has explicit knowledge of?non-sugar coated - answer, unable to sufficiently differentiate group types at the time the cache is populated. I've suggested approaches ... I guess we'll see. 2. Cache is NOT replicated within the site (bad thing) or out of the site (good thing), as such, each DC within a caching site independently updates its own cache at a controllable interval - if the site contains more than 1 DC, they all update their cache independently instead of 'bridgeheading' the operation and locally replicating 3. If site contains more than 500 users (or sub-class derivatives) containing a non-stale cached membership - the DC(s) will only update the first 500 objects (which can be increased). During the next pass, the DCs will NOT iterate though the list thereby covering all relevant objects. Instead, the DCs update the objects based on (IIRC) their natural ordering within the DIT (which may differ from DC to DC). 4. No automated failover capability (not critical may prove useful) - place a GC in the site = GC used and cache is populated locally from it - GC in site not found, cache is used 5. No interface to view, manage, update or pre-populate the cache - under-the-hood mechanisms do exist but weren't exposed - Eric wrote a CLI tool to view it some time ago - Scripts are available for manual update and can be bolted into the interface 6. DScrackNames API requires a GC when instructed to resolve locally-unknown SPNs used when computers apply policy (may have long-since been resolved ... haven't checked) That's all I can think of ... hope it proves useful! Dean -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, May 21, 2005 2:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved Dean, Would you be as kind as to elaborate on the other issues with Group Membership Crashing? I know you're not into the 'joe' model of writing novels, but I'm interested in what you've noted and why it occurs. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, May 21, 2005 1:10 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir
RE: [ActiveDir] Sticky group membership - Solved
Hi Dean :-) So if I've understood your first point correctly, there is no benefit at all to caching Global Groups, not even performance, e.g for LDAP searches? They're simply lumped in there because they cannot be differentiated form UGs. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Monday, 23 May 2005 2:25 a.m. To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved How strange, you're the 2nd person that's asked me that in as many days :-/ No particular ordering - 1. Caching Global Groups - sugar coatedcauses additional admin. requirements/sugar coated - non-sugar coatedridiculous, why cache what the DC already has explicit knowledge of?non-sugar coated - answer, unable to sufficiently differentiate group types at the time the cache is populated. I've suggested approaches ... I guess we'll see. 2. Cache is NOT replicated within the site (bad thing) or out of the site (good thing), as such, each DC within a caching site independently updates its own cache at a controllable interval - if the site contains more than 1 DC, they all update their cache independently instead of 'bridgeheading' the operation and locally replicating 3. If site contains more than 500 users (or sub-class derivatives) containing a non-stale cached membership - the DC(s) will only update the first 500 objects (which can be increased). During the next pass, the DCs will NOT iterate though the list thereby covering all relevant objects. Instead, the DCs update the objects based on (IIRC) their natural ordering within the DIT (which may differ from DC to DC). 4. No automated failover capability (not critical may prove useful) - place a GC in the site = GC used and cache is populated locally from it - GC in site not found, cache is used 5. No interface to view, manage, update or pre-populate the cache - under-the-hood mechanisms do exist but weren't exposed - Eric wrote a CLI tool to view it some time ago - Scripts are available for manual update and can be bolted into the interface 6. DScrackNames API requires a GC when instructed to resolve locally-unknown SPNs used when computers apply policy (may have long-since been resolved ... haven't checked) That's all I can think of ... hope it proves useful! Dean -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, May 21, 2005 2:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved Dean, Would you be as kind as to elaborate on the other issues with Group Membership Crashing? I know you're not into the 'joe' model of writing novels, but I'm interested in what you've noted and why it occurs. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, May 21, 2005 1:10 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens
RE: [ActiveDir] Sticky group membership - Solved
May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens are only updated during authentication. This means that if you have a group membership change and then connect to a remote resources you can get that new token if you completely break any previous sessions with the remote resource, then purge your kerberos tickets, and then reconnect to the resource. For interactive logons (i.e. you have a desktop associated with the logon) you need to log off and log on. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Saturday, May 14, 2005 1:18 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Sticky group membership Environment: Three W2K3 DC's and ten WTS (no SP1), all located on the same subnet. We have GPO's applied based on group membership. A few policies are only intended to be active for some hours, blocking execution of specific applications. After adding the users to the group, the policy is active almost immediately on the terminal servers - but after removing users from the group, the GPO's are still applied on some. GPresult shows that the users are still seen as member of the group, while running MemberOf against every DC says they are not? How can I troubleshoot this further, and where is it possible that the membership is cached? Ole Thomsen List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Sticky group membership - Solved
Dean, Would you be as kind as to elaborate on the other issues with Group Membership Crashing? I know you're not into the 'joe' model of writing novels, but I'm interested in what you've noted and why it occurs. -rtk -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, May 21, 2005 1:10 PM To: Send - AD mailing list Subject: RE: [ActiveDir] Sticky group membership - Solved May I ask why it was on in the first place? The caching of global groups is but one of many inadequacies! -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 10:00 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens are only updated during authentication. This means that if you have a group membership change and then connect to a remote resources you can get that new token if you completely break any previous sessions with the remote resource, then purge your kerberos tickets, and then reconnect to the resource. For interactive logons (i.e. you have a desktop associated with the logon) you need to log off and log on. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Saturday, May 14, 2005 1:18 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Sticky group membership Environment: Three W2K3 DC's and ten WTS (no SP1), all located on the same subnet. We have GPO's applied based on group membership. A few policies are only intended to be active for some hours, blocking execution of specific applications. After adding the users to the group, the policy is active almost immediately on the terminal servers - but after removing users from the group, the GPO's are still applied on some. GPresult shows that the users are still seen as member of the group, while running MemberOf against every DC says they are not? How can I troubleshoot this further, and where is it possible that the membership is cached? Ole Thomsen List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Sticky group membership - Solved
Yep, Dean lovingly calls this AD feature Global Group Crashing. He wasn't thrilled with the feature back when it was still in beta last I spoke to him about it. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Adner Sent: Sunday, May 15, 2005 6:49 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved That's because Universal Group Membership Caching also caches global groups. Didn't its name make that obvious? ; You don't want to enable it in a Site that has both GC's and non-GC's or you'll run into the behavior you observed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 09:00 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens are only updated during authentication. This means that if you have a group membership change and then connect to a remote resources you can get that new token if you completely break any previous sessions with the remote resource, then purge your kerberos tickets, and then reconnect to the resource. For interactive logons (i.e. you have a desktop associated with the logon) you need to log off and log on. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Saturday, May 14, 2005 1:18 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Sticky group membership Environment: Three W2K3 DC's and ten WTS (no SP1), all located on the same subnet. We have GPO's applied based on group membership. A few policies are only intended to be active for some hours, blocking execution of specific applications. After adding the users to the group, the policy is active almost immediately on the terminal servers - but after removing users from the group, the GPO's are still applied on some. GPresult shows that the users are still seen as member of the group, while running MemberOf against every DC says they are not? How can I troubleshoot this further, and where is it possible that the membership is cached? Ole Thomsen List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Sticky group membership - Solved
I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens are only updated during authentication. This means that if you have a group membership change and then connect to a remote resources you can get that new token if you completely break any previous sessions with the remote resource, then purge your kerberos tickets, and then reconnect to the resource. For interactive logons (i.e. you have a desktop associated with the logon) you need to log off and log on. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Saturday, May 14, 2005 1:18 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Sticky group membership Environment: Three W2K3 DC's and ten WTS (no SP1), all located on the same subnet. We have GPO's applied based on group membership. A few policies are only intended to be active for some hours, blocking execution of specific applications. After adding the users to the group, the policy is active almost immediately on the terminal servers - but after removing users from the group, the GPO's are still applied on some. GPresult shows that the users are still seen as member of the group, while running MemberOf against every DC says they are not? How can I troubleshoot this further, and where is it possible that the membership is cached? Ole Thomsen List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Sticky group membership - Solved
That's because Universal Group Membership Caching also caches global groups. Didn't its name make that obvious? ; You don't want to enable it in a Site that has both GC's and non-GC's or you'll run into the behavior you observed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Sunday, May 15, 2005 09:00 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership - Solved I think I found a solution, at least I cannot provoke the error anymore. Tests showed that the error was connected to one DC, every time the false mebership was active it was the latest installed DC that processed the logon. Investigation eventlogs on the DC gave sporadic warnings of group membership cache refresh. I turned off Universal Group Membership Caching, and now all seems to be well :-) What I don't understand is why this setting was influencing a global group, but maybe someone here can enlighten me? Thanks, Ole Thomsen -Original Message- From: Ole Thomsen Sent: Saturday, May 14, 2005 10:11 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership I am well aware of the fact that group membership is only updated during a new logon. But this false membership can stick for several days, and we reboot the terminal servers every night. My test user were removed from the group two days ago, and still get the GPO applied on some of the servers. As far as I can see the membership is recognized correctly on the network and file servers - just not during logon. Thanks, Ole Thomsen -Original Message- From: joe [mailto:[EMAIL PROTECTED] Sent: Saturday, May 14, 2005 8:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Sticky group membership User security tokens are only updated during authentication. This means that if you have a group membership change and then connect to a remote resources you can get that new token if you completely break any previous sessions with the remote resource, then purge your kerberos tickets, and then reconnect to the resource. For interactive logons (i.e. you have a desktop associated with the logon) you need to log off and log on. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ole Thomsen Sent: Saturday, May 14, 2005 1:18 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Sticky group membership Environment: Three W2K3 DC's and ten WTS (no SP1), all located on the same subnet. We have GPO's applied based on group membership. A few policies are only intended to be active for some hours, blocking execution of specific applications. After adding the users to the group, the policy is active almost immediately on the terminal servers - but after removing users from the group, the GPO's are still applied on some. GPresult shows that the users are still seen as member of the group, while running MemberOf against every DC says they are not? How can I troubleshoot this further, and where is it possible that the membership is cached? Ole Thomsen List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
