Актив директория. Зачем организации нужна Active Directory? VPN и двухфакторная аутентификация

Active Directory - служба каталогов корпорации Microsoft для ОС семейства Windows NT.

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

В чем суть работы Active Directory и какие задачи она решает? Читайте дальше.

Принципы организации одноранговых и многоранговых сетей

Но возникает другая проблема, что если пользователь user2 на РС2 решит изменить свой пароль? Тогда если пользователь user1 сменит пароль учетной записи, доступ user2 на РС1 к ресурсу будет невозможен.

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

А если их будет не 20 а 200?

Как вы понимаете администрирование сети при таком подходе превращается в кромешный ад.

Поэтому подход с использованием рабочих групп подходит для небольших офисных сетей с количеством ПК не более 10 единиц.

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

Этим узлом и выступает контролер домена - Active Directory.

Контролер домена

Контролер хранит базу данных учетных записей, т.е. он хранит учетку и для РС1 и для РС2.

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

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

После контролер выдает пользователю, осуществившему вход, что-то вроде паспорта, с которым он в дальнейшем работает в сети и который он предъявляет по запросу других компьютеров сетки, серверов к чьим ресурсам он хочет подключиться.

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

Число таких сохраненных ресурсов может достигать миллионов объектов.

В качестве контролера домена могут выступать следующие версии MS Windows : Windows Server 2000/2003/2008/2012 кроме редакций Web-Edition.

Контролер домена помимо того, что является центром аутентификации сети, также является центром управления всеми компьютерами.

Сразу после включения компьютер начинает обращаться к контролеру домена, задолго до появления окна аутентификации.

Таким образом, выполняется аутентификация не только пользователя, вводящего логин и пароль, но и аутентификация клиентского компьютера.

Установка Active Directory

Рассмотрим пример установки Active Directory на Windows Server 2008 R2. Итак для установки роли Active Directory, заходим в «Server Manager»:

Добавляем роль «Add Roles»:

Выбираем роль Active Directory Domain Services:

И приступаем к установке:

После чего получаем окно уведомления, об установленной роли:

После установки роли контролера домена, приступим к установке самого контролера.

Нажимаем «Пуск» в поле поиска программ вводим название мастера DCPromo, запускаем его и ставим галочку для расширенных настроек установки:

Жмем «Next» из предложенных вариантов выбираем создание нового домена и леса.

Вводим имя домена, например, example.net.

Пишем NetBIOS имя домена, без зоны:

Выбираем функциональный уровень нашего домена:

Ввиду особенностей функционирования контролера домена, устанавливаем также DNS-сервер .

Расположения базы данных, файла логов, системного тома оставляем без изменений:

Вводим пароль администратора домена:

Проверяем правильность заполнения и если все в порядке жмем «Next».

После этого пойдет процесс установки, в конце которого появится окно, которое сообщает, об успешной установке:

Введение в Active Directory

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

Чем поможет Active Directory специалистам?

приведу небольшой список "вкусняшек", которые можно получить развернув Active Directory:

  • единая база регистрации пользователей, которая хранится централизованно на одном либо нескольких серверах; таким образом, при появлении нового сотрудника в офисе вам нужно будет всего лишь завести ему учетную запись на сервере и указать, на какие рабочие станции он сможет получать доступ;
  • поскольку все ресурсы домена индексируются, это дает возможность простого и быстрого поиска для пользователей; например, если нужно найти цветной принтер в отделе;
  • совокупность применения разрешений NTFS, групповых политик и делегирования управления позволит вам тонко настроить и распределить права между участниками домена;
  • перемещаемые профили пользователей дают возможность хранить важную информацию и настройки конфигурации на сервере; фактически, если пользователь, обладающий перемещаемым профилем в домене, сядет работать за другой компьютер и введет свои имя пользователя и пароль, он увидит свой рабочий стол с привычными ему настройками;
  • с помощью групповых политик вы можете изменять настройки операционных систем пользователей, от разрешения пользователю устанавливать обои на рабочем столе до настроек безопасности, а также распространять по сети программное обеспечение, например, Volume Shadow Copy client и т. п.;
  • многие программы (прокси-серверы, серверы баз данныхи др.) не только производства Microsoft на сегодняшний день научились использовать доменную аутентификацию, таким образом, вам не придется создавать еще одну базу данных пользователей, а можно будет использовать уже существующую;
  • использование Remote Installation Services облегчает установку систем на рабочие места, но, в свою очередь, работает только при внедренной службе каталогов.

