Будучи хорошо знакомым с малым бизнесом изнутри, меня всегда интересовали следующие вопросы. Объясните, почему сотрудник должен пользоваться на рабочем компьютере тем браузером, который нравится сисадмину? Или взять любое другое программное обеспечение, например, тот же архиватор, почтовый клиент, клиент мгновенных сообщений… Это я плавно намекаю на стандартизацию, причем не по признакам личной симпатии сисадмина, а по признакам достаточности функционала, стоимости обслуживания и поддержки этих программных продуктов. Давайте начнем считать ИТ точной наукой, а не ремеслом, когда каждый делает так, как у него получается. Опять-таки, с этим в малом бизнесе тоже очень много проблем. Представьте, что компания в нелегкое кризисное время меняет нескольких таких администраторов, что в такой ситуации делать бедным пользователям? Постоянно переучиваться?

Давайте посмотрим с другой стороны. Любой руководитель должен понимать, что у него сейчас происходит в компании (в том числе и в ИТ). Это необходимо для отслеживания текущей ситуации, для оперативного реагирования на возникновение разного рода проблем. Но это понимание является более важным для стратегического планирования. Ведь, имея крепкий и надежный фундамент, мы можем строить дом на 3 этажа или на 5, делать крышу разной формы, делать балконы или зимний сад. Точно также и в ИТ, имеем надежную основу – можем в дальнейшем использовать более сложные продукты и технологии для решения бизнес-задач.

В первой статье и пойдет речь о таком фундаменте – службах Active Directory . Именно они призваны стать крепким фундаментом ИТ-инфраструктуры компании любого размера и любого направления деятельности. Что это такое? Вот давайте об этом и поговорим…

А разговор начнем с простых понятий – домена и служб Active Directory.

Домен – это основная административная единица в сетевой инфраструктуре предприятия, в которую входят все сетевые объекты, такие как пользователи, компьютеры, принтеры, общие ресурсы и многое другое. Совокупность таких доменов называется лесом.

Службы Active Directory (службы активного каталога ) представляют собой распределённую базу данных, которая содержит все объекты домена. Доменная среда Active Directory является единой точкой аутентификации и авторизации пользователей и приложений в масштабах предприятия. Именно с организации домена и развёртывания служб Active Directory начинается построение ИТ-инфраструктуры предприятия.

База данных Active Directory хранится на выделенных серверах – контроллерах домена. Службы Active Directory являются ролью серверных операционных систем Microsoft Windows Server. Службы Active Directory имеют широкие возможности масштабирования. В лесу Active Directory может быть создано более 2-х миллиардов объектов, что позволяет внедрять службу каталогов в компаниях с сотнями тысяч компьютеров и пользователей. Иерархическая структура доменов позволяет гибко масштабировать ИТ-инфраструктуру на все филиалы и региональные подразделения компаний. Для каждого филиала или подразделения компании может быть создан отдельный домен, со своими политиками, своими пользователями и группами. Для каждого дочернего домена могут быть делегированы административные полномочия местным системным администраторам. При этом всё равно дочерние домены подчиняются родительским.

Кроме того, службы Active Directory позволяют настроить доверительные отношения между доменными лесами. Каждая компания имеет собственный лес доменов, каждый из которых имеет собственные ресурсы. Но иногда бывает нужно предоставить доступ к своим корпоративным ресурсам сотрудникам другой компании – работа с общими документами и приложениями в рамках совместного проекта. Для этого между лесами организаций можно настроить доверительные отношения, что позволит сотрудникам одной организации авторизоваться в домене другой.

Для обеспечения отказоустойчивости служб Active Directory необходимо развернуть два или более контроллера домена в каждом домене. Между контроллерами домена обеспечивается автоматическая репликация всех изменений. В случае выхода из строя одного из контроллеров домена работоспособность сети не нарушается, ведь оставшиеся продолжают работать. Дополнительный уровень отказоустойчивости обеспечивает размещение серверов DNS на контроллерах домена в Active Directory, что позволяет в каждом домене получить несколько серверов DNS, обслуживающих основную зону домена. И в случае отказа одного из DNS серверов, продолжат работать остальные. О роли и значимости DNS серверов в ИТ-инфраструктуре мы еще поговорим в одной из статей цикла.

