В наших прошлых материалах мы разобрали общие вопросы касающиеся служб каталогов и Active Directory. Теперь пришла пора переходить к практике. Но не спешите бежать к серверу, перед развертыванием доменной структуры в вашей сети необходимо ее спланировать и иметь четкое представление о назначении отдельных серверов и процессах взаимодействия между ними.
Перед тем как создавать ваш первый контроллер домена необходимо определиться с режимом его работы. Режим работы определяет доступные возможности и зависит от версии применяемой операционной системы. Мы не будем рассматривать все возможные режимы, кроме тех которые имеют актуальность на текущий момент. Таких режимов три: Windows Server 2003, 2008 и 2008 R2.
Режим Windows Server 2003 следует выбирать только тогда, когда в вашей инфраструктуре уже развернуты сервера на данной ОС и планируется использовать один или несколько таких серверов в качестве контроллеров домена. В остальных случаях нужно выбирать режим Windows Server 2008 или 2008 R2 в зависимости от купленных лицензий. Следует помнить, что режим работы домена можно всегда повысить, а вот понизить уже не удастся (разве что восстановив из резервной копии), поэтому подходите к данному вопросу осмотрительно, с учетом возможных расширений, лицензий в филиалах и т.д. и т.п.
Мы сейчас не будем подробно рассматривать сам процесс создания контроллера домена, к этому вопросу мы вернемся позже, а сейчас хотим обратить ваше внимание на то, что в полноценной структуре Active Directory контроллеров домена должно быть не менее двух . В противном случае вы подвергаете себя неоправданному риску, так как в случае отказа единственного контроллера домена ваша структура AD будет полностью уничтожена . Хорошо если будет актуальная резервная копия и из нее удастся восстановиться, в любом случае все это время ваша сеть будет полностью парализована.
Поэтому сразу же после создания первого контроллера домена нужно развернуть второй, вне зависимости от размеров сети и бюджета. Второй контроллер должен быть предусмотрен еще на стадии планирования и без него за развертывание AD даже не стоит браться. Также не стоит совмещать роль контроллера домена с любыми иными серверными ролями, в целях обеспечения надежности операций с базой AD на диске отключается кэширование записи, что приводит к резкому падению производительности дисковой подсистемы (это объясняет и долгую загрузку контроллеров домена).
В итоге наша сеть должна принять следующий вид:
Вопреки распространенному мнению, все контроллеры в домене равнозначны, т.е. каждый контроллер содержит полную информацию о всех объектах домена и может обслужить клиентский запрос. Но это не значит, что контроллеры взаимозаменяемы, непонимание этого момента зачастую приводит к отказам AD и простою сети предприятия. Почему так происходит? Самое время вспомнить про роли FSMO.
Когда мы создаем первый контроллер, то он содержит все доступные роли, а также является глобальным каталогом, с появлением второго контроллера ему передаются роли хозяина инфраструктуры, хозяина RID и эмулятора PDC. Что будет если администратор решил временно вывести из строя сервер DC1, например чтобы почистить от пыли? На первый взгляд ничего страшного, ну перейдет домен в режим "только чтение", но работать то будет. Но мы забыли про глобальный каталог и если в вашей сети развернуты приложения требующие его наличия, например Exchange, то вы узнаете об этом раньше, чем снимете крышку с сервера. Узнаете от недовольных пользователей, да и руководство вряд ли придет в восторг.
Из чего следует вывод: в лесу должно быть не менее двух глобальных каталогов, а лучше всего по одному в каждом домене. Так как у нас домен в лесу один, то оба сервера должны быть глобальными каталогами, это позволит вам без особых проблем вывести любой из серверов на профилактику, временное отсутствие каких либо ролей FSMO не приводит к отказу AD, а лишь делает невозможным создание новых объектов.
Как администратор домена, вы должны четко знать каким образом роли FSMO распределены между вашими серверами и при выводе сервера из эксплуатации на длительный срок передавать эти роли другим серверам. А что будет если сервер содержащий роли FSMO необратимо выйдет из строя? Ничего страшного, как мы уже писали, любой контроллер домена содержит всю необходимую информацию и если такая неприятность все же произошла, то нужно будет выполнить захват необходимых ролей одним из контроллеров, это позволит восстановить полноценную работу службы каталогов.
Проходит время, ваша организация растет и у нее появляется филиал в другом конце города и возникает необходимость включить их сеть в общую инфраструктуру предприятия. На первый взгляд ничего сложного, вы настраиваете канал связи между офисами и размещаете в нем дополнительный контроллер. Все бы хорошо, но есть одно но. Данный сервер вы контролировать не можете, а следовательно не исключен несанкционированный доступ к нему, да и местный админ вызывает у вас сомнения в его квалификации. Как быть в такой ситуации? Для этих целей специально существует особый тип контроллера: контроллер домена доступный только на чтение (RODC) , данная функция доступна в режимах работы домена начиная с Windows Server 2008 и выше.
Контроллер домена доступный только для чтения содержит полную копию всех объектов домена и может быть глобальным каталогом, однако не позволяет вносить никаких изменений в структуру AD, также он позволяет назначить любого пользователя локальным администратором, что позволит ему полноценно обслуживать данный сервер, но опять таки без доступа к службам AD. В нашем случае это то, что "доктор прописал".
Настраиваем в филиале RODC, все работает, вы спокойны, но пользователи начинают жаловаться на долгий вход в систему и счета за трафик в конце месяца показывают превышение. Что происходит? Самое время еще раз вспомнить про равнозначность контроллеров в домене, клиент может направить свой запрос к любому контроллеру домена, даже находящемуся в другом филиале. Примите во внимание медленный и, с большой вероятностью, загруженный канал связи - вот и причина задержек входа.
Следующий фактор, отравляющий нам жизнь в этой ситуации, это репликация. Как известно, все изменения, сделанные на одном из контроллеров домена, автоматически распространяются на другие и называется этот процесс репликацией, он позволяет иметь на каждом контроллере актуальную и непротиворечивую копию данных. Служба репликации не знает о нашем филиале и медленном канале связи и поэтому все изменения в офисе тут же будут реплицироваться в филиал, загружая канал и увеличивая расход трафика.
Здесь мы вплотную подошли к понятию сайтов AD, которые не следует путать с интернет сайтами. Сайты Active Directory представляют способ физического деления структуры службы каталогов на области отделенные от других областей медленными и/или нестабильными каналами связи. Сайты создаются на основе подсетей и все клиентские запросы отправляются в первую очередь контроллерам своего сайта, также крайне желательно иметь в каждом сайте свой глобальный каталог. В нашем случае потребуется создать два сайта: AD Site 1 для центрального офиса и AD Site 2 для филиала, точнее один, так как по умолчанию структура AD уже содержит сайт, куда входят все ранее созданные объекты. Теперь рассмотрим как происходит репликация в сети с несколькими сайтами.
Будем считать, что наша организация немного подросла и главный офис содержит целых четыре контроллера домена, репликация между контроллерами одного сайта называется внутрисайтовой и происходит моментально. Топология репликации строится по схеме кольца с условием, чтобы между любыми контроллерами домена было не более трех шагов репликации. Схема кольца сохраняется до 7 контроллеров включительно, каждый контроллер устанавливает связь с двумя ближайшими соседями, при большем числе контроллеров появляются дополнительные связи и общее кольцо как бы превращается в группу наложенных друг на друга колец.
Межсайтовая репликация происходит иначе, в каждом домене автоматически выбирается один из серверов (сервер-плацдарм) который устанавливает связь с аналогичным сервером другого сайта. Репликация по умолчанию происходит раз в 3 часа (180 минут), однако мы можем установить собственное расписание репликации и для экономии трафика все данные передаются в сжатом виде. При наличии в сайте только RODC репликация происходит однонаправленно.
В 2002 году, прогуливаясь по коридору кафедры информатики своего любимого университета, я увидел на двери кабинета «Системы NT» свежий плакат. На плакате были изображены иконки пользовательских аккаунтов, объединенные в группы, от которых в свою очередь отходили стрелки к другим иконкам. Все это схематично объединялось в некую структуру, было написано что-то про единую систему входа, авторизацию и тому подобное. Насколько сейчас понимаю на том плакате была изображена архитектура систем Windows NT 4.0 Domains и Windows 2000 Active Directory. С этого момента началось и сразу же закончилось мое первое знакомство с Active Directory, так как потом была тяжелая сессия, веселые каникулы, после которых друг поделился дисками FreeBSD 4 и Red Hat Linux, и на ближайшие несколько лет я погрузился в мир Unix-подобных систем, но содержимое плаката я так и не забыл.
К системам на платформе Windows Server мне пришлось вернуться и более тесно с ними познакомиться, когда я перешел работать в компанию, где управление всей ИТ-инфраструктурой было основано на Active Directory. Помню, что главный админ той компании на каждом совещании все время что-то твердил про какие-то Active Directory Best Practices. Теперь, после 8 лет периодического общения с Active Directory, я достаточно хорошо понимаю, как работает данная система и что такое Active Directory Best Practices.
Как вы уже, наверное, догадались, речь пойдет про Active Directory.
Всем, кому интересна данная тема, добро пожаловать по кат.
Данные рекомендации справедливы для клиентских систем начиная с Windows 7 и выше, для доменов и лесов уровня Windows Server 2008/R2 и выше.
Стандартизация
Планирование Active Directory следует начать с разработки своих стандартов назначения имен объектов и их расположения в каталоге. Необходимо создать документ, в котором определить все необходимые стандарты. Конечно, это довольно частая рекомендация для ИТ специалистов. Принцип «сначала пишем документацию, а потом по данной документации строим систему» является очень хорошим, но он редко реализуем на практике по многим причинам. Среди этих причин - простая человеческая лень или отсутствие соответствующей компетенции, остальные причины являются производными от первых двух.
Рекомендую - сначала напишите документацию, все обдумайте и только потом приступайте к инсталляции первого контроллера домена.
Для примера приведу раздел документа по стандартам названия объектов Active Directory.
Именование объектов.
- Название пользовательских групп должно начинаться с префикса GRUS_ (GR - Group, US - Users)
- Название компьютерных групп н должно начинаться с префикса GRCP_ (GR - Group, CP - Computers)
- Название групп делегирования полномочий должно начинаться с префикса GRDL_ (GR - Group, DL - Delegation)
- Название групп доступа к ресурсам должно начинаться с префикса GRRS_ (GR - Group, RS - resources)
- Название групп для политик должно начинаться с префиксов GPUS_, GPCP_ (GP - Group policy, US - Users, CP - Computers)
- Название клиентских компьютеров должно состоять из двух, трех букв от названия организации, за которыми через дефис должен следовать номер, например, nnt-01.
- Название серверов должно начинаться только из двух букв, за которыми через дефис должна следовать роль сервера и его номер, например, nn-dc01.
Ваш подход к написанию документации должен быть очень основательным, это позволит сэкономить большое количество времени в дальнейшем.
Упрощайте все, что возможно, старайтесь достигнуть равновесия
При построении Active Directory необходимо следовать принципу достижения равновесия, делая выбор в пользу простых и понятных механизмов.
Принцип равновесия заключается в том, чтобы достигнуть необходимого функционала и безопасности при максимальной простоте решения.
Необходимо стараться построить систему так, чтобы ее устройство было понятно самому не искушенному администратору или даже пользователю. Например, в свое время была рекомендация создавать структуру леса из нескольких доменов. Более того рекомендовалось разворачивать не только мультидоменные структуры, но и структуры из нескольких лесов. Возможно, такая рекомендация существовала из-за принципа «разделяй и властвуй», либо потому-то Microsoft всем твердила, что домен - это граница безопасности и разделив организацию на домены, мы получим отдельные структуры, которые проще контролировать по отдельности. Но как показала практика, что более просто обслуживать и контролировать однодоменные системы, где границами безопасности являются организационные единицы (OU), а не домены. Поэтому избегайте создания сложных мультидоменных структур, лучше группируйте объекты по OU.
Конечно, следует действовать без фанатизма, - если невозможно обойтись без нескольких доменов, то нужно создавать несколько доменов, также и с лесами. Главное, чтобы вы понимали, что делаете, и к чему это может привести.
Важно понимать, что простую инфраструктуру Active Directory проще администрировать и контролировать. Я бы даже сказал, что чем проще, тем безопаснее.
Применяйте принцип упрощения. Старайтесь достигнуть равновесия.
Соблюдайте принцип – «объект - группа»
Начинайте создание объектов Active Directory с создания группы для данного объекта, и уже группе назначайте необходимые права. Рассмотрим на примере. Вам необходимо создать аккаунт главного администратора. Создайте сначала группу Head Admins и только потом создайте сам аккаунт и добавьте его в данную группу. Группе Head Admins назначьте права главного администратора, например, добавив ее в группу Domain Admins. Почти всегда получается так, что через некоторое время приходит на работу еще один сотрудник, которому нужны аналогичные права, и вместо того, чтобы заниматься делегированием прав на разные разделы Active Directory, будет возможно просто добавить его в необходимую группу, для которой в системе уже определена роль и делегированы необходимые полномочия.
Еще один пример. Вам необходимо делегировать права на OU с пользователями группе системных администраторов. Не делегируйте права напрямую группе администраторов, а создайте специальную группу вроде GRDL_OUName_Operator_Accounts, которой назначьте права. Потом просто добавьте в группу GRDL_OUName_Operator_Accounts группу ответственных администраторов. Обязательно получиться так, что в скором будущем, вам понадобиться делегировать другой группе администраторов права на данную OU. И в этом случае вы просто добавите группу данных администраторов в группу делегирования GRDL_OUName_Operator_Accounts.
Предлагаю следующую структуру групп.
- Группы пользователей (GRUS_)
- Группы администраторов (GRAD_)
- Группы делегирования (GRDL_)
- Группы политик (GRGP_)
- Группы серверов (GRSR_)
- Группы клиентских компьютеров (GRCP_)
- Группы доступа к общим ресурсам (GRRS_)
- Группы доступа к принтерам (GRPR_)
Соблюдайте принцип равновесия, ограничьте количество ролей для групп и помните, что название группы должно в идеале полностью описывать ее роль.
Архитектура OU.
Архитектуру OU в первую очередь следует продумывать с точки зрения безопасности и делегирования прав на данную OU системным администраторам. Не рекомендую планировать архитектуру OU с точки зрения привязки к ним групповых политик (хотя так чаще всего и делают). Для некоторых покажется немного странной моя рекомендация, но я не рекомендую вообще привязывать групповые политики к OU. Подробности читайте в секции Групповые политики.
OU Admins
Рекомендую выделить для административных аккаунтов и групп отдельную OU, куда поместить аккаунты и группы всех администраторов и инженеров технической поддержки. К данной OU следует ограничить доступ для обычных пользователей, а управление объектами из данной OU делегировать только главным администраторам.
OU Computers
OU для компьютеров лучше всего планировать с точки зрения географической принадлежности компьютеров и типов компьютеров. Распределите компьютеры с разных географических локаций по разным OU, а их в свою очередь разделите на клиентские компьютеры и серверы. Серверы можно еще поделить на Exchange, SQL и другие.
Пользователи, права в Active Directory
Пользовательским аккаунтам Active Directory следует уделять особое внимание. Как было сказано в секции про OU, пользовательские аккаунты следует группировать исходя из принципа делегирования полномочий на данные аккаунты. Также важно соблюдать принцип минимальных привилегий - чем меньше у пользователя прав в системе, тем лучше. Рекомендую сразу закладывать уровень привилегий пользователя в название его аккаунта. Аккаунт для повседневной работы должен состоять из Фамилии пользователя и инициалов на латинице (Например, IvanovIV или IVIvanov). Обязательными полями являются: First Name, Initials, Last Name, Display Name (на русском), email, mobile, Job Title, Manager.
Аккаунты администраторов должны быть следующих типов:
- С правами администратора на пользовательские компьютеры, но не серверы. Должны состоять из инициалов владельца и приставки local (Например, iivlocal)
- С правами на администрирование серверов и Active Directory. Должны состоять только из инициалов (Например, iiv).
Поясню, зачем следует разделять административные аккаунты на администраторов серверов и администраторов клиентских компьютеров. Делать это необходимо, из соображений безопасности. Администраторы клиентских компьютеров будут иметь право на установку софта на клиентских компьютерах. Какой и для чего софт будет устанавливаться, сказать никогда точно нельзя. Поэтому запускать установку программы с правами доменного администратора небезопасно, можно скомпрометировать весь домен. Необходимо администрировать клиентские компьютеры только с правами локального администратора данного компьютера. Это сделает невозможным целый ряд атак на аккаунты доменных администраторов, вроде «Pass The Hash». Дополнительно администраторам клиентских компьютеров необходимо закрыть подключение через службу терминалов и подключение по сети к компьютеру. Компьютеры технической поддержки и администраторов следует поместить в отдельный VLAN, чтобы ограничить к ним доступ из сети клиентских компьютеров.
Выделение прав администратора пользователям
Если вам необходимо дать права администратора пользователю, ни в коем случае не помещайте его учетную запись для повседневной работы в группу локальных администраторов компьютера. Учетная запись для повседневной работы должна быть всегда ограничена в правах. Создайте для него отдельную административную учетную запись вида namelocal и добавьте данную учетную запись в группу локальных администраторов при помощи политики, ограничив ее применение только на компьютере пользователя при помощи item-level targeting. Данной учетной записью пользователь сможет пользоваться, используя механизм Run AS.
Политики паролей
Создайте отдельные политики паролей для пользователей и администраторов при помощи fine-grained password policy. Желательно, чтобы пользовательский пароль состоял минимум из 8 символов и менялся хотя бы раз в квартал. Администраторам желательно менять пароль каждые два месяца, и он должен быть минимум из 10-15 символов и отвечать требованиям сложности.
Состав доменных и локальных групп. Механизм Restricted Groups
Состав доменных и локальных групп компьютерах домена должен контролироваться только в автоматическом режиме, при помощи механизма Restricted Groups. Почему это необходимо делать только таким образом, объясню на следующем примере. Обычно после того, как разрвенут домен Active Directory, администраторы добавляют себя в доменные группы вроде Domain admins, Enterprise admins, добавляют в нужные группы инженеров технической поддержки и остальных пользователей тоже распределяют по группам. В процессе администрирования данного домена процесс выдачи прав повторяется многократно и будет крайне сложно вспомнить, что ты вчера временно добавлял бухгалтера Нину Петровну в группу администраторов 1С и что сегодня необходимо ее из это группы убрать. Ситуация усугубится, если в компании работает несколько администраторов и каждый время от времени выдает права пользователям в подобно стиле. Уже через год будет почти невозможно разобраться в том, какие кому права назначены. Поэтому состав групп должен контролироваться только групповыми политиками, которые при каждом применении будут приводить все в порядок.
Состав встроенных групп
Стоит сказать, что встроенные группы вроде Account Operators, Backup operators, Crypt Operators, Guests, Print Operators, Server Operators должны быть пустыми, как в домене, так и на клиентских компьютерах. Эти группы в первую очередь необходимы для обеспечения обратной совместимости со старыми системами, и пользователи данных групп наделяются слишком большими правами в системе, и становятся возможны атаки на повышение привилегий.
Учетные записи локальных администраторов
При помощи механизма Restricted Groups необходимо блокировать учетные записи локальных администраторов на локальных компьютерах, блокировать гостевые учетные записи и очищать группу локальных администраторов на локальных компьютерах. Ни в коем случае не используйте групповые политики для установки паролей на учетные записи локальных администраторов. Этот механизм не безопасен, пароль можно извлечь прямо из политики. Но, если вы решили не блокировать учетные записи локальных администраторов, то для корректной установки паролей и их ротации используйте механизм LAPS. К сожалению, настройка LAPS не до конца автоматизирована, и поэтому нужно будет в ручном режиме добавлять атрибуты в схему Active Directory, выдавать на них права, назначать группы и так далее. Поэтому проще заблокировать аккаунты локальных администраторов.
Сервисные учетные записи.
Для запуска сервисов используйте сервисные учетные записи и механизм gMSA (доступен в системах Windows 2012 и выше)
Групповые Политики
Документируйте политики перед созданием/изменением.
При создании политики используйте принцип «Политика - группа». То есть перед созданием политики создайте сначала группу для данной политики, уберите из области применения политики группу Authenticated users и добавьте созданную группу. Политику привяжите не к OU, а к корню домена и регулируйте область ее применения при помощи добавления объектов в группу политики. Такой механизм я считаю более гибким и понятным, чем линковку политики к OU. (Именно про это я писал в секции про Архитектуру OU).
Всегда регулируйте область применения политики. Если вы создали политику только для пользователей, то отключайте структуру компьютер и наоборот, отключайте структуру пользователь, если создали политику только для компьютеров. Благодаря этим настройкам, политики будут более быстро применяться.
Настройте ежедневное резервное копирование политик при помощи Power Shell, чтобы в случае ошибок конфигурирования можно было всегда вернуть настройки к исходным.
Центральное хранилище шаблонов (Central Store)
Начиная с Windows 2008 стало возможным хранить ADMX-шаблоны групповых политик в центральном хранилище, в SYSVOL. До этого по умолчанию все шаблоны политик хранились локально, на клиентах. Чтобы разместить шаблоны ADMX в центральном хранилище, необходимо скопировать содержимое папки %SystemDrive%\Windows\PolicyDefinitions вместе с подпапками с клиентских систем (Windows 7/8/8.1) в директорию контроллера домена %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions со слиянием содержимого, но без замены. Далее следует сделать такое же копирование с серверных систем, начиная с самой старой. В последнюю очередь, при копировании папок и файлов с самой последней версии сервера, сделайте копирование со слиянием и ЗАМЕНОЙ.
Копирование ADMX-шаблонов
Дополнительно в центральном хранилище можно размещать ADMX-шаблоны для любых программных продуктов, например, таких как Microsoft Office, продукты Adobe, Google и других. Зайдите на сайт поставщика программного продукта, скачайте ADMX-шаблон групповой политики и распакуйте его в папку %SystemDrive%\Windows\SYSVOL\domain\Policies\PolicyDefinitions на любом из контроллеров домена. Теперь вы сможете управлять нужным вам программным продуктом через групповые политики.
Фильтры WMI
Фильтры WMI не очень быстро работают, поэтому предпочтительнее использовать механизм item-level targeting. Но если item-level targeting использовать невозможно, и вы решили использовать WMI, то рекомендую сразу создать для себя несколько самых распространённых фильтров: фильтр «Только клиентские операционные системы», «Только серверные операционные системы», фильтры «Windows 7», фильтры «Windows 8», «Windows 8.1», «Windows 10». Если у вас будут готовые наборы WMI фильтров, то потом будет проще применить нужный фильтр к нужной политике.
Аудит событий Active Directory
Обязательно включите аудит событий на контроллерах домена и других серверах. Рекомендую включить аудит следующих объектов:
- Audit Computer Account Management - Success, Failure
- Audit Other Account Management Events - Success, Failure
- Audit Security Group Management - Success, Failure
- Audit User Account Management - Success, Failure
- Audit Kerberos Authentication Service - Failure
- Audit Other Account Logon Events - Failure
- Audit Audit Policy Change - Success, Failure
Расширенные настройки аудита
Подробно останавливаться на настройках аудита не буду, так как в Сети есть достаточное количество статей, посвященных данной теме. Дополню только, что помимо включения аудита, следует настроить оповещения по e-mail о критических событиях безопасности. Стоит также учесть то, что в системах с обильным количеством событий стоит выделить отдельные серверы для сбора и анализа файлов журнала.
Скрипты администрирования и уборки
Все однотипные и часто повторяемые действия необходимо выполнять при помощи скриптов администрирования. Среди таких действий: создание аккаунтов пользователей, создание аккаунтов администраторов, создание групп, создание OU и так далее. Создание объектов при помощи скриптов позволит соблюдать вашу логику названия объектов Active Directory, встроив проверки синтаксиса прямо в скрипты.
Также стоит написать скрипты уборки, которые будут в автоматическом режиме контролировать составы групп, выявлять пользователей и компьютеры, которые давно не подключались к домену, выявлять нарушение другие ваших стандартов так далее.
Я не встречал в качестве явной официальной рекомендации использование скриптов администрирования для контроля соблюдения стандартов и выполнения фоновых операций. Но сам предпочитаю проверки и процедуры в автоматическом режиме при помощи скриптов, так как это очень сильно экономит время и избавляет от большого количества ошибок и, конечно, здесь сказывается мой немного юниксовый подход к администрированию, когда проще набрать пару команд, чем щелкать мышкой по окнам.
Ручное администрирование
Часть операций по администрированию вам и вашим коллегам будет необходимо делать в ручном режиме. Для этих целей рекомендую использовать консоль mmc с добавленными в нее оснастками.
Как будет сказано далее, контроллеры домена у вас должны функционировать в режиме Server Core, то есть администрирование всего окружения AD следует выполнять только со своего компьютера при помощи консолей. Для администрирования Active Directory необходимо на свой компьютер поставить Remote Server Administration Tools. Консоли следует запускать на вашем компьютере из-под пользователя с правами администратора Active Directory, которому делегировано управление.
Искусство управления Active Directory при помощи консолей требует отдельной статьи, а может быть даже и отдельного обучающего видео, поэтому здесь только говорю про сам принцип.
Контроллеры домена
В любом домене, контроллеров должно быть, как минимум два. На контроллерах домена должно быть, как можно меньше служб. Не стоит делать из контроллера домена файловый сервер или, упаси вас бог, поднять на нем роль сервера терминалов. Используйте на контроллерах домена операционные системы в режиме Server Core, удалив полностью поддержку WoW64, это значительно уменьшит количество необходимых обновлений и увеличит их безопасность.
Microsoft раньше не рекомендовала виртуализировать контроллеры домена в виду того, что при восстановлении из моментальных снимков были возможны трудноразрешимые конфликты репликации. Возможно, были еще причины, точно сказать не могу. Сейчас гипервизоры научились сообщать контроллерам о восстановлении их из моментальных снимков, и эта проблема исчезла. Я же все время виртуализировал контроллеры, не делая никаких моментальных снимков, так как не понимаю, зачем вообще может понадобиться делать таковые на контроллерах домена. По-моему, проще сделать резервную копию контроллера домена стандартными средствами. Поэтому, рекомендую виртуализировать все контроллеры домена, которые только возможно. Такая конфигурация будет более гибкой. При виртуализации контроллеров домена располагайте их на разных физических хостах.
Если вам необходимо разместить контроллер домена в незащищенной физической среде или в филиале вашей организации, то для этих целей используйте RODC.
Роли FSMO, первичные и вторичные контроллеры
Роли FSMO контроллеров домена продолжают порождать страх в головах начинающих администраторов. Часто новички изучают Active Directory по устаревшей документации или слушают рассказы других администраторов, которые что-то где-то когда-то читали.
По всем пяти + 1 ролям вкратце следует сказать следующее. Начиная с Windows Server 2008 больше не существует первичных и вторичных контроллеров домена. Все пять ролей контроллеров домена переносимы, но не могут размещаться одновременно более, чем на одном контроллере. Если мы возьмем один из контроллеров, который, к примеру, был хозяином 4 ролей и удалим его, то все эти роли мы без проблем сможем перенести на другие контроллеры, и в домене ничего страшного не произойдет, ничего не сломается. Такое возможно потому, что всю информацию по работе, связанной с той или иной ролью ее хозяин хранит прямо в Active Directory. И если мы передаем роль другому контроллеру, то он в первую очередь обращается за сохраненной информацией в Active Directory и приступает к несению службы. Домен может достаточно долгое время существовать без хозяев ролей. Единственная «роль», которая должна быть всегда в Active Directory и без которой будет все очень плохо, это роль глобального каталога (GC), ее могут нести на себе все контроллеры в домене. Рекомендую назначать роль GC каждому контроллеру в домене, чем их больше, тем лучше. Конечно, вы сможете найти случаи, когда на контроллер домена не стоить устанавливать роль GC. Что ж, если не надо, так не надо. Следуйте рекомендациям без фанатизма.
Служба DNS
Служба DNS критична для работы Active Directory и работать она должна без сбоев. Службу DNS лучше всего ставить на каждый контроллер домена и хранить DNS зоны в самой Active Directory. Если вы будете использовать Active Directory для хранения зон DNS, то вам следует настраивать свойства TCP/IP соединения на контроллерах домена, таким образом, чтобы на каждом контроллере в качестве первичного DNS-сервера был любой другой DNS-сервер, а в качестве вторичного можно поставить адрес 127.0.0.1. Такую настройку делать необходимо потому, что для нормального старта службы Active Directory требуется работающий DNS, а для старта DNS должна быть запущена служба Active Directory, так как в ней лежит сама зона DNS.
Обязательно настройте зоны обратного просмотра для всех своих сетей и включите автоматическое безопасное обновление записей PTR.
Рекомендую дополнительно включить автоматическую уборку зоны от устаревших записей DNS (dns scavenging).
В качестве DNS-Forwarders рекомендую указать защищенные серверы Яндекс, если нет других более быстрых в вашей географической локации.
Сайты и репликация
Многие администраторы привыкли считать, что сайты - это географическое объединение компьютеров. Например, сайт Москва, сайт Петербург. Такое представление появилось из-за того, что первоначально деление Active Directory на сайты было сделано с целью балансировки и разделения сетевого трафика репликации. Контроллерам домена в Москве не обязательно знать, что в Петербурге было сейчас создано десять учетных записей компьютеров. И поэтому подобную информацию об изменениях можно передавать раз в час по расписанию. Или вообще производить репликацию изменений один раз в сутки и только ночью, для экономии полосы пропускания.
Про сайты я бы сказал так: сайты - это логические группы компьютеров. Компьютеров, которые соединены между собой хорошим сетевым соединением. А сами сайты соединены между собой соединением с малой пропускной способность, что в наше время большая редкость. Поэтому, я делю Active Directory на сайты не для балансировки трафика репликации, а для балансировки сетевой нагрузки вообще и для более быстрой обработки клиентских запросов компьютеров сайта. Поясню на примере. Есть 100-мегабитная локальная сеть организации, которую обслуживают два контроллера домена и есть облако, где располагаются серверы приложений этой организации с двумя другими облачными контроллерами. Такую сеть я поделю на два сайта для того, чтобы контроллеры в локальной сети обрабатывали запросы клиентов из локальной сети, а контроллеры в облаке запросы от серверов приложений. Дополнительно это позволит разделить запросы к службам DFS и Exchange. И так как сейчас я редко где встречаю канал в Интернет менее 10 мегабит в секунду, то я включу Notify Based Replication, это когда репликация данных происходит сразу, как только появились какие-либо изменения в Active Directory.
Заключение
Сегодня утром я думал о том, почему человеческий эгоизм не приветствуется в обществе и где-то на глубинном уровне восприятия вызывает крайне отрицательные эмоции. И единственный ответ, который пришел мне в голову, это то, что человеческая раса не выжила бы на этой планете, если бы не научилась совместному использованию физических и интеллектуальных ресурсов. Именно поэтому я и делюсь данной статьей с вами и, надеюсь, что мои рекомендации помогут вам улучшить свои системы, и вы станете значительно меньше тратить времени на поиск и устранение неисправностей. Все это приведет к освобождению большего количества времени и энергии для творчества. Гораздо приятнее жить в мире творческих и свободных людей.
Хорошо, если в комментариях вы по возможности поделитесь своими знаниями и практиками построения Active Directory.
Всем мира и добра!
Вы можете помочь и перевести немного средств на развитие сайта
Active Directory
Active Directory («Активные директории», AD ) - LDAP -совместимая реализация службы каталогов корпорации Microsoft для операционных систем семейства Windows NT . Active Directory позволяет администраторам использовать групповые политики для обеспечения единообразия настройки пользовательской рабочей среды, развёртывать программное обеспечение на множестве компьютеров через групповые политики или посредством System Center Configuration Manager (ранее Microsoft Systems Management Server ), устанавливать обновления операционной системы, прикладного и серверного программного обеспечения на всех компьютерах в сети, используя Службу обновления Windows Server . Active Directory хранит данные и настройки среды в централизованной базе данных. Сети Active Directory могут быть различного размера: от нескольких десятков до нескольких миллионов объектов.
Представление Active Directory состоялось в 1999 году, продукт был впервые выпущен с Windows 2000 Server , а затем был модифицирован и улучшен при выпуске Windows Server 2003 . Впоследствии Active Directory был улучшен в Windows Server 2003 R2 , Windows Server 2008 и Windows Server 2008 R2 и переименован в Active Directory Domain Services . Ранее служба каталогов называлась NT Directory Service (NTDS ), это название до сих пор можно встретить в некоторых исполняемых файлах .
В отличие от версий Windows до Windows 2000 , которые использовали в основном протокол NetBIOS для сетевого взаимодействия, служба Active Directory интегрирована с DNS и TCP/IP . Для аутентификации по умолчанию используется протокол Kerberos . Если клиент или приложение не поддерживает аутентификацию Kerberos , используется протокол NTLM .
Устройство
Объекты
Active Directory имеет иерархическую структуру, состоящую из объектов. Объекты разделяются на три основные категории: ресурсы (например, принтеры), службы (например, электронная почта) и учётные записи пользователей и компьютеров. Active Directory предоставляет информацию об объектах, позволяет организовывать объекты, управлять доступом к ним, а также устанавливает правила безопасности.
Объекты могут быть вместилищами для других объектов (группы безопасности и распространения). Объект уникально определяется своим именем и имеет набор атрибутов - характеристик и данных, которые он может содержать; последние, в свою очередь, зависят от типа объекта. Атрибуты являются составляющей базой структуры объекта и определяются в схеме. Схема определяет, какие типы объектов могут существовать.
Сама схема состоит из двух типов объектов: объекты классов схемы и объекты атрибутов схемы. Один объект класса схемы определяет один тип объекта Active Directory (например, объект «Пользователь»), а один объект атрибута схемы определяет атрибут, который объект может иметь.
Каждый объект атрибута может быть использован в нескольких разных объектах классов схемы. Эти объекты называются объектами схемы (или метаданными) и позволяют изменять и дополнять схему, когда это необходимо. Однако каждый объект схемы является частью определений объектов Active Directory , поэтому отключение или изменение этих объектов могут иметь серьёзные последствия, так как в результате этих действий будет изменена структура Active Directory . Изменение объекта схемы автоматически распространяется в Active Directory . Будучи однажды созданным, объект схемы не может быть удалён, он может быть только отключён. Обычно все изменения схемы тщательно планируются.
Контейнер аналогичен объекту в том смысле, что он также имеет атрибуты и принадлежит пространству имён , но, в отличие от объекта, контейнер не обозначает ничего конкретного: он может содержать группу объектов или другие контейнеры.
Структура
Верхним уровнем структуры является лес - совокупность всех объектов, атрибутов и правил (синтаксиса атрибутов) в Active Directory . Лес содержит одно или несколько деревьев , связанных транзитивными отношениями доверия . Дерево содержит один или несколько доменов, также связанных в иерархию транзитивными отношениями доверия. Домены идентифицируются своими структурами имён DNS - пространствами имён.
Объекты в домене могут быть сгруппированы в контейнеры - подразделения. Подразделения позволяют создавать иерархию внутри домена, упрощают его администрирование и позволяют моделировать организационную и/или географическую структуры компании в Active Directory . Подразделения могут содержать другие подразделения. Корпорация Microsoft рекомендует использовать как можно меньше доменов в Active Directory , а для структурирования и политик использовать подразделения. Часто групповые политики применяются именно к подразделениям. Групповые политики сами являются объектами. Подразделение является самым низким уровнем, на котором могут делегироваться административные полномочия .
Другим способом деления Active Directory являются сайты , которые являются способом физической (а не логической) группировки на основе сегментов сети. Сайты подразделяются на имеющие подключения по низкоскоростным каналам (например по каналам глобальных сетей , с помощью виртуальных частных сетей) и по высокоскоростным каналам (например через локальную сеть). Сайт может содержать один или несколько доменов, а домен может содержать один или несколько сайтов. При проектировании Active Directory важно учитывать сетевой трафик , создающийся при синхронизации данных между сайтами.
Ключевым решением при проектировании Active Directory является решение о разделении информационной инфраструктуры на иерархические домены и подразделения верхнего уровня. Типичными моделями, используемыми для такого разделения, являются модели разделения по функциональным подразделениям компании, по географическому положению и по ролям в информационной инфраструктуре компании. Часто используются комбинации этих моделей.
Физическая структура и репликация
Физически информация хранится на одном или нескольких равнозначных контроллерах доменов , заменивших использовавшиеся в Windows NT основной и резервные контроллеры домена, хотя для выполнения некоторых операций сохраняется и так называемый сервер «операций с одним главным сервером », который может эмулировать главный контроллер домена. Каждый контроллер домена хранит копию данных, предназначенную для чтения и записи. Изменения, сделанные на одном контроллере, синхронизируются на все контроллеры домена при репликации . Серверы, на которых сама служба Active Directory не установлена, но которые при этом входят в домен Active Directory , называются рядовыми серверами.
Репликация Active Directory выполняется по запросу. Служба Knowledge Consistency Checker создаёт топологию репликации, которая использует сайты, определённые в системе, для управления трафиком. Внутрисайтовая репликация выполняется часто и автоматически с помощью средства проверки согласованности (уведомлением партнёров по репликации об изменениях). Репликация между сайтами может быть настроена для каждого канала сайта (в зависимости от качества канала) - различная «оценка» (или «стоимость») может быть назначена каждому каналу (например DS3 , , ISDN и т. д.), и трафик репликации будет ограничен, передаваться по расписанию и маршрутизироваться в соответствии с назначенной оценкой канала. Данные репликации могут транзитивно передаваться через несколько сайтов через мосты связи сайтов, если «оценка» низка, хотя AD автоматически назначает более низкую оценку для связей «сайт-сайт», чем для транзитивных соединений. Репликация сайт-сайт выполняется серверами-плацдармами в каждом сайте, которые затем реплицируют изменения на каждый контроллер домена своего сайта. Внутридоменная репликация проходит по протоколу RPC по протоколу IP , междоменная - может использовать также протокол SMTP .
Если структура Active Directory содержит несколько доменов, для решения задачи поиска объектов используется глобальный каталог : контроллер домена, содержащий все объекты леса, но с ограниченным набором атрибутов (неполная реплика). Каталог хранится на указанных серверах глобального каталога и обслуживает междоменные запросы.
Возможность операций с одним главным компьютером позволяет обрабатывать запросы, когда репликация с несколькими главными компьютерами недопустима. Есть пять типов таких операций: эмуляция главного контроллера домена (PDC-эмулятор), главный компьютер относительного идентификатора (мастер относительных идентификаторов или RID-мастер), главный компьютер инфраструктуры (мастер инфраструктуры), главный компьютер схемы (мастер схемы) и главный компьютер именования домена (мастер именования доменов). Первые три роли уникальны в рамках домена, последние две - уникальны в рамках всего леса.
Базу Active Directory можно разделить на три логические хранилища или «раздела». Схема является шаблоном для Active Directory и определяет все типы объектов, их классы и атрибуты, синтаксис атрибутов (все деревья находятся в одном лесу, потому что у них одна схема). Конфигурация является структурой леса и деревьев Active Directory . Домен хранит всю информацию об объектах, созданных в этом домене. Первые два хранилища реплицируются на все контроллеры доменов в лесу, третий раздел полностью реплицируется между репликами контроллеров в рамках каждого домена и частично - на сервера глобального каталога.
Именование
Active Directory поддерживает следующие форматы именования объектов: универсальные имена типа UNC , URL и LDAP URL . Версия LDAP формата именования X.500 используется внутри Active Directory .
Каждый объект имеет различающееся имя (англ. distinguished name , DN ) . Например, объект принтера с именем HPLaser3 в подразделении «Маркетинг» и в домене foo.org будет иметь следующее различающееся имя: CN=HPLaser3,OU=Маркетинг,DC=foo,DC=org , где CN - это общее имя, OU - раздел, DC - класс объекта домена. Различающиеся имена могут иметь намного больше частей, чем четыре части в этом примере. У объектов также есть канонические имена. Это различающиеся имена, записанные в обратном порядке, без идентификаторов и с использованием косых черт в качестве разделителей: foo.org/Маркетинг/HPLaser3 . Чтобы определить объект внутри его контейнера, используется относительное различающееся имя : CN=HPLaser3 . У каждого объекта также есть глобально уникальный идентификатор (GUID ) - уникальная и неизменная 128-битная строка, которая используется в Active Directory для поиска и репликации. Определённые объекты также имеют имя участника-пользователя (UPN , в соответствии с RFC 822 ) в формате объект@домен.
Интеграция с UNIX
Различные уровни взаимодействия с Active Directory могут быть реализованы в большинстве UNIX -подобных операционных систем посредством соответствующих стандарту LDAP клиентов, но такие системы, как правило, не воспринимают большую часть атрибутов, ассоциированных с компонентами Windows , например групповые политики и поддержку односторонних доверенностей.
Сторонние поставщики предлагают интеграцию Active Directory на платформах UNIX , включая UNIX , Linux , Mac OS X и ряд приложений на базе Java , с пакетом продуктов:
Добавления в схему, поставляемые с Windows Server 2003 R2 включают атрибуты, которые достаточно тесно связаны с RFC 2307 , чтобы использоваться в общем случае. Базовые реализации RFC 2307, nss_ldap и pam_ldap , предложенные PADL.com , непосредственно поддерживают эти атрибуты. Стандартная схема для членства в группе соответствует RFC 2307bis (предлагаемому) . Windows Server 2003 R2 включает Консоль управления Microsoft для создания и редактирования атрибутов.
Альтернативным вариантом является использование другой службы каталогов, например 389 Directory Server (ранее Fedora Directory Server , FDS ), eB2Bcom ViewDS v7.1 XML Enabled Directory или Sun Java System Directory Server от Sun Microsystems , выполняющую двухстороннюю синхронизацию с Active Directory , реализуя таким образом «отраженную» интеграцию, когда клиенты UNIX и Linux аутентифицируются FDS , а клиенты Windows аутентифицируются Active Directory . Другим вариантом является использование OpenLDAP с возможностью полупрозрачного перекрытия, расширяющей элементы удаленного сервера LDAP дополнительными атрибутами, хранимыми в локальной базе данных.
Active Directory автоматизируются с помощью Powershell .
Литература
- Рэнд Моримото, Кентон Гардиньер, Майкл Ноэл, Джо Кока Microsoft Exchange Server 2003 . Полное руководство = Microsoft Exchange Server 2003 Unleashed . - М .: «Вильямс», 2006. - С. 1024. - ISBN 0-672-32581-0
См. также
Ссылки
Примечания
| Компоненты Microsoft Windows | |
|---|---|
| Основные | |
| Службы управления |
|
| Приложения |
Контакты DVD Maker Факсы и сканирование Internet Explorer Журнал Экранная лупа Media Center Проигрыватель Windows Media Программа совместной работы Центр устройств Windows Mobile Центр мобильности Экранный диктор Paint Редактор личных символов Удалённый помощник Распознавание речи WordPad Блокнот Боковая панель Звукозапись Календарь Калькулятор Ножницы Почта Таблица символов Исторические : Movie Maker NetMeeting Outlook Express Диспетчер программ Диспетчер файлов Фотоальбом |
| Игры | |
| Ядро ОС | |
| Службы | |
| Файловые системы |
|
| Сервер |
Active Directory Службы развёртывания Служба репликации файлов DNS Домены Перенаправление папок Hyper-V IIS Media Services MSMQ Защита доступа к сети (NAP) Службы печати для UNIX Удалённое разностное сжатие Службы удаленной установки Служба управления правами Перемещаемые профили пользователей SharePoint Диспетчер системных ресурсов Удаленный рабочий стол WSUS Групповая политика Координатор распределённых транзакций |
| Архитектура | |
| Безопасность | |
| Совместимость | |
| Microsoft | ||
|---|---|---|
| ПО | ||
| Серверное ПО | ||
| Технологии | ||
| Интернет | ||
| Игры | ||
| Аппаратное обеспечение |
||
| Образование | ||
| Лицензирование | ||
| Подразделения | ||
Основополагающим компонентом доменных служб в каждой организации являются принципалы безопасности (оригинальное название - Security Principal), которые предоставляют пользователей, группы или компьютеры, которым требуется доступ к определенным ресурсам в сети. Именно таким объектам, как принципалам безопасности можно предоставлять разрешения доступа к ресурсам в сети, причем каждому принципалу во время создания объекта присваивается уникальный идентификатор безопасности (SID), который состоит из двух частей. Идентификатором безопасности SID называется числовое представление, которое уникально идентифицирует принципал безопасности. Первая часть такого идентификатора представляет собой идентификатор домена . Ввиду того, что принципалы безопасности расположены в одном домене, всем таким объектам присваивается один и тот же идентификатор домена. Второй частью SID является относительный идентификатор (RID) , который используется для уникальной идентификации принципала безопасности по отношению к ведомству, которое выдает SID.
Несмотря на то, что планирование и развертывание инфраструктуры доменных служб в большинстве организаций выполняется лишь один раз и в большинство объектов изменения вносятся очень редко, к важному исключению из этого правила можно отнести принципалы безопасности, которые необходимо периодически добавлять, изменять, а также удалять. Одним из основополагающих компонента идентификации являются учетные записи пользователей. По сути, учетные записи пользователей представляют собой физические объекты, в основном людей, которые являются сотрудниками вашей организации, но бывают исключения, когда учетные записи пользователей создаются для некоторых приложений в качестве служб. Учетные записи пользователей играют важнейшую роль в администрировании предприятии. К таким ролям можно отнести:
- Удостоверение личности пользователей , так как созданная учетная запись позволяет входить на компьютеры и в домены именно с теми данными, подлинность которых проверяет домен;
- Разрешения доступа к ресурсам домена , которые назначаются пользователю для предоставления доступа к доменным ресурсам на основании явных разрешений.
Объекты учетных записей пользователей можно отнести к самым распространенным объектам в Active Directory. Именно пользовательским учетным записям администраторы обязаны уделять особое внимание, так как пользователям свойственно приходить работать в организацию, перемещаться между отделами и офисами, жениться, выходить замуж, разводиться и даже увольняться из компании. Такие объекты представляют собой набор атрибутов, причем только одна пользовательская учетная запись может содержать свыше 250 различных атрибутов, что в несколько раз превышает количество атрибутов на рабочих станциях и компьютеров, работающих под операционной системой Linux. Во время создания учетной записи пользователя создается ограниченный набор атрибутов, а уже потом вы можете добавлять такие пользовательские учетные данные как организационные сведения, адреса проживания пользователей, телефонные номера и многое другое. Поэтому важно обратить внимание на то, что одни атрибуты являются обязательными , а остальные – опциональными . В этой статье я расскажу о ключевых методах создания пользовательских учетных записей, о некоторых опциональных атрибутах, а также будут описаны средства, позволяющие автоматизировать рутинные действия, связанные с созданием учетных записей пользователей.
Создание пользователей при помощи оснастки «Active Directory – пользователи и компьютеры»
В подавляющем большинстве случаев системные администраторы для создания основных принципалов безопасности предпочитают использовать оснастку , которая добавляется в папку «Администрирование» сразу после установки роли «Доменные службы Active Directory» и повышения сервера до контролера домена. Этот метод является наиболее удобным, так как для создания принципалов безопасности используется графический пользовательский интерфейс и мастер создания учетных записей пользователя очень прост в применении. К недостатку данного метода можно отнести тот момент, что при создании учетной записи пользователя вы не можете сразу задать большинство атрибутов, и вам придется добавлять необходимые атрибуты путем редактирования учетной записи. Для того чтобы создать пользовательскую учетную запись, выполните следующие действия:
- В поле «Имя» введите имя пользователя;
- В поле «Инициалы» введите его инициалы (чаще всего инициалы не используются);
- В поле «Фамилия» введите фамилию создаваемого пользователя;
- Поле «Полное имя» используется для создания таких атрибутов создаваемого объекта, как основное имя (Common Name) CN и отображения свойств имени. Это поле должно быть уникальным во всем домене, и заполняется автоматически, а изменять его стоит лишь в случае необходимости;
- Поле «Имя входа пользователя» является обязательным и предназначено для имени входа пользователя в домен. Здесь вам нужно ввести имя пользователя и из раскрывающегося списка выбрать суффикс UPN, который будет расположен после символа @;
- Поле «Имя входа пользователя (Пред-Windows 2000)» предназначено для имени входа для систем предшествующих операционной системе Windows 2000. В последние годы в организациях все реже встречаются обладатели таких систем, но поле обязательно, так как некоторое программное обеспечение для идентификации пользователей использует именно этот атрибут;
После того как заполните все требуемые поля, нажмите на кнопку «Далее» :
Рис. 2. Диалоговое окно создания пользовательской учетной записи
Рис. 3. Создание пароля для создаваемой учетной записи
Создание пользователей на основании шаблонов
Обычно в организациях существует множество подразделений или отделов, в которые входят ваши пользователи. В этих подразделениях пользователи обладают схожими свойствами (например, название отдела, должности, номер кабинета и пр.). Для наиболее эффективного управления учетными записями пользователей из одного подразделения, например, используя групповые политики, целесообразно их создавать внутри домена в специальных подразделениях (иначе говоря, контейнерах) на основании шаблонов. Шаблоном учетной записи называется учетная запись, впервые появившаяся еще во времена операционных систем Windows NT, в которой заранее заполнены общие для всех создаваемых пользователей атрибуты. Для того чтобы создать шаблон учетной записи пользователя, выполните следующие действия:
- Общие . Данная вкладка предназначена для заполнения индивидуальных пользовательских атрибутов. К этим атрибутам относятся имя пользователя и его фамилия, краткое описания для учетной записи, контактный телефон пользователя, номер комнаты, его электронный ящик, а также веб-сайт. Ввиду того, что данная информация является индивидуальной для каждого отдельного пользователя, данные заполненные на этой вкладке не копируются;
- Адрес . На текущей вкладке вы можете заполнить почтовый ящик, город, область, почтовый индекс и страну, где проживают пользователи, которые будут созданы на основании данного шаблона. Так как у каждого пользователя названия улиц обычно не совпадают, данные из этого поля не подлежат копированию;
- Учетная запись . В этой вкладке вы можете указать точно время входа пользователя, компьютеры, на которые смогут заходить пользователи, такие параметры учетных записей как хранение паролей, типы шифрования и пр., а также срок действия учетной записи;
- Профиль . Текущая вкладка позволяет вам указать путь к профилю, сценарий входа, локальный путь к домашней папке, а также сетевые диски, на которых будет размещена домашняя папка учетной записи;
- Организация . На этой вкладке вы можете указать должность сотрудников, отдел, в котором они работают, название организации, а также имя руководителя отдела;
- Члены групп . Здесь указывается основная группа и членство в группах.
Это основные вкладки, которые заполняются при создании шаблонов учетной записи. Помимо этих шести вкладок, вы можете еще заполнять информацию в 13 вкладках. Большинство из этих вкладок будут рассмотрены в последующих статьях данного цикла.
Рис. 5. Диалоговое окно копирования пользовательской учетной записи
Создание пользователей средствами командной строки
Как и в большинстве случаев, в операционной системе Windows есть утилиты командной строки с аналогичными функциями графического пользовательского интерфейса оснастки «Active Directory – пользователи и компьютеры» . Такие команды называются командами DS, так как они начинаются с букв DS. Для создания принципалов безопасности используется команда Dsadd . После самой команды указываются модификаторы, которые определяют тип и имя DN объекта. В случае с созданием учетных записей пользователей вам нужно указать модификатор user , который является типом объекта. После типа объекта необходимо ввести DN имя самого объекта. DN (Distinguished Name) объекта является результирующим набором, который содержит отличительное имя. Следом за DN обычно указывают имя пользователя UPN или имя входа предыдущих версий Windows. Если в имени DN присутствуют пробелы, то такое имя нужно заключить в кавычки. Синтаксис команды следующий:
Dsadd user DN_имя –samid имя_учетной_записи –UPN_имя –pwd пароль –дополнительные параметры
С данной командой можно использовать 41 параметр. Рассмотрим самые распространенные из них:
-samid – имя учетной записи пользователя;
-upn – имя входа пользователя пред-Windows 2000;
-fn – имя пользователя, которое в графическом интерфейсе заполняется в поле «Имя» ;
-mi – инициал пользователя;
-ln – фамилия пользователя, указываемая в поле «Фамилия» мастера создания пользовательской учетной записи;
-display – указывает полное имя пользователя, которое автоматически генерируется в пользовательском интерфейсе;
-empid – код сотрудника, который создается для пользователя;
-pwd – параметр, определяющий пользовательский пароль. В том случае, если вы укажете символ звездочки (*), вам будет предложено ввести пароль пользователя в защищенном от просмотра режиме;
-desc – краткое описание для пользовательской учетной записи;
-memberof – параметр, определяющий членство пользователя в одной или нескольких группах;
-office – местонахождения офиса, где работает пользователь. В свойствах учетной записи этот параметр можно найти во вкладке «Организация» ;
-tel – номер контактного телефона текущего пользователя;
-email – адрес электронной почты пользователя, который можно найти во вкладке «Общие» ;
-hometel – параметр, указывающий номер домашнего телефона пользователя;
-mobile – телефонный номер мобильного пользователя;
-fax – номер факсимильного аппарата, который использует текущий пользователь;
-title – должность пользователя в данной организации;
-dept – этот параметр позволяет указать наименование отдела, в котором работает данный пользователь;
-company – название компании, в которой работает создаваемый пользователь;
-hmdir – основной каталог пользователя, в котором будут расположены его документы;
-hmdrv – путь к сетевому диску, на котором будет размещена домашняя папка учетной записи
-profile – путь профиля пользователя;
-mustchpwd – данный параметр указывает на то, что при последующем входе в систему пользователь обязан изменить свой пароль;
-canchpwd – параметр, определяющий, должен ли пользователь изменять свой пароль. Если значением параметра указано «yes» , то у пользователя будет возможность изменения пароля;
-reversiblepwd – текущий параметр определяет хранение пароля пользователя с применением обратного шифрования;
-pwdneverexpires – параметр, указывающий на то, что срок действия пароля никогда не истечет. Во всех этих четырех параметрах, значениями могут выступать только «yes» или «no» ;
-acctexpires – параметр, определяющий, через сколько дней срок действия учетной записи истечет. Положительное значение представляет собой количество дней, через которое учетная запись истечет, а отрицательное означает, что срок действия уже закончен;
-disabled – указывает, что учетная запись уже отключена. Значениями для этого параметра также выступают «yes» или «no» ;
-q – указание тихого режима для обработки команды.
Пример использования:
Dsadd user “cn=Алексей Смирнов,OU=Маркетинг,OU=Пользователи,DC=testdomain,DC=com” -samid Alexey.Smirnov -upn Alexey.Smirnov -pwd * -fn Алексей -ln Смирнов -display “Алексей Смирнов” -tel “743-49-62” -email [email protected] -dept Маркетинг -company TestDomain -title Маркетолог -hmdir \\dc\profiles\Alexey.Smirnov -hmdrv X -mustchpwd yes -disabled no
Рис. 6. Создание пользовательской учетной записи средствами утилиты Dsadd
Создание пользователей при помощи команды CSVDE
Еще одна утилита командной строки CSVDE позволяет импортировать или экспортировать объекты Active Direcoty, представленные в виде cvd-файла – текстового файла с разделительными запятыми, которые можно создавать при помощи табличного процессора Microsoft Excel или простейшего текстового редактора Блокнот. В этом файле каждый объект представляется одной строкой и должен содержать атрибуты, которые перечислены в первой строке. Стоит обратить внимание на то, что при помощи данной команды вы не можете импортировать пользовательские пароли, то есть, сразу после завершения операции импорта пользовательские учетные записи будут отключены. Пример такого файла следующий:
Рис. 7. Представление CSV-файла
Синтаксис команды следующий:
Csvde –i –f filename.csv –k
- -i . Параметр, который отвечает за режим импорта. Если вы не укажите данный параметр, то эта команда будет использовать по умолчанию режим экспорта;
- -f
- -k
- -v
- -j
- -u . Параметр, позволяющий использовать режим Юникода.
Пример использования команды:
Csvde -i -f d:\testdomainusers.csv -k
Рис. 8. Импорт учетных записей пользователей из CSV-файла
Импорт пользователей средствами LDIFDE
Утилита командной строки Ldifde позволяет также импортировать или экспортировать объекты Active Directory, используя файловый формат LDIF (Lightweight Directory Access Protocol Data Interchange File). Данный файловый формат состоит из блока строк, которые образуют конкретную операцию. В отличие от файлов CSV, в данном файловом формате каждая отдельная строка представляет собой набор атрибутов, после которого следует двоеточие и само значение текущего атрибута. Также как и в CSV файле, первой строкой обязан быть атрибут DN. За ним следует строка changeType, которая указывает тип операции (add, change или delete). Для того чтобы научиться разбираться в этом файловом формате, вам нужно выучить по крайней мере ключевые атрибуты принципалов безопасности. Пример предоставлен ниже:
Рис. 9. Пример LDF файла
Синтаксис команды следующий:
Ldifde -i -f filename.csv -k
- -i . Параметр, который отвечает за режим импорта. Если вы не укажете данный параметр, то эта команда будет использовать по умолчанию режим экспорта;
- -f . Параметр, идентифицирующий имя файла, которое предназначено для импорта или экспорта;
- -k . Параметр, предназначенный для продолжения импорта пропуская все возможные ошибки;
- -v . Параметр, используя который вы можете вывести подробную информацию;
- -j . Параметр, отвечающий за расположение файла журнала;
- -d . Параметр, указывающий корень поиска LDAP;
- -f . Параметр, предназначенный для фильтра поиска LDAP;
- -p . Представляет собой область или глубину поиска;
- -l . Предназначен для указания списка атрибутов с разделительными запятыми, который будет включен в экспорт результирующих объектов;
Создание пользователей c помощью VBScript
VBScript является одним из самых мощных инструментов, предназначенных для автоматизации административных задач. Данный инструмент позволяет создавать сценарии, предназначенные для автоматизирования большинства действий, которые могут выполняться посредством пользовательского интерфейса. Сценарии VBScript представляют собой текстовые файлы, которые обычно пользователи могут редактировать при помощи обыкновенных текстовых редакторов (например, Блокнот). А для выполнения сценариев нужно просто дважды щелкнуть мышью по значку самого сценария, который откроется с применением команды Wscript. Для того чтобы создать пользовательскую учетную запись в VBScript не существует определенной команды, поэтому вам сначала нужно подключиться к контейнеру, затем использовать библиотеку адаптеров Active Directory Services Interface (ADSI) при помощи инструкции Get-Object, где выполняется строка запроса LDAP, предоставляющая собой моникер протокола LDAP:// с DN именем объекта. Например, Set objOU=GetObject(“LDAP://OU=Маркетинг,OU=Пользователи,dc=testdomain,dc=com”). Вторая строка кода активирует метод Create подразделения для создания объекта конкретного класса с конкретным отличительным именем, например, Set objUser=objOU.Create(“user”,”CN= Юрий Соловьев”). В качестве третьей строки указывается метод Put, где нужно указать наименование атрибута и его значение. Последняя строка данного сценария подтверждает сделанные изменения, то есть objUser.SetInfo().
Пример использования:
Set objOU=GetObject(“LDAP://OU=Маркетинг,OU=Пользователи,dc=testdomain,dc=com” Set objUser=objOU.Create(“user”,”CN= Юрий Соловьев”) objUser.Put “sAMAccountName”,”Yuriy.Soloviev” objUser.Put “UserPrincipalName” [email protected]” objUser.Put “givenName”,”Юрий” objUser.Put “sn”Соловьев” objUser.SetInfo()
Создание пользователей при помощи PowerShell
В операционной системе Windows Server 2008 R2 появилась возможность управлять объектами Active Directory средствами Windows PowerShell. Среда PowerShell считается мощнейшей оболочкой командной строки, разработанной на основе.Net Framework и предназначенной для управления и автоматизации администрирования операционных систем Windows и приложений, которые работают под данными операционными системами. PowerShell включает в себя свыше 150 инструментов командной строки, называемых командлетами, которые предоставляют возможность управления компьютерами предприятия из командной строки. Данная оболочка является компонентом операционной системы.
Для создания нового пользователя в домене Active Directory используется командлет New-ADUser, большинство значений свойств которого можно добавлять при помощи параметров данного командлета. Для отображения имени LDAP используется параметр –Path. Данный параметр задает контейнер или подразделение (OU) для нового пользователя. Если параметр Path не задан, командлет создает объект пользователя в контейнере по умолчанию для объектов пользователя в данном домене, то есть в контейнере Users. Для того чтобы указать пароль, используется параметр –AccountPassword со значением (Read-Host -AsSecureString "Пароль для вашей учетной записи"). Также стоит обязательно обратить внимание на то, что значением параметра –Country выступает именно код страны или региона выбранного пользователем языка. Синтаксис командлета следующий:
New-ADUser [-Name]
Как видно из данного синтаксиса, нет смысла описывать все параметры, так как они идентичны атрибутам принципала безопасности и не нуждаются в объяснениях. Посмотрим на пример использования:
New-ADUser -SamAccountName "Evgeniy.Romanov" -Name "Евгений Романов" -GivenName "Евгений" -Surname "Романов" -DisplayName "Евгений Романов" -Path "OU=Маркетинг,OU=Пользователи,DC=testdomain,DC=com" -CannotChangePassword $false -ChangePasswordAtLogon $true -City "Херсон" -State "Херсон" -Country UA -Department "Маркетинг" -Title "Маркетолог" -UserPrincipalName "[email protected]" -EmailAddress "[email protected]" -Enabled $true -AccountPassword (Read-Host -AsSecureString "AccountPassword")
Рис. 10. Создание учетной записи пользователя средствами Windows PowerShell
Заключение
В этой статье вы узнали о понятии принципал безопасности и о том, какую роль представляют учетные записи пользователей в доменной среде. Были подробно рассмотрены основные сценарии создания пользовательских учетных записей в домене Active Directory. Вы научились создавать пользовательские учетные записи при помощи оснастки «Active Directory – пользователи и компьютеры» , используя шаблоны, утилиты командной строки Dsadd, CSVDE и LDIFDE. Также вы узнали о методе создания пользовательских учетных записей при помощи языка сценариев VBScript и оболочки командной строки Windows PowerShell.
Александр Емельянов
Принципы построения доменов Active Directory
Active Directory уже давно вошла в разряд консервативных принципов логического построения сетевой инфраструктуры. Но многие администраторы продолжают использовать рабочие группы и домены Windows NT в своей работе. Внедрение службы каталогов будет интересно и полезно как начинающим, так и опытным администраторам для централизации управления сетью и обеспечения должного уровня безопасности.
Active Directory – технологию, появившуюся в линейке систем Win2K шесть лет назад, можно было охарактеризовать как революционную. По своей гибкости и масштабируемости она превосходит домены NT 4 на порядок, не говоря уже о сетях, состоящих из рабочих групп.
С момента выхода AD было выпущено огромное количество книг и публикаций на тему планирования, проектирования топологии, поддержки доменов, обеспечения безопасности и т. п.
Сертификационные курсы корпорации Microsoft обещают, что за 40 часов вы сможете научиться тому, как развернуть свой домен и с успехом его администрировать.
Не верю. Администрирование – это процесс, включающий в себя многолетний опыт с «набитыми шишками», огромным количеством прочитанной документации (в массе своей на английском языке) и «задушевными» беседами с начальством и пользователями.
Есть еще один нюанс – перед тем, как пройти курс по внедрению Active Directory, вы должны иметь успешно сданный курс по администрированию сетевой инфраструктуры на базе Windows Server 2003, который тоже требует некоторых финансовых затрат со стороны обучающегося. Лишний раз убеждаемся, что Microsoft своего не упустит. Но речь не об этом…
Изучение внедрения AD никак не вписывается в рамки недельного курса и уж тем более одной публикации. Однако, вооружившись опытом предыдущих статей, попытаемся разобраться, что же такое служба каталогов по сути своей, каковы основные тонкости ее инсталляции и чем она может облегчить жизнь системного администратора.
Также посмотрим, что нового появилось в Active Directory с выходом Windows Server 2003.
Стоит отметить, что в последнем квартале прошедшего года Microsoft выпустила Windows Vista, а вместе с ней и обновленную службу каталогов. Однако старые технологии не потеряли своей актуальности и по сей день.
В рамках статьи мы пройдем путь от понимания сущности AD до создания своего собственного домена. Дальнейшая его настройка и инструменты управления и диагностики будут освещены в следующих номерах.
Чем поможет Active Directory
Приведу неполный список всех «вкусностей», которые вы получите, развернув службу каталогов:
- единая база регистрации пользователей, которая хранится централизованно на одном либо нескольких серверах; таким образом, при появлении нового сотрудника в офисе вам нужно будет всего лишь завести ему учетную запись на сервере и указать, на какие рабочие станции он сможет получать доступ;
- поскольку все ресурсы домена индексируются, это дает возможность простого и быстрого поиска для пользователей; например, если нужно найти цветной принтер в отделе автоматизации;
- совокупность применения разрешений NTFS, групповых политик и делегирования управления позволит вам тонко настроить и распределить права между участниками домена;
- перемещаемые профили пользователей дают возможность хранить важную информацию и настройки конфигурации на сервере; фактически, если пользователь, обладающий перемещаемым профилем в домене, сядет работать за другой компьютер и введет свои имя пользователя и пароль, он увидит свой рабочий стол с привычными ему настройками;
- с помощью групповых политик вы можете изменять настройки операционных систем пользователей, от разрешения пользователю устанавливать обои на рабочем столе до настроек безопасности, а также распространять по сети программное обеспечение, например, Volume Shadow Copy client и т. п.;
- многие программы (прокси-серверы, серверы баз данныхи др.) не только производства Microsoft на сегодняшний день научились использовать доменную аутентификацию, таким образом, вам не придется создавать еще одну базу данных пользователей, а можно будет использовать уже существующую;
- использование Remote Installation Services облегчает установку систем на рабочие места, но, в свою очередь, работает только при внедренной службе каталогов.
Отрицательные стороны этой технологии появляются в процессе работы либо от незнания основ, либо от нежелания вдаваться в тонкости компонентов AD. Научитесь правильно решать возникающие задачи, и весь негатив исчезнет.
Я лишь заострю внимание на том факте, что все вышеперечисленное будет иметь силу при наличии гомогенной сети на базе семейства ОС Windows 2000 и выше.
Логика построения
Рассмотрим основные составляющие службы каталогов.
Домены
Это основная логическая единица построения. В сравнении с рабочими группами домены AD – это группы безопасности, имеющие единую базу регистрации, тогда как рабочие группы – это всего лишь логическое объединение машин. AD использует для именования и службы поиска DNS (Domain Name Server – сервер имен домена), а не WINS (Windows Internet Name Service – сервис имен Internet), как это было в ранних версиях NT. Таким образом, имена компьютеров в домене имеют вид, например, buh.work.com, где buh – имя компьютера в домене work.com (хотя это не всегда так, об этом читайте далее).
В рабочих группах используются NetBIOS-имена. Для размещения доменной структуры AD возможно использование DNS-сервера не компании Microsoft. Но он должен быть совместим с BIND 8.1.2 или выше и поддерживать записи SRV (RFC 2052), а также протокол динамической регистрации (RFC 2136). Каждый домен имеет хотя бы один контроллер домена, на котором располагается центральная база данных.
Деревья
Это многодоменные структуры. Корнем такой структуры является главный домен, для которого вы создаете дочерние. Фактически Active Directory использует иерархическую систему построения, аналогичную структуре доменов в DNS.
Например, если мы имеем домен work.com (домен первого уровня) и создаем для него два дочерних домена first.work.com и second.work.com (здесь first и second – это домены второго уровня, а не компьютер в домене, как в случае, описанном выше), то в итоге получим дерево доменов (см. рис. 1).
Деревья как логическое построение используются, когда вам нужно разделить филиалы компании, например, по географическим признакам, либо из каких-то других организационных соображений.
AD помогает автоматически создавать доверительные отношения между каждым доменом и его дочерними доменами.
Таким образом, создание домена first.work.com ведет к автоматической организации двухсторонних доверительных отношений между родительским work.com и дочерним first.work.com (аналогично и для second.work.com). Поэтому с родительского домена могут применяться разрешения для дочернего, и наоборот. Нетрудно предположить, что и для дочерних доменов будут существовать доверительные отношения.
Еще одно свойство доверительных отношений – транзитивность. Получаем – для домена net.first.work.com создаются доверительные отношения с доменом work.com.
Леса
Также как и деревья это многодоменные структуры. Но лес – это объединение деревьев, имеющих разные корневые домены.
Предположим, вы решили иметь несколько доменов с именами work.com и home.net и создать для них дочерние домены, но из-за того, что tld (top level domain) не в вашем управлении, в этом случае вы можете организовать лес (см. рис. 2), выбрав один из доменов первого уровня корневым. Вся прелесть создания леса в этом случае – двухсторонние доверительные отношения между двумя этими доменами и их дочерними доменами.
Однако при работе с лесами и деревьями необходимо помнить следующее:
- нельзя добавить в дерево уже существующий домен;
- нельзя включить в лес уже существующее дерево;
- если домены помещены в лес, их невозможно переместить в другой лес;
- нельзя удалить домен, имеющий дочерние домены.
Для получения более глубокой информации по тонкостям использования и конфигурирования деревьев и лесов вы можете посетить базу знаний Microsoft TechNet, а мы пойдем дальше.
Организационные единицы (OU)
Их можно назвать субдоменами. OU позволяют группировать в домене учетные записи пользователей, группы пользователей, компьютеры, разделяемые ресурсы, принтеры и другие OU. Практическая польза от их применения состоит в возможности делегирования прав для администрирования этих единиц.
Попросту говоря, можно назначить администратора в домене, который сможет управлять OU, но не иметь прав для администрирования всего домена.
Важной особенностью OU в отличие от групп (немного забегаем вперед) является возможность применения к ним групповых политик. «А почему нельзя разбить исходный домен на несколько доменов вместо использования OU?» – спросите вы.
Многие специалисты советуют иметь по возможности один домен. Причина этому – децентрализация администрирования при создании дополнительного домена, так как администраторы каждого такого домена получают неограниченный контроль (напомню, что при делегировании прав администраторам OU можно ограничивать их функционал).
В дополнение к этому для создания нового домена (даже дочернего) нужен будет еще один контроллер. Если же у вас есть два обособленных подразделения, соединенных медленным каналом связи, могут возникнуть проблемы с репликацией. В этом случае более уместным будет иметь два домена.
Также существует еще один нюанс применения групповых политик: политики, в которых определены настройки паролей и блокировки учетных записей могут применяться только для доменов. Для OU эти настройки политик игнорируются.
Группы пользователей и компьютеров
Они используются для административных целей и имеют такой же смысл, как и при использовании на локальных машинах в сети. В отличие от OU, к группам нельзя применять групповые политики, но для них можно делегировать управление. В рамках схемы Active Directory выделяют два вида групп: группы безопасности (применяются для разграничения прав доступа к объектам сети) и группы распространения (применяются в основном для рассылки почтовых сообщений, например, в сервере Microsoft Exchange Server).
Они подразделяются по области действия:
- универсальные группы могут включать в себя пользователей в рамках леса, а также другие универсальные группы или глобальные группы любого домена в лесу;
- глобальные группы домена могут включать в себя пользователей домена и другие глобальные группы этого же домена;
- локальные группы домена используются для разграничения прав доступа, могут включать в себя пользователей домена, а также универсальные группы и глобальные группы любого домена в лесу;
- локальные группы компьютеров – группы, которые содержит SAM (security account manager) локальной машины. Область их распространения ограничивается только данной машиной, но они могут включать в себя локальные группы домена, в котором находится компьютер, а также универсальные и глобальные группы своего домена или другого, которому они доверяют. Например, вы можете включить пользователя из доменной локальной группы Users в группу Administrators локальной машины, тем самым дав ему права администратора, но только для этого компьютера.
Сайты
Это способ физического разделения службы каталогов. По определению сайт – это группа компьютеров, соединенных быстрыми каналами передачи данных.
Например, если вы имеете несколько филиалов в разных концах страны, соединенных низкоскоростными линиями связи, то для каждого филиала вы можете создать свой сайт. Делается это для повышения надежности репликации каталога.
Такое разбиение AD не влияет на принципы логического построения, поэтому как сайт может содержать в себе несколько доменов, так и наоборот, домен может содержать несколько сайтов. Но такая топология службы каталогов таит в себе подвох. Как правило, для связи с филиалами используется Интернет – очень небезопасная среда. Многие компании используют средства защиты, например, брандмауэры. Служба каталогов в своей работе использует около полутора десятков портов и служб, открытие которых для прохождения трафика AD через брандмауэр, фактически выставит ее «наружу». Решением проблемы является использование технологии туннелирования, а также наличие в каждом сайте контроллера домена для ускорения обработки запросов клиентов AD.
На рис. 3 представлена логика вложенности составляющих службы каталогов. Видно, что лес содержит два дерева доменов, в которых корневой домен дерева, в свою очередь, может содержать OU и группы объектов, а также иметь дочерние домены (в данном случае их по одному у каждого). Дочерние домены также могут содержать группы объектов и OU и иметь дочерние домены (на рисунке их нет). И так далее. Напомню, что OU могут содержать OU, объекты и группы объектов, а группы могут содержать другие группы. Более подробно о вложенности групп и их составляющих читайте в следующей статье.
Сущность службы каталогов
Чтобы обеспечить некоторый уровень безопасности, любая операционная система должна иметь файлы, содержащие базу данных пользователей. В ранних версиях Windows NT для этого использовался файл SAM (Security Accounts Manager – менеджер учетных записей). Он содержал учетные данные пользователей и был зашифрован. Сегодня SAM также используется в операционных системах семейства NT 5 (Windows 2000 и выше).
Когда вы повышаете роль рядового сервера до контроллера домена с помощью команды DCPROMO (фактически она запускает мастер установки службы каталогов), подсистема безопасности Windows Server 2000/2003 начинает использовать централизованную базу данных AD. Это можно легко проверить – попробуйте после создания домена открыть на контроллере оснастку Computer Management и найти там «Локальные пользователи и группы». Более того, попробуйте войти на этот сервер под локальной учетной записью. Вряд ли у вас получится.
Большинство данных пользователей сохраняются в файле NTDS.DIT (Directory Information Tree – дерево информации каталога). NTDS.DIT – это модифицированная база данных. Она создана с использованием той же технологии, что и база данных Microsoft Access. Алгоритмы работы контроллеров домена содержат вариант движка JET базы данных Access, который был назван ESE (Extensible Storage Engine – расширяемый движок хранения информации). NTDS.DIT и службы, обеспечивающие взаимодействие с этим файлом, фактически и есть служба каталогов.
Структура взаимодействия клиентов AD и основного хранилища данных, аналогично как и пространство имен службы каталогов, представлены в статье . Для полноты описания нужно упомянуть об использовании глобальных идентификаторов. Глобальный уникальный идентификатор (Global Unique Identifier, GUID) – это 128-разрядное число, сопоставляемое каждому объекту при его создании для обеспечения уникальности. Имя объекта AD можно изменить, а вот GUID останется неизменным.
Глобальный каталог
Наверняка вы успели заметить, что структура AD может быть весьма сложной и вмещать в себя большое количество объектов. Чего стоит только тот факт, что домен AD может включать в себя до 1,5 млн. объектов. Но из-за этого могут возникнуть проблемы с производительностью при выполнении операций. Эта проблема решается с помощью Глобального каталога (Global Catalog, GC). Он содержит сокращенную версию всего леса AD, что помогает ускорять поиск объектов. Владельцем глобального каталога могут выступать специально назначенные для этого контроллеры домена.
Роли FSMO
В AD существует определенный перечень операций, выполнение которых можно возложить только на один контроллер. Они называются ролями FSMO (Flexible Single-Master Operations – операции с одним хозяином). Всего в AD 5 ролей FSMO. Рассмотрим их более подробно.
В рамках леса обязательно должна существовать гарантия уникальности доменных имен при добавлении нового домена к лесу доменов. Такая гарантия осуществляется исполнителем роли владельца операции именования доменов (Domain Naming Master) Исполнитель роли владельца схемы (Schema Master) осуществляет все изменения в схеме каталога. Исполнители ролей владельца доменных имен и владельца схемы должны быть уникальны в рамках леса доменов.
Как я уже говорил, при создании объекта ему сопоставляется глобальный идентификатор, гарантирующий его уникальность. Именно поэтому контроллер, отвечающий за генерацию GUID и исполняющий роль владельца относительных идентификаторов (Relative ID Master), должен быть один-единственный в рамках домена.
В отличие от доменов NT в AD нет понятия PDC и BDC (основной и резервный контроллеры домена). Одной из ролей FSMO является PDC Emulator (эмулятор основного контроллера домена). Сервер под управлением Windows NT Server может выступать в роли резервного контроллера домена в AD. Но известно, что в доменах NT может использоваться только один основной контроллер. Именно поэтому Microsoft сделала так, что в рамках одного домена AD мы можем назначить единственный сервер – носитель роли PDC Emulator. Таким образом, отступая от терминологии, можно говорить о наличии главного и резервных контроллеров домена, имея в виду обладателя роли FSMO.
При удалении и перемещении объектов один из контроллеров должен сохранить ссылку на этот объект, пока не будет полностью завершена репликация. Такую роль выполняет владелец инфраструктуры каталога (Infrastructure Master).
Последние три роли требуют уникальности исполнителя в рамках домена. Все роли возлагаются на первый контроллер, созданный в лесу. При создании разветвленной инфраструктуры AD вы можете передавать эти роли другим контроллерам. Могут возникать также ситуации, когда владелец одной из ролей недоступен (вышел из строя сервер). В этом случае необходимо выполнить операцию захвата роли FSMO с помощью утилиты NTDSUTIL (о ее использовании мы поговорим в следующих статьях). Но стоит быть осторожным, так как при захвате роли служба каталогов полагает, что предыдущего владельца нет, и не обращается к нему вовсе. Возвращение в сеть прежнего исполнителя роли может привести к нарушению ее функционирования. Особенно это критично для владельца схемы, владельца доменных имен и владельца идентификаторов.
Что касается производительности: наиболее требовательна к запасу ресурсов компьютера роль эмулятора основного контроллера домена, поэтому ее можно возложить на другой контроллер. Остальные роли не столь требовательны, поэтому при их распределении вы можете руководствоваться нюансами логического построения схемы вашей AD.
Последний шаг теоретика
Прочтение статьи вовсе не должно перевести вас из теоретиков в практики. Потому что, пока вы не учли все факторы от физического размещения узлов сети до логического построения всего каталога, не стоит браться за дело и воздвигать домен простыми ответами на вопросы мастера установки AD. Подумайте, как будет называться ваш домен и, если вы собираетесь создать дочерние для него, по каким признакам они будут именоваться. При наличии в сети нескольких сегментов, соединенных ненадежными каналами связи, рассмотрите возможность использования сайтов.
Как руководство по установке AD могу посоветовать использовать статьи и , а также базу знаний Microsoft.
Напоследок несколько советов:
- Постарайтесь по возможности не совмещать роли PDC Emulator и прокси-сервера на одной машине. Во-первых, при большом количестве машин в сети и пользователей Интернет возрастает нагрузка на сервер, а во-вторых, при удачной атаке на ваш прокси «упадет» не только Интернет, но и основной контроллер домена, а это чревато некорректной работой всей сети.
- Если вы постоянно администрируете локальную сеть, а не собираетесь заняться внедрением Active Directory для заказчиков, вносите машины в домен постепенно, скажем, по четыре-пять в день. Поскольку если у вас в сети большое количество машин (50 и больше) и вы управляете ею один, то вряд ли вы управитесь даже за выходные, а если и управитесь, то насколько все будет корректно, неизвестно. К тому же для обмена документацией внутри сети вы можете использовать файловый или внутренний почтовый сервер (такой был описан мной в №11 за 2006 г.). Единственное, в этом случае стоит корректно разобраться в настройке прав пользователей для доступа к файловому серверу. Потому что, если, например, он не будет включен в домен, аутентификация пользователей будет осуществляться, основываясь на записях локальной базы SAM. Там нет данных о доменных пользователях. Однако если ваш файловый сервер будет в числе первых машин, включенных в AD, и не будет контроллером домена, то будет существовать возможность аутентификации посредством как локальной базы SAM, так и учетной базы AD. Но для последнего варианта вам нужно будет в локальных настройках безопасности разрешить (если это еще не сделано) доступ к файловому серверу по сети как участникам домена, так и локальным учетным записям.
О дальнейшей настройке службы каталогов (создание и управление учетными записями, назначение групповых политик и др.) читайте в следующей статье.
Приложение
Новшества Active Directory в Windows Server 2003
С выходом Windows Server 2003 в Active Directory появились следующие изменения:
- Стало возможным переименование домена после его создания.
- Улучшился пользовательский интерфейс управления. Например, можно изменить атрибуты сразу нескольких объектов.
- Появилось хорошее средство управления групповыми политиками – Group Policy Management Console (gpmc.msc, ее нужно скачивать с сайта Microsoft).
- Изменились функциональные уровни домена и леса.
О последнем изменении нужно сказать подробнее. Домен AD в Windows Server 2003 может находиться на одном из следующих уровней, перечисленных в порядке роста функциональности:
- Windows 2000 Mixed (смешанный Windows 2000) . В нем допускается иметь контроллеры различных версий – как Windows NT, так и Windows 2000/2003. Причем если серверы Windows 2000/2003 равноправны, то сервер NT, как уже говорилось, может выступать только резервным контроллером домена.
- Windows 2000 Native (естественный Windows 2000) . Допускается иметь контроллеры под управлением Windows Server 2000/2003. Этот уровень более функционален, но имеет свои ограничения. Например, вы не сможете переименовывать контроллеры доменов.
- Windows Server 2003 Interim (промежуточный Windows Server 2003) . Допускается иметь контроллеры под управлением Windows NT, а также Windows Server 2003. Используется, например, когда главный контроллер домена под управлением сервера Windows NT обновляется до W2K3. Уровень имеет чуть большую функциональность, чем уровень Windows 2000 Native.
- Windows Server 2003 . Допускается наличие в домене контроллеров только под управлением Windows Server 2003. На этом уровне можно воспользоваться всеми возможностями службы каталогов Windows Server 2003.
Функциональные уровни леса доменов практически те же, что и для доменов. Единственное исключение – существует только один уровень Windows 2000, на котором возможно использование в лесу контроллеров под управлением Windows NT, а также Windows Server 2000/2003.
Стоит заметить, что изменение функционального уровня домена и леса является операцией необратимой. То есть отсутствует обратная совместимость.
- Коробко И. Active Directory – теория построения. //«Системный администратор», №1, 2004 г. – C. 90-94. ().
- Марков Р. Домены Windows 2000/2003 – отказываемся от рабочей группы. //«Системный администратор», №9, 2005 г. – C. 8-11. ().
- Марков Р. Установка и настройка Windows 2К Server. //«Системный администратор», №10, 2004 г. – C. 88-94. ().
Антивирус Bitdefender: эффективный защитник Без вопросов
Значение слова неудачный
Обзор Samsung Galaxy A7 (2017): не боится воды и экономии Стоит ли покупать samsung a7
Делаем бэкап прошивки на андроиде
Как настроить файл подкачки?