И Это далеко не полный список возможностей, но об этом позже. Сейчас я постараюсь расскажу саму логику построения Active Directory , но опять стоит выяснить из чего-же из чего-же сделаны наши мальчишьки строится Active Directory - это Домены, Деревья, Леса, Организационные единицы, Группы пользователей и компьютеров.

Домены - Это основная логическая единица построения. В сравнении с рабочими группами домены 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 2136). Каждый домен имеет хотя бы один контроллер домена, на котором располагается центральная база данных.

Деревья - Это многодоменные структуры. Корнем такой структуры является главный домен, для которого вы создаете дочерние. Фактически Active Directory использует иерархическую систему построения, аналогичную структуре доменов в DNS.

Если мы имеем домен work.com (домен первого уровня) и создаем для него два дочерних домена first.work.com и second.work.com (здесь first и second – это домены второго уровня, а не компьютер в домене, как в случае, описанном выше), то в итоге получим дерево доменов.

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

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) не в вашем управлении, в этом случае вы можете организовать лес, выбрав один из доменов первого уровня корневым. Вся прелесть создания леса в этом случае – двухсторонние доверительные отношения между двумя этими доменами и их дочерними доменами.

Однако при работе с лесами и деревьями необходимо помнить следующее:

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

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

Попросту говоря, Можно назначить администратора в домене, который сможет управлять OU, но не иметь прав для администрирования всего домена.

Важной особенностью OU в отличие от групп является возможность применения к ним групповых политик. «А почему нельзя разбить исходный домен на несколько доменов вместо использования OU?» – спросите вы.

Многие специалисты советуют иметь по возможности один домен. Причина этому – децентрализация администрирования при создании дополнительного домена, так как администраторы каждого такого домена получают неограниченный контроль (напомню, что при делегировании прав администраторам OU можно ограничивать их функционал).

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

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

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

Если вы имеете несколько филиалов в разных концах страны, соединенных низкоскоростными линиями связи, то для каждого филиала вы можете создать свой сайт. Делается это для повышения надежности репликации каталога.

Такое разбиение AD не влияет на принципы логического построения, поэтому как сайт может содержать в себе несколько доменов, так и наоборот, домен может содержать несколько сайтов. Но такая топология службы каталогов таит в себе подвох. Как правило, для связи с филиалами используется Интернет – очень небезопасная среда. Многие компании используют средства защиты, например, брандмауэры. Служба каталогов в своей работе использует около полутора десятков портов и служб, открытие которых для прохождения трафика AD через брандмауэр, фактически выставит ее «наружу». Решением проблемы является использование технологии туннелирования, а также наличие в каждом сайте контроллера домена для ускорения обработки запросов клиентов AD.

Представлена логика вложенности составляющих службы каталогов. Видно, что лес содержит два дерева доменов, в которых корневой домен дерева, в свою очередь, может содержать OU и группы объектов, а также иметь дочерние домены (в данном случае их по одному у каждого). Дочерние домены также могут содержать группы объектов и OU и иметь дочерние домены (на рисунке их нет). И так далее. Напомню, что OU могут содержать OU, объекты и группы объектов, а группы могут содержать другие группы.

Группы пользователей и компьютеров - используются для административных целей и имеют такой же смысл, как и при использовании на локальных машинах в сети. В отличие от OU, к группам нельзя применять групповые политики, но для них можно делегировать управление. В рамках схемы Active Directory выделяют два вида групп: группы безопасности (применяются для разграничения прав доступа к объектам сети) и группы распространения (применяются в основном для рассылки почтовых сообщений, например, в сервере Microsoft Exchange Server).

Они подразделяются по области действия:

  • универсальные группы могут включать в себя пользователей в рамках леса, а также другие универсальные группы или глобальные группы любого домена в лесу
  • глобальные группы домена могут включать в себя пользователей домена и другие глобальные группы этого же домена
  • локальные группы домена используются для разграничения прав доступа, могут включать в себя пользователей домена, а также универсальные группы и глобальные группы любого домена в лесу
  • локальные группы компьютеров – группы, которые содержит SAM (security account manager) локальной машины. Область их распространения ограничивается только данной машиной, но они могут включать в себя локальные группы домена, в котором находится компьютер, а также универсальные и глобальные группы своего домена или другого, которому они доверяют. Например, вы можете включить пользователя из доменной локальной группы Users в группу Administrators локальной машины, тем самым дав ему права администратора, но только для этого компьютера

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