Но это всё технические аспекты внедрения и поддержания работоспособности служб Active Directory. Давайте поговорим о тех преимуществах, которые получает компания, отказываясь от одноранговой сети с использованием рабочих групп.

1. Единая точка аутентификации

В рабочей группе на каждом компьютере или сервере придётся вручную добавлять полный список пользователей, которым требуется сетевой доступ. Если вдруг один из сотрудников захочет сменить свой пароль, то его нужно будет поменять на всех компьютерах и серверах. Хорошо, если сеть состоит из 10 компьютеров, но если их больше? При использовании домена Active Directory все учётные записи пользователей хранятся в одной базе данных, и все компьютеры обращаются к ней за авторизацией. Все пользователи домена включаются в соответствующие группы, например, «Бухгалтерия», «Финансовый отдел». Достаточно один раз задать разрешения для тех или иных групп, и все пользователи получат соответствующий доступ к документам и приложениям. Если в компанию приходит новый сотрудник, для него создаётся учётная запись, которая включается в соответствующую группу, – сотрудник получает доступ ко всем ресурсам сети, к которым ему должен быть разрешён доступ. Если сотрудник увольняется, то достаточно заблокировать – и он сразу потеряет доступ ко всем ресурсам (компьютерам, документам, приложениям).

2. Единая точка управления политиками

В рабочей группе все компьютеры равноправны. Ни один из компьютеров не может управлять другим, невозможно проконтролировать соблюдение единых политик, правил безопасности. При использовании единого каталога Active Directory, все пользователи и компьютеры иерархически распределяются по организационным подразделениям, к каждому из которых применяются единые групповые политики. Политики позволяют задать единые настройки и параметры безопасности для группы компьютеров и пользователей. При добавлении в домен нового компьютера или пользователя, он автоматически получает настройки, соответствующие принятым корпоративным стандартам. При помощи политик можно централизованно назначить пользователям сетевые принтеры, установить необходимые приложения, задать параметры безопасности браузера, настроить приложения Microsoft Office.

3. Повышенный уровень информационной безопасности

Использование служб Active Directory значительно повышает уровень безопасности сети. Во-первых – это единое и защищённое хранилище учётных записей. В доменной среде все пароли доменных пользователях хранятся на выделенных серверах контроллерах домена, которые, как правило, защищены от внешнего доступа. Во-вторых, при использовании доменной среды для аутентификации используется протокол Kerberos, который значительно безопаснее, чем NTLM, использующийся в рабочих группах.

4. Интеграция с корпоративными приложениями и оборудованием

Большим преимуществом служб Active Directory является соответствие стандарту LDAP, который поддерживается другими системами, например, почтовыми серверами (Exchange Server), прокси-серверами (ISA Server, TMG). Причем это не обязательно только продукты Microsoft. Преимущество такой интеграции заключается в том, что пользователю не требуется помнить большое количество логинов и паролей для доступа к тому или иному приложению, во всех приложениях пользователь имеет одни и те же учётные данные – его аутентификация происходит в едином каталоге Active Directory. Windows Server для интеграции с Active Directory предоставляет протокол RADIUS, который поддерживается большим количеством сетевого оборудования. Таким образом, можно, например, обеспечить аутентификацию доменных пользователей при подключении по VPN извне, использование Wi-Fi точек доступа в компании.

5. Единое хранилище конфигурации приложений

Некоторые приложения хранят свою конфигурацию в Active Directory, например, Exchange Server. Развёртывание службы каталогов Active Directory является обязательным условием для работы этих приложений. Хранение конфигурации приложений в службе каталогов является выгодным с точки зрения гибкости и надёжности. Например, в случае полного отказа сервера Exchange, вся его конфигурация останется нетронутой. Для восстановления работоспособности корпоративной почты, достаточно будет переустановить Exchange Server в режиме восстановления.

