5

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.

Improve this question

2 Answers 2

Reset to default
8

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).

Improve this answer
1
  • 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, 2012 at 16:24
1

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.

Improve this answer
4
  • 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, 2012 at 14:55
  • The bulk of this answer makes no sense to me in relation to the context of the question.
    – joeqwerty
    Dec 11, 2012 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, 2012 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, 2012 at 15:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .