| Author |
 Topic  |
|
|
Hawkster
Seasoned But Casual Onlooker
USA
54 Posts
Status: offline |
 Posted - 01/20/2006 : 3:06:46 PM
|
Ok guys, we all know the best practive of AGDLP for handling domain groups and applying security to resources. For those a bit rusty on it, here's the short explanation:
“To use groups effectively, administrators should add domain user accounts (A) into global groups (G), add global groups into domain local groups (DL), and then add the domain local group to the security properties page of the target resource (that you wish to manage), and set the permission (P) access control list to reflect the appropriate level of permission. This strategy, called AGDLP, provides the most flexibility while reducing the complexity of assigning access permissions to resources.”
My question is this - in practice, how good are you about doing this? I've seen several environments now that basically stick with Global groups, assign these directly to resources, put their users in these global groups and away they go! This may be good in small, single domain situations, but can get to be a mess beyond that.
However, going with the Best Practice also doubles the amount of groups over the method above (i.e. One Domain Local, with a nested Global every time you need a new group for something). Of course, the best practice is there for a reason, mainly ease of security configuration between resources in trusted domains.
What do you mostly see out there and what do you do? Are you following best practices? 
|
Edited by - Hawkster on 01/20/2006 3:08:04 PM |
|
|
wkasdo
Administrator
Netherlands
6233 Posts
Status: offline |
Posted - 01/21/2006 : 1:55:13 PM
|
| This particular best practice is designed for a multi-domain environment, as you say. If you are sure you will never have that, you can stick with global groups. Or universals, for that matter. |
 |
|
|
terry712
Here To Stay
134 Posts
Status: offline |
Posted - 01/22/2006 : 07:42:53 AM
|
working predominately with netware - this area has always been confusing to me
i cant help feel it's a legacy from the bindery days of nt were you needed the two groups for it to work
i have recently started to deploy a 2003 setup for part of our business and struggled to decide whether to use this policy or just stick with the one. although i cant forsee us ever crossing domains etc - i have adopted the agdlp - it takes a bit longer and does seem to have a bit of redundant group feel and i have to hum the ryhme to myself everytime i go near a group but cant help feel that someday if it does come necessary to use it then it may come back and haunt me and it would be harder to modify it later
personally from discussion in other forums - i feel people who have come from nt background - always use it but if you havent worked with nt and only ad then you tend to ignore it as it seems overly complex
|
Edited by - terry712 on 01/22/2006 07:44:24 AM |
|
|
|
Playwell
Honorable But Hopeless Addict
Netherlands
4106 Posts
Status: offline |
Posted - 01/22/2006 : 08:29:40 AM
|
In terms of daily operations in a single domain you are probably right to use global groups. However, if you have multple domains, or planning too, local groups is the way to go. The big advantage of using local groups is that local groups do not have sids. This means that in case of a migration the data can be used in any domain, if those local groups are added.
Hope i made some sense.. |
'People who think they know everything are a great annoyance to those of us who do. '
Quote by Isaac Asimov |
|
|
|
wkasdo
Administrator
Netherlands
6233 Posts
Status: offline |
Posted - 01/23/2006 : 02:17:00 AM
|
> Hope i made some sense..
Well...
> The big advantage of using local groups is that local groups do not have sids.
I'm not sure what you meant here, but it needs just a little bit of rework ;-) |
|
|
|
joe_elway
Honorable But Hopeless Addict
Ireland
6729 Posts
Status: offline |
Posted - 01/23/2006 : 04:03:57 AM
|
I keep it simple because I like to keep AD simple:
- Single domain forest
- Users -> Domain Local/Global Group -> Permission.
The trick in this is a good naming standard and role based groups. I also banned nested permissions in file shares.
The MS defined best practice is overkill for a simple environment. However, if you are doing an MCP exam then their route is the correct answer. |
|
|
|
Hawkster
Seasoned But Casual Onlooker
USA
54 Posts
Status: offline |
Posted - 01/23/2006 : 09:57:45 AM
|
quote:
Originally posted by joe_elway
The MS defined best practice is overkill for a simple environment. However, if you are doing an MCP exam then their route is the correct answer.
I have to agree Joe...however, it's tough to have a Crystal Ball when it comes to these matters. I'm seeing a situation now where a simple environment (5 years ago) has now gotten more complicated as the business has grown. There are now a couple other domain trusts in place and the current system of all Global Groups isn't working.
Of course, there are permissions EVERYWHERE in the environment associated with these groups, so I believe the route of converting some of them to DL (via universal) is the solution that will be looked-at. I haven't read of any "gotchas" with changing the group scope, so if anyone knows of any, please share.
|
|
|
|
Braino
Welcome Newcomer
USA
2 Posts
Status: offline |
Posted - 10/25/2006 : 7:01:02 PM
|
Hey all... old thread I know... :-P
Two notes:
- Local Groups do indeed have SIDS.
- Another reason to use AGDLP (again focused at larger domains) is MaxTokenSize. This is the size of the Security token that you get when you log on. It contains all your group membership and is for resource access. If you are a member of too many groups then your token could grow over 8000 (for Win2k) or 12000 (for Win2k3) bytes which would basically break your token and keep you from authenticating. If you follow AGDLP however you can fit alot more groups in your token. That's because for Global groups, only the RID (vs the entire SID) is put in the Token.
Note this is only for 2k3 & XP. 2000 will put the full SID for all groups (although there is a 2000 hotfix for this...). you could also increase MaxTokenSize (as much as 66535!) but doing so has it's own problems... There are also more considerations if you have membership in trusted domains... but ah well.
Regards, 
Braino |
|
|
|
clarinathan
Moderator
United Kingdom
4781 Posts
Status: offline |
Posted - 11/22/2006 : 09:24:37 AM
|
quote:
could also increase MaxTokenSize (as much as 66535!) but doing so has it's own problems... There are also more considerations if you have membership in trusted domains... but ah well.
Yes on Exchange 2003 it can really make you run out of pagedpool memory if I remember correctly!
To many large tokens for not enough 32bit constricted resource.
Of course that has all gone away with 2007 Exchange!
Cheers
Nathan |
Nathan Winters - MVP Exchange Server
MCSE & MCSA 2000 & 2003 + Messaging, MCITP Exchange 2007, MCP, VMWare VCP v2 & v3.
Checkout the Messaging and Mobility User Group: http://www.mmmug.co.uk
Checkout my blog:
Unified Comms: - http://www.nathanwinters.co.uk |
|
|
|
ptwilliams
Moderator
United Kingdom
4401 Posts
Status: offline |
Posted - 11/22/2006 : 09:44:30 AM
|
Hi Brian, and welcome to the forum!
Have a look at this for some info. on token bloat:
-- http://web2.minasi.com/forum/topic.asp?TOPIC_ID=19907
While what you are saying is correct in that it is documented, I don't believe it's as big an issue as some of the documentation states.
The point I'm trying to get at is yes, that can and will happen, but that's just a client side pile of crap. The real aspect of this is the Kerberos PAC, which will take about 1020 SIDs.
|
|
|
|
ptwilliams
Moderator
United Kingdom
4401 Posts
Status: offline |
Posted - 11/22/2006 : 09:47:04 AM
|
Oh yeah Nathan, that's a nice one. That's where, if I remember correctly, Exchange is forced to use either 8KB of 12KB "chunks" of paged-pool memory, causing perf. issues on the store on x86 systems due to the hard-limit on the size of the paged pool.
x64 is the way forward. If anyone can get their DCs, Exchange systems and Certificate servers, etc. onto x64 you're good to go.
|
|
|
| |
Topic |
|
Do you AGDLP?