Давайте посмотрим с другой стороны. Любой руководитель должен понимать, что у него сейчас происходит в компании (в том числе и в ИТ). Это необходимо для отслеживания текущей ситуации, для оперативного реагирования на возникновение разного рода проблем. Но это понимание является более важным для стратегического планирования. Ведь, имея крепкий и надежный фундамент, мы можем строить дом на 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 являются сердцем ИТ-инфраструктуры предприятия. В случае отказа вся сеть, все сервера, работа всех пользователей будут парализованы. Никто не сможет войти в компьютер, получить доступ к своим документам и приложениям. Поэтому служба каталогов должна быть тщательно спроектирована и развёрнута, с учётом всех возможных нюансов, например, пропускной способности каналов между филиалами или офисами компании (от этого напрямую зависит скорость входа пользователей в систему, а также обмен данными между контроллерами домена).

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

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

Active Directory - это очень удобный способ системного управления. С помощью Active Directory можно эффективно управлять данными.

Указанные службы позволяют создать единую базу данных под управлением контроллеров домена. Если вы владеете предприятием, руководите офисом, в общем, контролируете деятельность множества людей, которых нужно объединить, вам пригодится такой домен.

В него включаются все объекты - компьютеры, принтеры, факсы, учётные записи пользователей и прочее. Сумма доменов, на которых расположены данные, именуется «лесом». База Active Directory - это доменная среда, где количество объектов может составлять до 2 миллиардов. Представляете эти масштабы?

То есть, при помощи такого «леса» или базы данных можно соединить большое количество сотрудников и оборудования в офисе, причём без привязки к месту - в службах могут быть соединены и другие юзеры, например, из офиса компании в другом городе.

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

Далее, при создании такой сети определяется один контролирующий домен, и даже при последующем наличии других доменов первоначальный по-прежнему остаётся «родительским» - то есть только он имеет полный доступ к управлению информацией.

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

Ещё один вариант использования базы - если, например, ваша компания сотрудничает с другой, и вам предстоит выполнить общий проект. В таком случае может потребоваться доступ посторонних личностей к файлам домена, и здесь можно настроить своего рода «отношения» между двумя разными «лесами», открыть доступ к требуемой информации, не рискуя безопасностью остальных данных.

В общем, Active Directory является средством для создания базы данных в рамках определённой структуры, независимо от её размеров. Пользователи и вся техника объединяются в один «лес», создаются домены, которые размещаются на контроллерах.

Ещё целесообразно уточнить - работа служб возможна исключительно на устройствах с серверными системами Windows. Помимо этого, на контроллерах создаётся 3-4 сервера DNS. Они обслуживают основную зону домена, а в случае, когда один из них выходит из строя, его заменяют прочие серверы.

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

Преимущества Active Directory

Плюсы Active Directory следующие:

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

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

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

Что касается определённого порядка в ведении записей, вы всегда можете поделить юзеров на группы - «Отдел кадров» или «Бухгалтерия».

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

  1. Контроль над каждым участником базы данных.

Если в локальной группе каждый участник независим, его трудно контролировать с другого компьютера, то в доменах можно установить определённые правила, соответствующие политике компании.

Вы как системный администратор можете задать настройки доступа и параметры безопасности, а после применить их для каждой группы пользователей. Естественно, в зависимости от иерархии, одним группам можно определить более жёсткие настройки, другим предоставить доступ к иным файлам и действиям в системе.

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

  1. Универсальность в установке программного обеспечения.

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

А если на фирме эксплуатируется отдельная утилита или специальные службы, их можно синхронизировать с доменами и упростить к ним доступ. Каким образом? Если объединить все продукты, использующиеся в компании, сотруднику не нужно будет вводить разные логины и пароли для входа в каждую программу - эти сведения будут общими.

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

Используем базу данных на Windows Server 2012

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

Чтобы загрузить службы, для начала необходимо выполнить следующее:

  1. Поменять название компьютера: нажмите на «Пуск», откройте Панель управления, пункт «Система». Выберите «Изменить параметры» и в Свойствах напротив строки «Имя компьютера» кликните «Изменить», впишите новое значение для главного ПК.
  2. Выполните перезагрузку по требованию ПК.
  3. Задайте настройки сети так:
    • Через панель управления откройте меню с сетями и общим доступом.
    • Откорректируйте настройки адаптера. Правой клавишей нажмите «Свойства» и откройте вкладку «Сеть».
    • В окне из списка кликните на протокол интернета под номером 4, опять нажмите на «Свойства».
    • Впишите требуемые настройки, например: IP-адрес - 192.168.10.252 , маска подсети - 255.255.255.0, основной подшлюз - 192.168.10.1.
    • В строке «Предпочтительный DNS-сервер» укажите адрес локального сервера, в «Альтернативном…» - другие адреса DNS-серверов.
    • Сохраните изменения и закройте окна.

