Контроллер домена — Domain controller

A контроллер домена (DC) — это серверный компьютер , который отвечает на запросы аутентификации безопасности внутри компьютера сетевой домен . Это сервер в сети , который отвечает за предоставление хосту доступа к ресурсам домена. Он аутентифицирует пользователей, хранит информацию об учетных записях пользователей и применяет политику безопасности для домена. Чаще всего он реализуется в средах Microsoft Windows (см. Контроллер домена (Windows) ), где он является центральным элементом службы Windows Active Directory . Однако контроллеры домена, отличные от Windows, могут быть установлены с помощью программного обеспечения управления идентификацией , такого как Samba и Red Hat FreeIPA .

Содержание

Программное обеспечение

Программное обеспечение и операционная система, используемые для запуска контроллера домена, обычно состоят из нескольких ключевых компонентов, общих для платформ . Сюда входят операционная система (обычно Windows Server или Linux ), служба LDAP (Red Hat Directory Server и т. Д.), служба сетевого времени (ntpd , chrony и т. д.) и протокол аутентификации компьютерной сети (обычно Kerberos . Другие компоненты, такие как инфраструктура открытого ключа (Службы сертификации Active Directory, DogTag , OpenSSL ) служба и Система доменных имен (Windows DNS или BIND ) также могут быть включены в на том же сервере или на другом сервере, присоединенном к домену.

Реализация

Контроллеры домена обычно развертываются как кластер для обеспечения высокой доступности и максимальной надежности. В Windows В среде один контроллер домена выполняет роль основного контроллера домена (PDC), а все другие серверы повышаются до статуса контроллера домена на сервере домена в качестве резервного контроллера домена (BDC). В средах на основе Unix одна машина служит главным контроллером домена и другие служат реплики контроллеров домена, периодически реплицируя информацию базы данных с главного контроллера домена и сохраняя ее в формате только для чтения.

Контроллер домена (Windows) — Domain controller (Windows)

На Microsoft Servers , a контроллер домена (DC) — это серверный компьютер , который отвечает на запросы аутентификации безопасности (вход в систему и т. Д.) В пределах домена Windows . Домен — это концепция, представленная в Windows NT , посредством которой пользователю может быть предоставлен доступ к ряду компьютерных ресурсов с использованием единой комбинации имени пользователя и пароля.

Содержание

История

В Windows NT 4 Server один контроллер домена на домен был настроен как основной контроллер домена (PDC); все остальные контроллеры домена были резервными контроллерами домена (BDC).

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

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

Windows 2000 и более поздние версии представили Active Directory («AD»), который в значительной степени устранил концепцию PDC и BDC в пользу репликации с несколькими мастерами . Однако по-прежнему существует несколько ролей, которые может выполнять только один контроллер домена, которые называются ролями гибкой единственной главной операции . Некоторые из этих ролей должны быть заполнены одним контроллером домена на домен, в то время как для других требуется только один контроллер домена на лес AD . Если сервер, выполняющий одну из этих ролей, потерян, домен все еще может функционировать, и если сервер снова не будет доступен, администратор может назначить альтернативный DC, который возьмет на себя роль в процессе, известном как «захват» роли.

Основной контроллер домена

В Windows NT 4 один контроллер домена служит основным контроллером домена (PDC). Другие, если они существуют, обычно являются резервным контроллером домена (BDC). PDC обычно обозначается как «первый». «Менеджер пользователей для доменов» — это утилита для хранения информации о пользователях / группах. Он использует базу данных безопасности домена на первичном контроллере. PDC имеет главную копию базы данных учетных записей пользователей, к которой он может получить доступ и изменить. На компьютерах BDC есть копия этой базы данных, но эти копии доступны только для чтения. PDC будет регулярно реплицировать свою базу данных учетных записей на BDC. BDC существуют для обеспечения резервного копирования PDC, а также могут использоваться для аутентификации пользователей, входящих в сеть. В случае отказа PDC один из BDC может быть назначен на его место. PDC обычно будет первым контроллером домена, который был создан, если он не был заменен повышенным BDC.

Эмуляция PDC (основной контроллер домена)

В современных выпусках Windows домены были дополнены использованием служб Active Directory . В доменах Active Directory концепция отношений между первичным и вторичным контроллерами домена больше не применяется. Эмуляторы PDC содержат базы данных учетных записей и инструменты администрирования. В результате большая рабочая нагрузка может замедлить работу системы. Служба DNS может быть установлена ​​на вторичном компьютере-эмуляторе, чтобы снизить нагрузку на эмулятор PDC. Применяются те же правила; в домене может существовать только один основной контроллер домена, но можно использовать несколько серверов репликации.

• Мастер-эмулятор основного контроллера домена действует вместо основного контроллера домена, если в пределах контроллеров домена (BDC) Windows NT 4.0 остаются домен, выступающий в качестве источника для их репликации.
• Главный эмулятор PDC получает преимущественную репликацию изменений пароля внутри домена. Поскольку изменение пароля требует времени для репликации на всех контроллерах домена в домене Active Directory, главный эмулятор PDC получает уведомление об изменении пароля немедленно, и если попытка входа в систему не удалась на другом контроллере домена, этот контроллер домена перенаправит запрос входа в систему. Мастер-эмулятор PDC, прежде чем отклонить его.
• Мастер-эмулятор PDC также служит машиной, с которой все контроллеры домена в домене будут синхронизировать свои часы. Он, в свою очередь, должен быть настроен для синхронизации с внешним источником времени NTP .

Samba

Первичные контроллеры домена (PDC) были точно воссозданы на Samba эмуляция клиент-серверной системы Microsoft SMB . Samba имеет возможность эмулировать домен NT 4.0, а также современные доменные службы Active Directory на компьютере Linux.

Резервный контроллер домена

В доменах Windows NT 4 резервный контроллер домена (BDC) — это компьютер, на котором есть копия базы данных учетных записей пользователей. В отличие от базы данных учетных записей на PDC, база данных BDC является копией только для чтения. Когда изменения вносятся в базу данных основных учетных записей на PDC, PDC отправляет обновления на BDC. Эти дополнительные контроллеры домена существуют для обеспечения отказоустойчивости. Если PDC выходит из строя, его можно заменить на BDC. В таких обстоятельствах администратор продвигает BDC в качестве нового PDC. BDC также могут аутентифицировать запросы пользователей на вход в систему и брать на себя часть аутентификационной нагрузки с PDC.

Когда была выпущена Windows 2000 , домен NT, обнаруженный в NT 4 и предыдущих версиях, был заменен на Active Directory . В доменах Active Directory, работающих в основном режиме, концепции PDC и BDC не существуют. В этих доменах все контроллеры домена считаются равными. Побочным эффектом этого изменения является потеря возможности создания контроллера домена «только для чтения». Windows Server 2008 повторно представила эту возможность.

Номенклатура

Windows Server может быть одного из трех типов: «контроллеры домена» Active Directory (те, которые обеспечивают идентификацию и аутентификацию), «рядовые серверы» Active Directory (те, которые предоставляют дополнительные услуги, такие как как файловые репозитории и схемы) и Windows Workgroup «автономные серверы». Термин «Сервер Active Directory» иногда используется Microsoft как синоним «Контроллера домена», но этот термин не приветствуется.

Что такое контроллер домена, когда он нужен и как его настроить?

Я хотел бы знать, что мы подразумеваем под контроллером домена и как сделать систему контроллером домена и когда нам нужно сделать систему DC?

Проще говоря, «домен» — это унифицированный набор компьютеров и учетных записей пользователей, управляемых серверными машинами, обозначенными как «контроллеры домена». (Это, конечно, неполное определение, но это хорошее начало.) Контроллер домена — это компьютер, на котором установлена ​​одна из серверных операционных систем Microsoft, например Windows Server 2008 или Windows Server 2008 R2 в любом выпуске, кроме Web Edition, или один из ориентированных на малый бизнес серверных продуктов, для которого были выполнены следующие действия:

• Роль сервера доменных служб Active Directory (ADDS) включена.
• Сервер был «продвинут» как контроллер домена для вашей организации.

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

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

Создание домена Active Directory не следует воспринимать легкомысленно. Это имеет долгосрочные последствия для повседневной работы пользователей вашей организации. Пожалуйста, внимательно изучите проблему или подумайте о найме консультанта, прежде чем принять решение о создании домена AD в вашей организации.

Прежде всего, домен — это набор взаимосвязанных ресурсов на платформе Windows, таких как принтеры, приложения и т. Д.) Для группы пользователей. Пользователям, которые являются частью домена (которым для входа в домен назначаются имена пользователей и пароли), предоставляются особые разрешения на доступ к ресурсам, которые могут находиться на одном или нескольких серверах в сети.

