Correct – the claims are part of the user’s Kerb ticket. So even after that attribute changes, they’ll maintain access for the lifetime of their existing ticket.
Thanks, Brian Desmond [email protected]<mailto:[email protected]> w – 312.625.1438 | c – 312.731.3132 From: [email protected] [mailto:[email protected]] On Behalf Of Charles F Sullivan Sent: Friday, January 2, 2015 1:26 PM To: [email protected] Subject: RE: [NTSysADM] Dynamic Access control in Windows Server 2012 R2 question I can only guess at this, but if you were using the old method of simply relying on group membership and you had removed the user from a group which had access while they were logged on to a computer, they would still have access from that computer (based on the access token they got when they logged while having membership in the group). As far as I know from my own experience, they would continue to have access until they logged off from the machine, or until their Kerberos ticket reached its end of life. I think, though I’m not sure, that DAC also relies on the user’s access token. I’m hoping someone else has a more definitive answer. One thing that makes me question my own contention is that it was only 10 minutes, though it’s possible that the Kerberos ticket only had 10 minutes left to its TTL. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Christopher Bodnar Sent: Friday, January 2, 2015 10:45 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] Dynamic Access control in Windows Server 2012 R2 question Just got around to playing with this in a Dev environment. Very interesting stuff. Got it all to work perfectly. Just have one question. So for my Dev environment I had a test setup where it would allow access to a share based on the “department” attribute in AD. If in “Sales” or “HR”, allow. Worked great. Then what I did was modify one of the “Sales” users department attribute. So they had access before…. Then after the change it should have denied them access. I found in testing (using the effective permissions tab on the file server) that it took about 10 minutes for this to deny the user. That surprised me. It wasn’t a change to any of the DAC items (policy, list, etc…), nor was it a Group Policy change. It was a change to the attribute of the user. So where was that being cached, that it took 10 minutes? In my test environment I only have 1 DC. Also, from what I have read…. a Windows 7 client should work with this. So far I’ve only tested with a 2012 R2 client. Can anyone confirm that? Thanks Christopher Bodnar Enterprise Architect I, Corporate Office of Technology:Enterprise Architecture and Engineering Services Tel 610-807-6459 3900 Burgess Place, Bethlehem, PA 18017 [email protected]<mailto:> [cid:[email protected]] The Guardian Life Insurance Company of America www.guardianlife.com<http://www.guardianlife.com/> ________________________________ ----------------------------------------- This message, and any attachments to it, may contain information that is privileged, confidential, and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are notified that any use, dissemination, distribution, copying, or communication of this message is strictly prohibited. If you have received this message in error, please notify the sender immediately by return e-mail and delete the message and any attachments. Thank you.