Установите роли Active Directory так:

  1. Через пуск откройте «Диспетчер сервера».
  2. В меню выберите добавление ролей и компонентов.
  3. Запустится мастер, но первое окно с описанием можно пропустить.
  4. Отметьте строку «Установка ролей и компонентов», перейдите дальше.
  5. Выберите ваш компьютер, чтобы поставить на него Active Directory.
  6. Из списка отметьте роль, которую нужно загрузить - для вашего случая это «Доменные службы Active Directory».
  7. Появится небольшое окно с предложением загрузки необходимых для служб компонентов - примите его.
  8. После вам предложат установить другие компоненты - если они вам не нужны, просто пропустите этот шаг, нажав«Далее».
  9. Мастер настройки выведет окно с описаниями устанавливаемых вами служб - прочтите и двигайтесь дальше.
  10. Появиться перечень компонентов, которые мы собираемся установить - проверьте, всё ли верно, и если да, жмите на соответствующую клавишу.
  11. По завершении процесса закройте окно.
  12. Вот и всё - службы загружены на ваш компьютер.

Настройка Active Directory

Для настройки доменной службы вам нужно сделать следующее:

  • Запустите одноимённый мастер настройки.
  • Кликните на жёлтый указатель вверху окна и выберите «Повысить роль сервера до уровня контроллера домена».
  • Нажмите на добавление нового «леса» и создайте имя для корневого домена, затем кликните «Далее».
  • Укажите режимы работы «леса» и домена - чаще всего они совпадают.
  • Придумайте пароль, но обязательно запомните его. Перейдите далее.
  • После этого вы можете увидеть предупреждение о том, что домен не делегирован, и предложение проверить имя домена - можете пропустить эти шаги.
  • В следующем окне можно изменить путь к каталогам с базами данных - сделайте это, если они вам не подходят.
  • Теперь вы увидите все параметры, которые собираетесь установить - просмотрите, правильно ли выбрали их, и идите дальше.
  • Приложение проверит, выполняются ли предварительные требования, и если замечаний нет, или они некритичны, жмите «Установить».
  • После окончания инсталляции ПК самостоятельно перегрузиться.

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

Чтобы добавить нового юзера, нажмите правой клавишей по названию домена, выберите «Создать», после «Подразделение». Перед вами появится окно, где нужно ввести имя нового подразделения - оно служит папкой, куда вы можете собирать пользователей по разным отделам. Таким же образом вы позже создадите ещё несколько подразделений и грамотно разместите всех сотрудников.

Далее, когда вы создали имя подразделения, нажмите на него правой клавишей мыши и выберите «Создать», после - «Пользователь». Теперь осталось только ввести необходимые данные и поставить настройки доступа для юзера.

Когда новый профиль будет создан, нажмите на него, выбрав контекстное меню, и откройте «Свойства». Во вкладке «Учётная запись» удалите отметку напротив «Заблокировать…». На этом всё.

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



В 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 таким образом, чтобы вам не приходилось заполнять поле «Description». Например, из названия группы GPCP_Restricted_Groups понятно, что это группа для политики, которая применяется для компьютеров и выполняет работу механизма Restricted Groups.
Ваш подход к написанию документации должен быть очень основательным, это позволит сэкономить большое количество времени в дальнейшем.

Упрощайте все, что возможно, старайтесь достигнуть равновесия
При построении 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).
Поле Surname обоих типов административных аккаунтов следует начинать с буквы I (Например, iPetrov P Vasily)
Поясню, зачем следует разделять административные аккаунты на администраторов серверов и администраторов клиентских компьютеров. Делать это необходимо, из соображений безопасности. Администраторы клиентских компьютеров будут иметь право на установку софта на клиентских компьютерах. Какой и для чего софт будет устанавливаться, сказать никогда точно нельзя. Поэтому запускать установку программы с правами доменного администратора небезопасно, можно скомпрометировать весь домен. Необходимо администрировать клиентские компьютеры только с правами локального администратора данного компьютера. Это сделает невозможным целый ряд атак на аккаунты доменных администраторов, вроде «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
Аудит необходимо конфиругировать в разделе Advanced Audit Policy Configuration и обязательно включить настройку в разделел Local Policy/Security Options - Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings , которая отменит настройки верхнего уровня и применит расширенные.

Расширенные настройки аудита

Подробно останавливаться на настройках аудита не буду, так как в Сети есть достаточное количество статей, посвященных данной теме. Дополню только, что помимо включения аудита, следует настроить оповещения по 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.
Всем мира и добра!

Вы можете помочь и перевести немного средств на развитие сайта

Загрузка...
Top