RE: [ActiveDir] Domain Local Groups vs Global Groups

[Dan Holme]

Title: Message

Local groups are “so 1990s” <grin>… because they exist on individual systems, they are virtually un-manageable (save via Restricted Groups policies).  Fugghedaboutem.   DOMAIN LOCAL groups are what you probably mean, or should mean.  They exist as a single instance in Active Directory, instead of the multiple-local-groups-one-each-server model of NT4.   The best practice in a SINGLE DOMAIN (or a single ‘active’ domain with an empty forest root domain) is:                 Users à Global Groups  - - - > Global Groups à Domain Local Groups - - - > Domain Local Groups à ACL Users go into global groups (which in Windows Server 2000 or greater domain functional level can be further nested into other global groups if necessary). Global groups nest into domain local groups. ACLs are assigned to domain local groups.   In a multidomain forest, best practice is the above *OR*                 Users à Global Groups - - - > Global Groups à Universal Groups - - - > Universal Groups à Domain Local Groups - - - > Domain Local Groups à ACL                 Or                 Users à Global Groups | Universal Groups à ACL Universal groups are really useful in multidomain forests for defining things like “My Company Executives” where each domain has a (global) Executives role defined, and those nest into a ‘super group’   WHY this complexity?  It yields optimal replication (though that’s more of a technicality these days, in a single domain, since many/most organizations are making every DC a global catalog server).  More importantly, it sets you up for effective role-based management in a dynamic enterprise.  Domain Local Groups as the “access group” enable cross-domain access which may not seem important to you today (‘we have just one domain’) but will become important the day there’s a joint venture, acquisition, merger, etc…  If it seems to complex to figure out the “why” then stop asking and just do it ;-)   There is no *technical* “better or worse” about ACLing resources to global groups.  For that matter, you could ACL resources to each and every user.  Why don’t you do that?  Because it’s “obviously” unmanageable.  Doing it to global groups is equally, if not as obviously, unmanageable, particularly in the long term.  That said, there’s a very minor technical difference that deals with the size of your PAC in your Kerberos ticket, so please don’t take me to the matt for not detailing that… it’s technical more than practical.   What should be driving your design is the need for ROLE BASED MANAGEMENT of your enterprise.   Role based management, as far as “resources” goes, should be discussed in terms of Roles (people / groups of people) and Management (in this case, managing access to a resource).   Roles define who someone is – you could ‘describe’ them by their roles (job, function, department, business unit, geographical location, seniority, etc.).  Just so happens that roles should be defined using global security groups and yes, roles nest within roles (global à global) so your departmental management role groups might very well nest into a ‘corporate managers’ role group.  Say, for example, that you define your brokers as to whether they are ‘just brokers’ (global group: ROLE_Brokers) or ‘supervisors’ (ROLE_Broker_Sups).  Let’s say you also have a team of auditors (ROLE_Auditors)   Management groups (for dealing with resource access, in this case) are typically domain local groups.  But don’t think of them as their technical scope (domain local) – think of them as their purpose: to manage access to a resource.  So, for example, if you have a share for your “broker data”, you might have the following resource access management groups that parallel specific access levels to that share: Ø  ACL_BrokerData_Editors      (ACL = a group for access control; Editors = MODIFY permission) Ø  ACL_BrokerData_Contributors  (Contributors = permissions to create new files/folders and to modify own creations; but read-only to other people’s stuff) Ø  ACL_BrokerData_Readers   (Read access)   With those three ‘resource access’ groups, you can manage access to that resource by defining which roles get what access.  Nest your role groups into your management groups.  (global à domain local, technically).  So your business might lead you to say “brokers can add things to this share and read but not modify other people’s stuff”.  That would be nesting Role_Brokers into ACL_BrokerData_Contributors.  Role_Broker_Sups might be given ‘modify’ permission by nesting them into ACL_BrokerData_Editors.  And your auditors might be nested into the ACL_BrokerData_Readers group.   You are now headed towards ROLE BASED MANAGEMENT.  When an employee is promoted from broker to supervisor, you change their “role” membership (out of Role_Brokers, into Role_BrokerEditors) and voila, they now have access to this (and other) data store(s) based on the new role’s access.  Ideally, you tie your role groups to your HR system so that any change to roles of an employee are ‘authoritative’.   Finally, think about the ease-of-audit.  If you’ve been disciplined about (or have provisioned shares by) tying ACLs ONLY to your ‘resource management’ (ACL_xyz) groups, you can now find out “who has access to this resource” by enumerating group membership, rather than going out and hunting through ACLs on files/folders.  Even more useful if that “BrokerData” happens to be folders on several servers!   You can also easily identify the “exceptions to the rule” in your organization by looking at ACL groups and identifying any security principal that is not a “ROLE_” group…!  Very powerful stuff.   So focus on the BUSINESS of managing groups… why you want to manage groups.  I expect it will be because you want more manageability of people, resources, security, configuration, software deployment, blah blah blah… role based management.  If you can describe your business in terms of roles (people / groups of people (other roles))  and what you are trying to manage (people, resources, security, configuration, software deployment, blah blah blah) you’ll have done 90% of the work.  THEN you can turn to group scope and here’s the bottom line: roles are global; management groups are domain local unless you are managing something using Group Policy security filtering (which can only be done to global groups).   I’m doing a lot of work with role based management these days, and I’d be happy to help you out more where I can:  dan dot holme at intelliem dot com is my email.  I don’t check this group often enough, so feel free to write me directly.     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wyatt, David Sent: Wednesday, July 26, 2006 8:28 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Domain Local Groups vs Global Groups   I'd be interested to hear peoples strategy for permissioning windows based file servers when the server is in a Windows 2003 domain.  I have read the best practices about putting users into global groups then put the global groups into local groups then permission the resource with the local group.  But:   1.  Is it better practice to put the domain local group into a local group on the file server and then use this local group to permission the share/folder?  Is this excessive?  I have read something about performance or avoiding limits by using the server local group when the access token is created.   2.  What shortcomings would there be in putting users into global groups then simply permissioning the global group onto the resource.  We only have a single forest/domain.   I am also aware of Universal groups but lets put these to one side.....for the moment..;-)     Thanks David **************************************************************************** This message contains confidential information and is intended only for the individual or entity named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as an invitation or offer to buy or sell any securities or related financial instruments. GAM operates in many jurisdictions and is regulated or licensed in those jurisdictions as required. ****************************************************************************