Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Our company is trying to rethink our approach to managing permissions among employees for access to project files in our domain. We're considering creating a new AD Group for each office project and then adding users to the groups as employees work on projects. (Right now, user accounts are individually added or removed from relevant project folders by a script when they join or leave a project.)

The concern is that we have ~300 new projects a year, so there would potentially be thousands of these groups. Also, users may work on many projects over the years, so each user would potentially be a member of hundreds of groups.

Are either of those numbers a concern? We don't want to create a situation that causes the domain controller to struggle or push the limits of AD.

share|improve this question
add comment

2 Answers

up vote 7 down vote accepted

You don't really define your replication topology, which can come into play here. Assuming you have a single site with all DCs in the same LAN, replication won't be your issue. Simply having thousands of groups normally isn't a problem, unless you have severe restrictions on replication (like you do it across the country over two soup cans and a piece of string).

The problem that you may face is that a user's access token can only contain 1024 SIDs. Once the user is a member of about 1000 groups, some SIDs can't be added to the token, which will cause an access failure when trying to use a resource that requires that token.

In short, if you have a user being a member of 1,000 groups you'll have problems. If not, you're fine.

This TechNet article covers the problem pretty well and this Microsoft document explains it in depth (warning: word document direct link).

share|improve this answer
    
Also don't forget default maximum token size is 12k too, regardless of the number of SIDs in the token. Whichever limit you hit first. (Default is bumped up to 48k or so in Server 2012, but is configurable in any case.) –  Ryan Ries Dec 11 '12 at 16:24
add comment

It depends on how you plan to scale.

First you should use nested groups and a RBAC approach.

For scaling you will need other domain controllers to take the load from the primary one. You will need to design the application to be able to fail-over for DNS, LDAP, Kerberos services. You might need to split your structure in different OU. This will help you to delegate and to have less objects in an OU.

Before going to do big changes, searc, try to reproduce your current setup in a test environment and do load testing based on the current queries (make a baseline). Then do the changes in the test environment and do the load test again and assume a higher number of requests.

share|improve this answer
    
What do you mean by "For scaling you will need other domain controllers to take the load from the primary one" - It doesn't sound like he's using NT4, so there's no "primary" DC. –  MDMarra Dec 11 '12 at 14:55
    
The bulk of this answer makes no sense to me in relation to the context of the question. –  joeqwerty Dec 11 '12 at 15:29
    
No, but admins are configuring the app to point to only one DC and they do not configure the redundancy. Also some services are installed on one single DC per forest. I am talking about FSMO roles. Please correct me if I am wrong - I am more a Linux admin than a Windows one. –  Mircea Vutcovici Dec 11 '12 at 15:32
    
It sounds like these groups are just assigned to network shares that contain data for individual projects. Are we reading the same question? There don't seem to be custom apps hardcoded to point to one DC. –  MDMarra Dec 11 '12 at 15:36
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.