Every security group on a user's token adds about 45 bytes to the token and sometime around 80 security groups, you can expect a token to break 4k and bump up to 8k. This will have the most impact to Exchange until you bump up to Exchange 2007 and 64-bit OS.
When debating between server local and domain groups (whether domain global or domain local), you have to decide between ease of management (domain groups) and ease on tokens (server local groups).
Ideally, you will have an RBS model in place where a user is a member of a half dozen or so role-based groups which will grant access to shares instead of an Access Based Security (ABS) model. ABS creates a group (or groups) for each resource that needs access defined and then places all users and/or groups within that group. That's great in a user domain/resource domain architecture. If you don't have that though, you are just using a lot of redundant groups.
I would recommend securing your shares and/or resources with role-based groups first, then if additional persons need access to a share or resourse, then grant them access through the ABS group at the domain level. Having to connect to 25 different file shares to manage share security is insane and nesting each group into 2-12 other groups ends up with a security model that quickly becomes very convoluted and difficult to map out. The one thing that an ABS model does do is make auditing access easier. But if you're making your day to day management of that model significantly more time consuming (by going with server local groups), then it's probably just easier to start defining items by RBS groups instead anyway. Not to mention that auditing server local groups is almost as much of a pain, if not more of one, as getting a tool that will go out and show you the share-level (or even file/directory level) ACLs ( www.winzero.ca has one).
I know that MS recommends local server groups as an alternative when users end up with large amounts of security groups, but I feel that managing those objects is unwieldy enough (particularly in larger environments with a large number of file servers) to where you'd almost need to add a small team just to manage the shares. I'd rather double my number of Exchange servers and have everyone at an 8k tokens than add 4 employees at $x per hour just to manage server local groups.
That's my take on it... I'm sure you'll end up with another 20 other opinions from 20 other people though.
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..;-)ThanksDavid****************************************************************************
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.
****************************************************************************