Подводя итоги, хочется еще раз акцентировать внимание на том, что службы Active Directory являются сердцем ИТ-инфраструктуры предприятия. В случае отказа вся сеть, все сервера, работа всех пользователей будут парализованы. Никто не сможет войти в компьютер, получить доступ к своим документам и приложениям. Поэтому служба каталогов должна быть тщательно спроектирована и развёрнута, с учётом всех возможных нюансов, например, пропускной способности каналов между филиалами или офисами компании (от этого напрямую зависит скорость входа пользователей в систему, а также обмен данными между контроллерами домена).

Один из вариантов построения локальной сети – это сеть на основе сервера . Подобного рода сети используются в том случае, когда количество компьютеров превышает 15-20 штук. В такой ситуации уже неуместно использовать так называемые рабочие группы , поскольку одноранговая сеть с таким количеством узлов не может обеспечить необходимый уровень управляемости и контроля. В этом случае функции контроля лучше возложить на управляющий сервер – .

Для управления работой сервера используются специальные версии операционной системы с расширенными функциями администрирования. Примерами таких операционных систем являются Windows Server 2008 или Windows Server 2012 .

После установки на отдельный компьютер серверной операционной системы, прежде чем она сможет организовать работу локальной сети, требуется произвести определенные настройки. Серверная операционная система представляет собой универсальный механизм с очень широкими возможностями, или, как их часто называют, ролями. Одной из таковых ролей, причем, наверное, самой сложной и ответственной, является . Если вы планируете получить эффективный механизм управления пользователями сети, его придется в любом случае настроить.

Создание контроллера домена влечет за собой установку такого системного механизма, как Active Directory – основного средства создания, настройки и управления учетными записями пользователей и компьютеров локальной сети. Кроме того, как правило, на контроллер домена сразу же добавляются роли и , что делает сервер законченным и готовым к использованию продуктом.

Одним из безусловных плюсов доменной системы является возможность гибкой настройки групповых политик, с помощью которых можно ограничивать доступ не только к программной, но и к аппаратной части компьютера. Например, легко можно запретить использование DVD-привода, флеш-накопителей и т.д. Групповая политика начинается в момент входа пользователя в сеть, поэтому ему никак не удастся обойти эти ограничения.

Контроллер домена – наиболее важное и уязвимое место локальной сети, поэтому рекомендуется создавать резервный контроллер. В этом случае дополнительный контроллер домена получает название вторичного, а главный домен становится первичным контроллером домена. Периодически происходит синхронизация данных учетных записей и прав доступа, поэтому в случае выхода из строя первичного контроллера – сразу же подключается вторичный, и работа в сети не прерывается ни на секунду. Кроме того, необходимо обеспечивать пассивную защиту домена путем установки на сервер источника бесперебойного питания.

Чтобы не вдаваться в большое число специальных терминов, контроллеры доменов являются серверами, поддерживающими работу Active Directory. Они хранят информацию об учетных записях пользователей и компьютеров, входящих в домен, схему, а также собственную копию базы данных Active Directory, поддерживающую запись. Помимо этого, контроллеры домена выступают в роли центрального компонента безопасности в домене. Подобная организация позволяет гибко настраивать политики безопасности в рамках корпоративной сети, а также разрешать, или наоборот, запрещать определенным группам пользователей доступ к тем или иным ресурсам.

Основные функции контроллера домена:

• Хранение полной копии информации Active Directory, которая относится к конкретному домену, управление и репликация данной информации на другие контроллеры входящие в данный домен;
• Репликация информации каталога, относящейся ко всем объектам домена Active Directory;
• Разрешение конфликтов репликации, когда один и тот же атрибут был изменен на разных контроллерах до момента инициализации репликации.

Преимущества для бизнеса

Преимущества централизованной системы на базе контроллеров домена:

