Наша компания пытается переосмыслить наш подход к управлению разрешениями сотрудников на доступ к файлам проекта в нашем домене. Мы рассматриваем создание новой группы AD для каждого офисного проекта, а затем добавление пользователей в группы по мере того, как сотрудники работают над проектами. (Прямо сейчас учетные записи пользователей индивидуально добавляются или удаляются из соответствующих папок проекта сценарием, когда они присоединяются к проекту или покидают его.)
Беспокоит то, что у нас есть ~ 300 новых проектов в год, так что потенциально таких групп могут быть тысячи. Кроме того, пользователи могут работать над многими проектами в течение многих лет, поэтому каждый пользователь потенциально может быть членом сотен групп.
Вызывает ли беспокойство любое из этих чисел? Мы не хотим создавать ситуацию, которая заставит контроллер домена бороться или выходить за пределы AD.
На самом деле вы не определяете свою топологию репликации, которая может здесь сыграть роль. Если у вас есть один сайт со всеми контроллерами домена в одной локальной сети, репликация не будет вашей проблемой. Простые тысячи групп обычно не проблема, если только у вас нет серьезных ограничений на репликацию (например, вы делаете это по всей стране, используя две консервные банки и кусок веревки).
Проблема, с которой вы можете столкнуться, заключается в том, что токен доступа пользователя может содержать только 1024 SID. Если пользователь является членом примерно 1000 групп, некоторые идентификаторы безопасности не могут быть добавлены к токену, что приведет к сбою доступа при попытке использовать ресурс, для которого требуется этот токен.
Короче говоря, если у вас есть пользователь, который является членом 1000 групп, у вас возникнут проблемы. Если нет, то все в порядке.
Эта статья TechNet довольно хорошо освещает проблему и этот документ Microsoft подробно объясняет это (предупреждение: прямая ссылка на текстовый документ).
Это зависит от того, как вы планируете масштабироваться.
Сначала вы должны использовать вложенные группы и RBAC подходить.
Для масштабирования вам потребуются другие контроллеры домена, которые будут брать на себя нагрузку с основного. Вам нужно будет разработать приложение, чтобы иметь возможность аварийного переключения для служб DNS, LDAP, Kerberos. Возможно, вам потребуется разделить вашу структуру на разные подразделения. Это поможет вам делегировать и иметь меньше объектов в OU.
Прежде чем вносить большие изменения, выполните поиск, попробуйте воспроизвести вашу текущую настройку в тестовой среде и провести нагрузочное тестирование на основе текущих запросов (сделайте базовый план). Затем внесите изменения в тестовую среду и снова выполните нагрузочный тест, предполагая большее количество запросов.