RE: [ActiveDir] AD Groups

[GRILLENMEIER,GUIDO (HP-Germany,ex1)]

my issue with DLGs is manyfold - obviously only related to multi-domain environments. And it's not that I don't use them at all, but I don't use them as extensively as you do.  Yes I do like UGs, although the impact of replication is obviously somewhat larger - but that's the price to pay for the benefits I have and it's been minimized with LVR in 2003.  I try to avoid global groups (GG) as much as I can - we've basically limited our groups to use either DLGs or UGs, but usually it's UGs for the users and DLGs for the resources.   Issues with users in DLGs:   1. Application impact: when you have Exchange in all domains of your forest and you're using DLGs as distribution lists, then obviously the resulting memberships of a DL will be different, depending which GC the Exchange server uses.  But Exchange is just one app of many that would have this problem. And it doesn't help to use GGs and nest them in UGs - same issue. 2. Visibility: you can simply not see all the groups a user is a member of, when he's added to DLGs in different domains of the forest. This is different with UGs - you can see memberships in any domain, when connected to a GC (which most of our DCs are anyways). In 2003, a filter was added to ADUC to only show the UGs of the same domain, so that the display would be consistent with that of a non-GC DC.  This is scheduled to be "fixed" in SP1 of 2003 - you should then have the choice of either displaying all groups or just the ones of your domain. But you can always look at the "raw" data via ADSI edit or other tools to get the memberOf information. 3. Recoverability: similar issue to the above, but with a different twist: when accidentally deleting a user, the DLG memberhips in other domains are the hardest to recover. There would be much to explain here, but I'm too tired to do so right now and I know you're aware of it.  Can be avoided by using UGs as well.  Ofcourse I still need to manage the DLGs, as nesting groups is no different...  So once my solution for managing all links in a forest (inkl. DLGs) is finished, I might change my attitude, as this tool will make all memberships "visible" for any user, no mattter which domain they're from (and showing the results of group-nesting should be easy as well)     Rgd. the group-concept that I mostly implement: I use role based groups for AD delegation => here I use the UGs directly on the respective AD objects (typically OUs).  So no magic, I concentrate on the role-model and only have limited nesting (e.g. to grant a regional helpdesk permissions over various admin-units etc.).   File-Resource access is much more complicated - one of the reasons for requiring DLGs here is simply to add objects from trusted domains - something I don't usually need to do for AD delegation.  So you basically have resource-related UGs, which are member of resource related DLGs. We typically differentiate read an write permissions, but also do some nesting to control list permissions to the parent shares/folders, without needing to put the users into too many groups directly.  The whole structure is somewhat complex, but still very good to manage - especially the ongoing management, as a user only needs to be added to a single UG to either have read or write access to a specific folder.   To keep the complexity low, we only set explicit permissions up to the 3rd level of the folder structure - everything else should be inherited.  I find it easier to handle many top-level folders, than going too deep into the structure and still try to differentiate permissions.   I'm sure we can discuss more details over that beer at DEC next week ;-)   /Guido     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Montag, 15. M�rz 2004 07:17 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] AD Groups Hey occasionally I stop sitting on my brain and actually use it... :op   Note you can actually set a DL SID on a ACL if you don't accept the help of the GUI....  So say you ACL an entire directory structure or OU or whatever and then when you actually want it all to go live, change all of the groups involved from DL to Security...   Now what's your issue with DLG's... Am I right in assuming you like UNI's and that is what you stick with or do you really use a lot of Globals. And if so, do you do more role based security groups or resource based security groups?   I exposed myself and my group configurations to the world and no one else seemed to reciprocate, I am very interested in hearing what other larger companies are doing. Heck I would like to hear what smaller companies are doing if they are doing something unique meaning not UGLY.     ------------- http://www.joeware.net   (download joeware) http://www.cafeshops.com/joewarenet  (wear joeware)       From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Thursday, March 11, 2004 10:42 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] AD Groups fully agree on most of what you've said (except I'm not such a big fan of DLGs, but I see your point).   I like the idea of converting a group to a DL from a security group - I've just done a test and it really works well ;-)  The group is no longer applied to the security token of a user belonging to the group, however, the group keeps it's SID and will also still be resolved just fine when checking ACLs (you can obviously not set new permissions based on the group...). "Reactivating", i.e. turning it back to a security group, the group also worked well - good thinking Joe!   /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Donnerstag, 11. M�rz 2004 15:51 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] AD Groups Group use detection is one of the more difficult things to do in Windows.   The key thing is to have a very tight standard use process for groups. The names should tell you what they are used on and you should really put the smack down if people are found using them in a way outside of the standard. Alternatively you can force everyone to document every single use of the group. Since this means keeping additional documentation I have started work internal to the company I contract for right now to actually create a new attribute for groups called resources (or maybe joeware-Resources :oP ) which is a multivalue unicode string attribute and when you apply the group to something you you update that attribute, that way the group becomes the place to find out where it is applied, of course this only works as long as people update it. You could set up (and my future future goal) an automated system of sort that creates the group and assigns it permissions to things and updates the attribute all on one fell swoop. Most people are a ways from that and I know I am.   This problem is yet another reason why I like domain local groups so much. The scope of the problem is greatly reduced. With a gobal or universal group the scope of your checking for its use is all domains in the forest, all domains that trust the domain that the group exists in. This could be trusted NT4, other Windows forests, etc. With a domain local group the scope is limited to the one domain and the members thereof. This is also why I don't like seeing groups named HR-DEPT or other role based groups because people tend to see them and say, oh yeah, that is who I want, and apply that to whatever they are trying to secure. I understand the reasoning behind role based stuff like that, but much prefer resource securing with resource specific groups. Actually I think it would be cool if you could have a role based group that can't have permissions applied to it. It can however, be nested in resource specific groups that can have permissions applied. (Hey Stuart/Eric you listening, am I on crack here?).   Now where do you check for use if you have no idea where it is being used?   You have to check every ACL on every file on every folder on every machine within the group's scope. You have to check the rights assignments in every machine and every gpo within the group's scope. You have to check the acl on every registry key of every machine within the group's scope. You have to check the ACL of every AD object in the group's scope. You have to check the ACL of every service on every machine within the group's scope. You have to check the ACL of every file share of every machine within the group's scope. If you have Exchange you have to check every ACL (and MAPI Role Property) of every mailbox within the group's scope. If you have fun programmers or vendors with fun programmers who really play with security you could possibly have to check every single securable kernel object within the group's scope. This could be named pipes, processes, threads, job objects, etc etc. Do a search on securable kernel objects and you should be able to find a list that will take a security descriptor parameter which means they are securable.   Every person on this list could take a reasonable swipe at what objects above would *probably* be secured in their respective companies (have fun in MS hehehe). No one could make any kind of statement for all of them. Heck, I wouldn't make a statement for our company and I know what the actual standards are and bust people when they don't follow them when I catch them and we have been pushing our standards for 7+ years. Some people still just do whatever they feel like simply because they don't know better or feel that they know better and have the power.   Something I think could work is if you convert a group to a DL from a security group, it will keep its SID and it won't get stripped off of ACLs but the security tokens won't get build with the SID in it... That should effectively flush out uses of the group over time without permanently deleting the group. As people call you chase down where it might be getting used. If you see the group being converted back into a security group automatically it means somewhere Exchange is using it.       ------------- http://www.joeware.net   (download joeware) http://www.cafeshops.com/joewarenet  (wear joeware)       From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicolas Blank Sent: Thursday, March 11, 2004 2:16 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] AD Groups Another might be to check where the groups are being used. If they're used to secure file/print type resources and/or AD resources then they may be discovered using a decent reporting tool, i.e check if group X is used in AD anywhere, or is present on THAT server. You could explore this via scripts or use third party reporting tools that support ACL level reporting   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: 10 March 2004 11:23 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] AD Groups   delete one by one and see who screems ;-)   or go through a terrible audit of your whole IT environment to see which groups are used on which resoures on any joined or trusted part of your AD infrastructure.  Welcome to the downsides of the DACL (Discretionary Access Control List) model, where any owner controls ACLs on his objects => I sure hope that MS is able to keep to their plans to try to replace DACL with RBAC (Role Based Access Control) in future OSs - but they have a long way to go (won't even try to imaging the compatibility issues...).   /Guido   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Philadelphia, Lynden - Revios Toronto Sent: Mittwoch, 10. M�rz 2004 19:35 To: '[EMAIL PROTECTED]' Subject: [ActiveDir] AD Groups Is there a way that I can see what groups are not used anymore in AD.