1. Единая база данных для аутентификации. Контроллер домена хранит все учетные записи в одной базе данных и каждый пользователь, входящего в домен компьютера, обращается к контроллеру домена для входа в систему. Разделение пользователей по соответствующим группам позволяет упростить организацию распределенного доступа к документам и приложениям. Таким образом, при появлении нового сотрудника, достаточно создать для него учетную запись в соответствующей группе и сотрудник автоматически получит доступ ко всех необходимым сетевым ресурсам и устройствам. При уходе сотрудника достаточно заблокировать его учетную запись для отзыва всех доступов.
2. Единая точка управления политиками. Контроллер домена позволяет распределять учетные записи компьютеров и пользователей по организационным подразделениям и применять к ним различные групповые политики, определяя настройки и параметры безопасности для группы компьютеров и пользователей (напр. доступ к сетевым принтерам, набор необходимых приложений, настройки браузера и т.д). Таким образом, при добавлении в домен нового компьютера или пользователя, он автоматически получит все настройки и доступы, определенные для того или иного подразделения.
3. Безопасность. Гибкая настройка процедур аутентификации и авторизации, в совокупности с централизованным управлением позволяют значительно повысить безопасность IT-инфраструктуры в рамках организации. Помимо этого, физически контроллер домена устанавливается в специальном месте, защищенном от внешнего доступа.
4. Упрощенная интеграция с другими сервисами. Использование контроллера домена в качестве единой точки аутентификации позволяет пользователям использовать одну и ту же учетную запись при работе с дополнительными инструментами и службами (напр. почтовые службы, офисные программы, прокси-серверы, мессенджеры, и т.д).

Настройка

Контроллер домена на базе доменной службы Active Directory является ключевым элементом IT-инфраструктуры, обеспечивающий контроль доступа, а также защиту данных в рамках организации. От корректной настройки контроллера домена зависит функционирование не только самого контроллера домена, но также и Active Directory в целом (например, распространение политик безопасности и правил доступа), что в свою очередь влияет на работу всех сопутствующих служб и сервисов, а также определяет уровень безопасности. Выбирайте лучших разработчиков в разделе.

Контроллеры доменов являются серверами, поддерживающими работу Active Directory. Каждый контроллер домена имеет собственную копию базы данных Active Directory, поддерживающую запись. Контроллеры домена выступают в роли центрального компонента безопасности в домене.

Все операции безопасности и проверки учетных записей выполняются на контроллере домена. Каждый домен должен иметь как минимум один контроллер домена. Для обеспечения устойчивости к ошибкам рекомендуется для каждого домена устанавливать как минимум два контроллера домена.

В операционной системе Windows NT запись в базу данных поддерживал только один контроллер домена, то есть для создания и изменения параметров учетных записей пользователей необходимо было подключение к контроллеру домена.

Такой контроллер назывался первичным контроллером домена (Primary Domain Controller - PDC) . Начиная с операционной системы Windows 2000 архитектура контроллеров доменов была изменена таким образом, чтобы обеспечить возможность обновления базы данных Active Directory на любом контроллере домена. После обновления базы данных на одном контроллере домена, изменения реплицировались на все остальные контроллеры.

Хотя все контроллеры домена поддерживают запись в базу данных, они не идентичны. В доменах и лесах Active Directory существуют задачи, которые выполняются определенными контроллерами домена. Контроллеры домена с дополнительными обязанностями известны как хозяева операций (operation masters) . В некоторых материалах компании Microsoft такие системы называются Flexible Single-Master Operations (FSMO) . Многие верят, что термин FSMO использовался так долго только из-за того, что произнесенная аббревиатура звучит очень смешно.

Существует пять ролей хозяев операций. По умолчанию все пять ролей выдаются первому контроллеру домена в лесу Active Directory. Три роли хозяев операций используются на уровне доменов и назначаются первому контроллеру домена в созданном домене. Утилиты Active Directory, которые рассматриваются далее, позволяют передавать роли хозяев операций от одного контроллера другому контроллеру домена. Кроме этого, можно заставить контроллер домена принять на себя определенную роль хозяина операции.

Существует две роли хозяев операций, которые работают на уровне леса.

• Хозяин именования домена (Domain naming master) - к этим хозяевам операций необходимо обращаться каждый раз, когда в пределах иерархии доменов леса вносятся изменения в именование. Задачей хозяина именования домена заключается в обеспечении уникальности имен доменов в пределах леса. Эта роль хозяина операций должна быть доступна при создании новых доменов, удалении доменов или переименовании доменов
• Хозяин схемы (Schema master) - роль хозяина схемы принадлежит единственному контроллеру домена в пределах леса, на котором можно вносить изменения в схему. Как только изменения внесены, они реплицируются на все остальные контроллеры домена в пределах леса. В качестве примера необходимости внесения изменений в схему можно рассмотреть установку программного продукта Microsoft Exchange Server. При этом в схему вносятся изменения, позволяющие администратору одновременно управлять учетными записями пользователей и почтовыми ящиками