Другими словами, домен — это логическая группа компьютеров, которые совместно используют центральную базу данных, которая называется Active Directory (AD). База данных содержит информацию о безопасности пользователя и учетных записях для ресурсов в этом домене. Любой человек, который использует компьютеры в домене, получает свою учетную запись, которой назначается доступ к ресурсам в этом домене.

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

Контроллер домена является отличным инструментом для системных администраторов, поскольку он позволяет им предоставлять или запрещать пользователям доступ к общесистемным ресурсам, таким как принтеры, документы, папки, сетевые папки и т. Д., Через одно имя пользователя и пароль. Как только контроллер домена настроен в компании, офисе или здании, он принимает на себя ответственность за ответы на запросы пользователей по аутентификации безопасности, такие как проверка разрешений, вход в систему и т. Д.

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

Контроллер домена предоставляет сервисы аутентификации для сети компьютеров Windows. См. Статью Wikipedia для краткого введения. Если вам нужно создать его, вы можете сделать это с сервером Windows (любой из множества разновидностей, например, Windows 2003 Server) или запустить Samba на Linux. Я бы порекомендовал последний подход, и если вам нужен совет, какой дистрибутив Linux использовать, я бы порекомендовал Ubuntu .

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

• Главная
• Active Directory — от теории к практике. Часть 1 — общие вопросы.

Active Directory — от теории к практике. Часть 1 — общие вопросы.

В наших прошлых материалах мы разобрали общие вопросы касающиеся служб каталогов и 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 репликация происходит однонаправленно.

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

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал: