Я планирую создать домен на базе Windows Server 2008 для 70 компьютеров и 50+ пользователей, который будет распределен по двум разным зданиям, которые соединены выделенной линией 100 Мбит / с. Я планирую использовать один домен с контроллером домена в каждом из двух зданий. Мы планируем вырасти до более чем 150 компьютеров и 100 пользователей в течение 3 лет. Большая часть нашей работы связана с большим доступом к файлам (на данный момент несколько ТБ файловых серверов) и некоторым специализированным исследовательским оборудованием и программным обеспечением.
Я не уверен, как лучше всего организовать пользователей в домене. Стоит ли организовывать их в организационные единицы? Должен ли я использовать вместо этого группы? Комбинация обоих? Даже несколько доменов? Не могли бы вы предложить какие-нибудь рекомендации для такого размера и сложности?
Спасибо заранее.
Вам не нужна многодоменная среда. Вы используете мультидоменную среду только тогда, когда вы иметь к (разные политики паролей для разных пользователей в среде Windows 2003, использование домена в качестве границы репликации для двух или более очень больших сред). Среда с одним доменом - лучший вариант.
Вы правы, разместив хотя бы один DC в каждом физическом месте. Убедитесь, что вы настроили конфигурацию «Сайт» и «Подсеть» AD, чтобы AD мог принимать интеллектуальные решения о репликации и (что более важно) клиентские компьютеры могли принимать интеллектуальные решения о том, с каким контроллером домена они разговаривают во время входа в систему. Оба контроллера домена должны быть отмечены как серверы «Глобального каталога» и должны предоставлять службы DNS для компьютеров в их местоположении. (Вы должны указать удаленный контроллер домена в качестве вторичного DNS-сервера для ПК, но вы хотите, чтобы они сначала разговаривали с контроллером домена в своем местоположении.)
Организация пользователей, компьютеров, групп и других объектов в подразделения в вашей Active Directory (AD) основана на двух критериях:
В качестве третьей задачи вы можете организовать объекты в AD так, чтобы их было легко визуально найти, но это чисто эстетическая задача.
Делегирование управления связано с изменением разрешений по умолчанию в AD, чтобы позволить другим пользователям выполнять административные задачи. Представьте себе сценарий, в котором у вас есть удаленный филиал и «опытный ИТ-пользователь» в этом офисе, который хочет сбросить пароли для пользователей, которые забыли свой пароль в своем офисе.
Передав ей управление (поместив ее в группу и делегировав управление группе) для сброса паролей. только в подразделении, где расположены объекты учетных записей пользователей, представляющие пользователей в ее офисе (возможно, в дочерних подразделениях - делегирование по умолчанию наследуется дочерним подразделениям), вы предоставляете ей возможность сбрасывать пароли только для этих пользователей.
В небольшой организации может не быть большого объема делегирования управления, но это то, о чем вы должны хотя бы подумать при «белой доске» вашей потенциальной конфигурации.
Групповая политика обычно применяется к пользователям или компьютерам путем связывания объектов групповой политики с подразделениями. (Можно использовать групповую политику вообще без каких-либо подразделений, но это большая проблема и нереальная стратегия развертывания.) Если вам нужно было установить приложение через «Политику установки программного обеспечения» на все ПК в бухгалтерии, например, имея ПК, организованные в подразделения, представляющие отделы, дадут вам простой способ нацелить объект групповой политики на все эти ПК.
Применение групповой политики можно контролировать с помощью других средств (членство в группе пользователя или компьютера, фильтрация WMI, IP-подсеть с помощью объектов групповой политики, связанных в объектах «Сайт»), тогда как делегирование управления может работать только на основе OU. . Таким образом, делегирование управления является вашей первой приоритетной задачей при проектировании (т.е. убедитесь, что предложенный макет подразделения работает для вашей желаемой стратегии делегирования управления), а применение групповой политики (которое является более гибким) является второстепенной задачей.
Возможно, вам стоит попросить кого-нибудь, знакомого с Active Directory, сесть с вами на пару часов и задать вам несколько вопросов о том, как вы хотите использовать свою AD для разработки предлагаемого дизайна. Похоже, что среда довольно проста, а иерархии подразделений легко перепроектировать в будущем, но хороший консультант по AD может дать вам несколько отличных идей, которые по мере вашего роста позволят вам минимизировать административные расходы и упростить предоставление функций пользователям. .
Редактировать:
Я бы не согласился с утверждением в вашем комментарии относительно: «иерархия OU должна копировать структуру моей организации». Иерархия подразделений должна поддерживать желаемое делегирование управления и стратегии применения групповой политики. Если это окажется похоже на вашу "организационную схему" или другую организационную схему, пусть будет так. Тем не менее, AD не является «организационной схемой», и вы не должны предполагать, что иерархия OU в конечном итоге будет выглядеть как любая существующая организационная диаграмма.
Группы безопасности используются для предоставления разрешений таким ресурсам, как общие папки. (Вы также можете указывать отдельных пользователей в разрешениях, но не должны исключать таких крайних случаев, как домашние каталоги.) Подразделения не являются «участниками безопасности», т. Е. Они не имеют связанного с ними идентификатора безопасности (SID) и поэтому не может быть назван в разрешениях.
Иерархия AD OU используется для управления применением групповой политики.
Разрешения, установленные в иерархии подразделений (и структура иерархии под этими разрешениями) управляют делегированием административных обязанностей в Active Directory.
Иногда возникает ощущение дублирования, когда приходится создавать, скажем, OU «Учет» и группу безопасности «Учет». К сожалению, продукт был разработан именно так. Я не могу сказать, что сталкивался с подобными ситуациями во многих случаях.
Что немного сбивает с толку, так это идея о том, что группа безопасности является объектом AD и, следовательно, ее разрешения могут быть изменены, чтобы позволить произвольному набору пользователей управлять членством в группе. Эта группа, в свою очередь, может использоваться для управления другими типами доступа (например, разрешениями на общие папки или разрешениями на выполнение дополнительных административных задач в AD). Самая легкая для понимания группа такого рода - «Администраторы домена». Делегирование кому-либо прав на контроль членства в группе «Администраторы домена» может (намеренно или непреднамеренно) предоставить этому делегированному администратору право повышать кого-либо (возможно, себя) до «Администратора домена».
По сути, делегирование контроля над членством в группах безопасности должно быть хорошо продумано во время разработки. С ним можно делать действительно мощные и интересные вещи, но нужно все продумать.