Каждая из ролей на уровне леса может принадлежать только одному контроллеру домена в пределах леса. То есть, можно использовать один контроллер в роли хозяина именования домена, а второй контроллер в роли хозяина схемы. Кроме этого, обе роли можно назначить одному контроллеру домена. Такое распределение ролей используется по умолчанию.

Каждый домен в пределах леса имеет контроллер домена, выполняющий каждую из ролей уровня домена.

• Хозяин относительных идентификаторов (RID master) - хозяин относительных идентификаторов отвечает за назначение относительных идентификаторов. Относительные идентификаторы являются уникальной частью идентификатора безопасности (Security ID - SID), который используется для определения объекта безопасности (пользователя, компьютера, группы и т.д.) в пределах домена. Одной из главных задач хозяина относительных идентификаторов является удаление объекта из одного домена и добавление объекта в другой домен при перемещении объектов между доменами.
• Хозяин инфраструктуры (Infrastructure master) - задачей хозяина инфраструктуры является синхронизация членства в группах. При внесении изменений в состав групп, хозяин инфраструктуры сообщает об изменениях всем остальным контроллерам домена.
• Эмулятор первичного контроллера домена (PDC Emulator) - эта роль используется для эмуляции первичного контроллера домена Windows NT 4 для поддержки резервных контроллеров домена Windows NT 4. Еще одной задачей эмулятора первичного контроллера домена является предоставление центральной точки администрирования изменений в паролях пользователей, а также политик блокирования пользователей.

Слово "политики" достаточно часто используется в этом разделе для ссылки на объекты групповых политик (group policy objects - GPO). Объекты групповых политик являются одной из главных полезных особенностей Active Directory и рассматриваются в соответствующей статье, ссылка на которую представлена ниже.

Так уж получилось в нашей организации, что инфраструктуру надо было делать быстро, а на покупку лицензий требовалось время. Поэтому было решено использовать образы Windows Server 2012R2 Evaluation, а после тестового периода уже лицензировать. Тогда еще никто не знал, что нельзя просто так взять, прописать лицензию Standard в релизе Evaluation, и на выходе получить лицензионный Standard, иначе, думаю, сначала бы все таки купили лицензии. Но делать нечего, что имеем, с тем и работаем. Итак.

Задача: после покупки лицензий Microsoft на Windows server 2012R2 Standard необходимо активировать их на наших серверах. Приступаем.

При выполнении задачи была обнаружена проблема. Так как изначально мы устанавливали Windows server 2012R2 Standard Evaluation, то при попытке прописать ключ для Standard - сервер говорит, что ему этот ключ не подходит. Начали поиск решения проблемы перевода сервера из версии Evaluation в Standard. Ответ был найден на сайте microsoft в статье TechNet .

Частично статья помогла решить проблему. Мы смогли поменять версию на трех физических серверах и активировать их нашими лицензиями. Но, к сожалению, не все так просто складывалось с контроллерами домена. В вышеуказанной статье прямым текстом говорится, что контроллеры домена НЕВОЗМОЖНО перевести из выпуска Evaluation в Standard. Нам же это необходимо сделать в самые кратчайшие сроки, т.к. количество возможных /rearm у PDC закончилось, а дней до окончания ознакомительной версии осталось меньше 3 дней.

Варианта решения вопроса я видел два. Либо поочередно между BDC и PDC передавать права хозяина схемы и прочие роли, понижать до рядовых серверов и после поднимать обратно. Но идею этого доменного волейбола я отмел, по причине того, что просто напросто делал все это впервые и боялся поломать.

Поэтому было решено поднимать новый сервер, повышать до контроллера домена и передавать ему хозяина схемы, а после выключать старый PDC и назначать новому его IP, этот вариант тогда мне показался проще и безопаснее. Замечу, что после описанных ниже событий, я по прежнему считаю это хорошим решением, по крайней мере все прошло без эксцессов, иначе бы статья имела совсем другой заголовок, или ее бы не было вовсе.

