>Because BJ Whalen (Group Policy Program Manager) told me not to at TechEd last week. >:-)
He told me the same thing at DEC last month so it must be true :-] (It was also prominently featured on one of his slides) As far as your longer answer, that is also clearly noted in the GP white paper. "Note: Use the Deny ACE with caution. A Deny ACE setting for any group has precedence over any Allow ACE given to a user or computer because of membership in another group." I liked the way one of the MS guys put it in the GP newsgroup a while back- "I would discourage you from using "Deny" ACEs - they tend to over-complicate your security group model and make things difficult to troubleshoot. You can also get into trouble if you accidentally set a deny permission for the wrong group and end up denying them from having access to the GPO to fix it." >I vaguely recall someone telling me that Deny permissions require significantly more >processing >than Allow. I would swear I heard that somewhere too, I'll be darned if I can remember where now :-] Everyone in the know seems to strongly discourage general use of deny ACE's so I just keep that in the back of my head -----Original Message----- From: Tony Murray [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 10, 2003 9:24 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] OU and GPO Design Comments The short answer: Because BJ Whalen (Group Policy Program Manager) told me not to at TechEd last week. :-) The longer answer: I think it has to do with the fact that Deny permissions always beat Allow in the ACE. So for someone who is a member of two groups, one allowing the policy to be applied and the other denying the latter will win. This makes problems harder to troubleshoot. I vaguely recall someone telling me that Deny permissions require significantly more processing than Allow. If this is true then overuse of Deny could degrade performance. Tony ---------- Original Message ---------------------------------- Wrom: TQTIPWIGYOKSTTZRCLBDXRQBGJSNBOHMK Reply-To: [EMAIL PROTECTED] Date: Tue, 10 Jun 2003 07:28:22 -0700 Hey Tony, What's the thinking behind the recommendation "not to use Deny" for group filtering? -gil -----Original Message----- Wrom: HJYFMYXOEAIJJPHSCRTNHGSWZIDREXCAXZOWCONEUQZAA Sent: Tuesday, June 10, 2003 12:17 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] OU and GPO Design Comments If you use group filtering in this way, it is recommended not to use Deny. Instead use positive filtering. To do this, remove the Authenticated Users group from the ACL and then add the groups you want it to apply to using Apply Group Policy. Another approach would be to create an OU layer for delegation of administration, e.g. User, Computer, etc. and then have OUs at a level below these for the application of group policy. For example, under the Branch->Users OU you could have OUs called General, Lab, VIP, etc. Someone else made a point about separate OUs for workstations and laptops. This is certainly an option, but there may be a way to avoid this by using WMI filtering in the GPO. For example, WMI can identify the chassis type of the machine. Based on this information you could filter the GPO based on whether the chassis corresponds to a laptop or workstation. Tony ---------- Original Message ---------------------------------- Wrom: TZRCLBDXRQBGJSNBOHMKHJYFMYXOEAIJJPHSC Reply-To: [EMAIL PROTECTED] Date: Tue, 10 Jun 2003 00:04:25 -0400 I'm interested in feedback on the following OU and GPO design. Simple OU structure, something like: |--Branches |--Users |--Computers The "Users" OU would hold around 5000 users and the "Computers" OU an equal amount of workstations and servers. GPO's would be created for the users and linked to the OU, but only applied to certain global groups that the users would be members of. Similar for the computers. There would be an "All Users" and "All Computers" GPO with global settings, then more granular GPO's for departmental specific settings. Almost all administration would be done centrally, so there should be little need for delegation. This seems like it should be simple and effective, but we haven't tried it real-world, so I'm curious if people have any thoughts on possible gotcha's, issues, etc. -- David List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