Схему можно без проблем воспроизвести в течение рабочего дня. Оставалось полтора дня, так что, помечтать о том, как я буду все это делать времени не было, надо было срочно приступать. Далее действия по пунктам.

1. Создаем новую виртуальную машину с параметрами соответствующими текущему PDC. Желательно создать на физическом сервере, на котором нет других контроллеров домена, но это если у вас несколько гипервизоров, как в моем случае, если нет, то это не принципиально, вопрос только в отказоустойчивости. Ну а если вы работаете не с гипервизорами, а с реальными серверами, то отказоустойчивость PDC и BDC вещь и так само собой разумеющаяся.

2. Устанавливаем Windows Server 2012R2. Выбираем выпуск Standard с графическим интерфейсом. Настраиваем TCP/IP и переименовываем сервер в соответствии со стандартном наименований в IT инфраструктуре.

3. После установки в диспетчере серверов включаем серверу новые роли. Нас интересует AD, DNS и прочие роли и компоненты, используемые на текущих домен-контроллерах.

4. Повышаем сервер до контроллера домена. Проходит репликация между основным контроллером домена и новым.

5. Передаем роли хозяина схемы со старого DC на новый.
Для этого заходим на контроллер домена, которому будут назначаться роли FSMO, запускаем командную строку, и вводим команды в указанной ниже последовательности:

ntdsutil
roles
connections
connect to server <имя сервера PDC>
q

Успешно подключившись к серверу, мы получим приглашение к управлению ролями (FSMO maintenance), и можем приступать к передаче ролей:

transfer naming master - передача роли хозяина доменных имен.
transfer infrastructure master - передача роли хозяина инфраструктуры;
transfer rid master - передача роли хозяина RID;
transfer schema master - передача роли хозяина схемы;
transfer pdc - передача роли эмулятора PDC

Для завершения работы Ntdsutil вводим команду q.

6. После передачи хозяина схемы смотрим системный журнал и dcdiag на предмет ошибок. Их быть не должно. Если есть, исправляем. (я столкнулся с ошибкой dns, где сервер жаловался на неправильно указанные сервера пересылки. В этот же день я узнал, что в серверах пересылки DNS не должен быть указан сервер на котором установлен DNS (как правило указывают сервера DNS провайдера и Yandex(Google), что в общем-то логично, это по сути порождает петлю в DNS.

7. Если ошибки исправлены, или их нет. Приступаем к сменам IP-адресов. Назначаем старому PDC любой свободный IP-адрес в сети, а новому PDC назначаем адрес старого.

8. Снова проверяем на ошибки. Проводим тесты. Выключаем старый PDC и BDC. Проверяем возможность авторизации в домене. Затем оставляем включенным только BDC, проверяем принимает ли он на себя роль контроллера домена в случае недоступности PDC.

9. Если все тесты проходят удачно. Можно уничтожать старый PDC и приниматься за смену версии BDC.

10. В нашем случае cтарый PDC все еще нельзя было выкинуть на помойку так как на нем функционировала роль пространства имен DFS, а мы не знали, как ее реплицировать на новый сервер.

11. Все оказалось очень просто. Входим в графическую оснастку «Управление DFS». В «Пространстве имен» добавляем существующие пространства имен, затем каждому пространству имен добавляем сервер пространства имен и в общем-то все. Корень dfs автоматически вместе с ссылками на сетевые ресурсы появляется на c:\ и все работает. На всякий случай проверяем работу выключением старого PDC. Сначала сетевые ресурсы будут недоступны (DFS нужно 300 секунд для репликации). По истечении 5 минут сетевые ресурсы снова должны стать доступны.

12. Оставляем старый PDC выключенным и через какое то время понижаем до рядового сервера и после удаляем. Можно конечно и сразу, но мне было страшно и я до последнего не верил, что все получилось без проблем.

P.S.: Все вышеописанные действия проводились после внимательного изучения книги Windows server 2012R2 - Полное руководство. В частности глав посвященных конкретно AD, DNS и DFS, а так же контроллерам домена. Без понимания и планирования к данным действиям лучше не приступать, т.к. можно потерять рабочую инфраструктуру.

Надеюсь, для кого-то эта статья окажется полезной и нужной. Спасибо за внимание!