Это Канонический вопрос о доменных службах Active Directory (AD DS).
Что такое Active Directory? Что он делает и как работает?
Как организована Active Directory: лес, дочерний домен, дерево, сайт или подразделение
Я ловлю себя на том, что почти ежедневно объясняю некоторые из того, что я считаю общеизвестным. Надеемся, что этот вопрос послужит каноническим вопросом и ответом на большинство основных вопросов об Active Directory. Если вы чувствуете, что можете улучшить ответ на этот вопрос, отредактируйте его.
Доменные службы Active Directory - это сервер каталогов Microsoft. Он предоставляет механизмы аутентификации и авторизации, а также структуру, в которой могут быть развернуты другие связанные службы (службы сертификации AD, федеративные службы AD и т. Д.). Это LDAP совместимая база данных, содержащая объекты. Наиболее часто используемые объекты - это пользователи, компьютеры и группы. Эти объекты могут быть организованы в организационные единицы (OU) в соответствии с любым количеством логических или бизнес-потребностей. Объекты групповой политики (GPO) затем можно связать с подразделениями, чтобы централизовать настройки для различных пользователей или компьютеров в организации.
Когда люди говорят «Active Directory», они обычно имеют в виду «доменные службы Active Directory». Важно отметить, что существуют другие роли / продукты Active Directory, такие как службы сертификации, службы федерации, службы облегченного доступа к каталогам, службы управления правами и т. Д. Этот ответ относится конкретно к доменным службам Active Directory.
Лес - это граница безопасности. Объекты в отдельных лесах не могут взаимодействовать друг с другом, если администраторы каждого отдельного леса не создают доверять между ними. Например, учетная запись администратора предприятия для domain1.com, которая обычно является самой привилегированной учетной записью в лесу, не будет иметь никаких разрешений во втором лесу с именем domain2.com, даже если эти леса существуют в одной локальной сети, если нет доверия.
Если у вас есть несколько несвязанных бизнес-единиц или вам нужны отдельные границы безопасности, вам понадобится несколько лесов.
Домен - это граница управления. Домены являются частью леса. Первый домен в лесу известен как корневой домен леса. Во многих малых и средних организациях (и даже в некоторых крупных) вы найдете только один домен в одном лесу. Корневой домен леса определяет пространство имен по умолчанию для леса. Например, если первый домен в новом лесу назван domain1.com, то это корневой домен леса. Если у вас есть бизнес-потребность в дочернем домене, например, в филиале в Чикаго, вы можете назвать дочерний домен chi. В FQDN дочернего домена будет chi.domain1.com. Вы можете видеть, что имя дочернего домена было добавлено к имени корневого домена леса. Обычно это так и работает. В одном лесу могут быть непересекающиеся пространства имен, но это целая отдельная банка червей для разного времени.
В большинстве случаев вы захотите попробовать и сделать все возможное, чтобы иметь один домен AD. Это упрощает управление, а современные версии AD позволяют очень легко делегировать управление на основе OU, что снижает потребность в дочерних доменах.
На самом деле, нет. dcpromo.exe, инструмент, который продвигает сервер в DC, не защищен от идиотов. Это действительно позволяет вам принимать неправильные решения при именовании, поэтому обратите внимание на этот раздел, если вы не уверены. (Редактировать: dcpromo устарел в Server 2012. Используйте Install-ADDSForest Командлет PowerShell или установите AD DS из диспетчера сервера.)
Прежде всего, не используйте выдуманные TLD, такие как .local, .lan, .corp, или любую другую чушь. Эти TLD не зарезервированный. ICANN сейчас продает TLD, так что ваша mycompany.corp то, что вы используете сегодня, может действительно принадлежать кому-то завтра. Если у вас есть mycompany.com, то разумнее всего использовать что-нибудь вроде internal.mycompany.com или ad.mycompany.com для вашего внутреннего имени AD. Если вы используете mycompany.com поскольку веб-сайт с внешним разрешением, вам следует избегать использования этого имени в качестве внутреннего имени AD, поскольку в итоге вы получите разделенный DNS.
Сервер, который отвечает на запросы аутентификации или авторизации, является контроллером домена (DC). В большинстве случаев контроллер домена будет хранить копию Глобальный каталог. Глобальный каталог (GC) - это частичный набор объектов в все домены в лесу. Он доступен для прямого поиска, что означает, что междоменные запросы обычно могут выполняться на GC без необходимости обращения к DC в целевом домене. Если DC запрашивается через порт 3268 (3269 при использовании SSL), то запрашивается GC. Если запрашивается порт 389 (636 при использовании SSL), то используется стандартный запрос LDAP, и для объектов, существующих в других доменах, может потребоваться направления.
Когда пользователь пытается войти в компьютер, который присоединен к AD, используя свои учетные данные AD, объединенное и хешированное сочетание имени пользователя и пароля отправляется на контроллер домена как для учетной записи пользователя, так и для учетной записи компьютера, на котором выполняется вход. Да, компьютер тоже входит в систему. Это важно, потому что если что-то произойдет с учетной записью компьютера в AD, например, кто-то сбрасывает учетную запись или удаляет ее, вы можете получить сообщение об ошибке, в котором говорится, что между компьютером и доменом не существует доверительных отношений. Несмотря на то, что ваши сетевые учетные данные в порядке, компьютеру больше не доверяют для входа в домен.
Я слышу «У меня есть основной контроллер домена (PDC) и хочу установить резервный контроллер домена (BDC)» гораздо чаще, чем мне хотелось бы верить. Концепция PDC и BDC умерла с Windows NT4. Последним бастионом для PDC была AD в переходном смешанном режиме Windows 2000, когда у вас еще были контроллеры домена NT4. По сути, если вы не поддерживаете установку 15+ летней давности, которая никогда не обновлялась, у вас действительно нет PDC или BDC, у вас просто два контроллера домена.
Несколько контроллеров домена могут одновременно отвечать на запросы аутентификации от разных пользователей и компьютеров. Если один выйдет из строя, остальные продолжат предлагать услуги аутентификации без необходимости делать одну «первичной», как вам пришлось бы делать во времена NT4. Лучше всего иметь по крайней мере два DC на домен. Эти контроллеры домена должны содержать копию GC и оба должны быть DNS-серверами, которые также должны содержать копию интегрированных DNS-зон Active Directory для вашего домена.
«Итак, если нет основных контроллеров домена, почему существует роль основного контроллера домена, которую может выполнять только один контроллер домена?»
Я часто это слышу. Eсть Эмулятор PDC роль. Это отличается от того, чтобы быть PDC. На самом деле есть 5 гибких ролей с одним главным оператором (FSMO). Их также называют ролями мастера операций. Эти два термина взаимозаменяемы. Что они собой представляют и чем занимаются? Хороший вопрос! 5 ролей и их функции:
Мастер именования доменов - В каждом лесу есть только один мастер именования доменов. Мастер именования доменов гарантирует, что при добавлении нового домена в лес он будет уникальным. Если сервер, выполняющий эту роль, отключен, вы не сможете вносить изменения в пространство имен AD, включая такие вещи, как добавление новых дочерних доменов.
Мастер схемы - В лесу есть только один Мастер операций схемы. Он отвечает за обновление схемы Active Directory. Задачи, для которых это требуется, такие как подготовка AD к новой версии Windows Server, работающей как контроллер домена, или установка Exchange, требуют изменения схемы. Эти изменения должны выполняться мастером схемы.
Мастер инфраструктуры - На каждый домен приходится один хозяин инфраструктуры. Если в вашем лесу только один домен, вам не о чем беспокоиться. Если у вас несколько лесов, убедитесь, что эта роль не удерживается сервером, который также является держателем GC, если каждый DC в лесу не является GC. Хозяин инфраструктуры отвечает за правильную обработку междоменных ссылок. Если пользователь в одном домене добавляется в группу в другом домене, хозяин инфраструктуры для рассматриваемых доменов проверяет, правильно ли обрабатывается. Эта роль не будет работать правильно, если она находится в глобальном каталоге.
RID Мастер - Мастер относительного идентификатора (мастер RID) отвечает за выдачу пулов RID контроллерам домена. На каждый домен приходится один мастер RID. Любой объект в домене AD имеет уникальный Идентификатор безопасности (SID). Он состоит из комбинации идентификатора домена и относительного идентификатора. Каждый объект в данном домене имеет один и тот же идентификатор домена, поэтому относительный идентификатор делает объекты уникальными. У каждого контроллера домена есть пул относительных идентификаторов для использования, поэтому, когда этот контроллер домена создает новый объект, он добавляет RID, который еще не использовался. Поскольку контроллерам домена выдаются неперекрывающиеся пулы, каждый RID должен оставаться уникальным в течение всего срока существования домена. Когда в пуле контроллера домена остается ~ 100 RID, он запрашивает новый пул у мастера RID. Если мастер RID отключен в течение длительного периода времени, создание объекта может завершиться ошибкой.
Эмулятор PDC - Наконец, мы подошли к наиболее часто неправильно понимаемой роли из них всех - роли эмулятора PDC. На каждый домен приходится один эмулятор PDC. Если есть неудачная попытка аутентификации, она пересылается эмулятору PDC. Эмулятор основного контроллера домена функционирует как «средство разрешения конфликтов», если пароль был обновлен на одном контроллере домена и еще не реплицирован на другие. Эмулятор PDC также является сервером, который управляет синхронизацией времени в домене. Все остальные контроллеры домена синхронизируют свое время с эмулятором PDC. Все клиенты синхронизируют свое время с контроллером домена, в который они вошли. Важно, чтобы все оставалось в пределах 5 минут друг от друга, иначе Kerberos сломается, и когда это произойдет, все заплачут.
Важно помнить, что серверы, на которых работают эти роли, не высечены из камня. Обычно перемещать эти роли тривиально, поэтому, хотя некоторые DC делают немного больше, чем другие, если они выходят из строя на короткие периоды времени, обычно все будет нормально работать. Если они не работают на долгое время, легко прозрачно передать роли. Это намного лучше, чем во времена NT4 PDC / BDC, поэтому, пожалуйста, перестаньте называть свои контроллеры домена этими старыми именами. :)
Репликация, конечно. По умолчанию контроллеры домена, принадлежащие к одному домену на одном сайте, будут реплицировать свои данные друг другу с интервалом в 15 секунд. Это гарантирует, что все относительно актуально.
Есть некоторые «срочные» события, запускающие немедленную репликацию. Это следующие события: учетная запись заблокирована из-за слишком большого количества неудачных попыток входа, изменение пароля домена или политики блокировки, изменение секрета LSA, изменение пароля учетной записи компьютера контроллера домена или передача роли RID Master в новый DC. Любое из этих событий вызовет немедленное событие репликации.
Изменения пароля находятся где-то между срочными и несрочными и обрабатываются однозначно. Если пароль пользователя изменен на DC01 и пользователь пытается войти в компьютер, который аутентифицируется против DC02 до того, как произойдет репликация, вы ожидаете, что это не удастся, верно? К счастью, этого не происходит. Предположим, что здесь есть еще третий DC, называемый DC03 который выполняет роль эмулятора PDC. когда DC01 обновляется новым паролем пользователя, это изменение немедленно реплицируется на DC03 также. При попытке аутентификации DC02 терпит неудачу, DC02 затем пересылает эту попытку аутентификации на DC03, который подтверждает, что это действительно нормально, и вход в систему разрешен.
DNS имеет решающее значение для правильного функционирования AD. Официальная линия Microsoft состоит в том, что любой DNS-сервер можно использовать, если он правильно настроен. Если вы попытаетесь использовать BIND для размещения своих AD-зон, вы под кайфом. Шутки в сторону. Придерживайтесь использования зон AD Integrated DNS и при необходимости используйте условные или глобальные серверы пересылки для других зон. Все ваши клиенты должны быть настроены для использования ваших DNS-серверов AD, поэтому здесь важно иметь избыточность. Если у вас два контроллера домена, попросите их запустить DNS и настройте клиентов на использование обоих для разрешения имен.
Кроме того, вы захотите убедиться, что если у вас более одного DC, они не перечисляют себя первыми для разрешения DNS. Это может привести к ситуации, когда они "остров репликации" где они отключены от остальной топологии репликации AD и не могут быть восстановлены. Если у вас два сервера DC01 - 10.1.1.1 и DC02 - 10.1.1.2, то их список DNS-серверов должен быть настроен следующим образом:
Сервер: DC01 (10.1.1.1)
Первичный DNS - 10.1.1.2
Вторичный DNS - 127.0.0.1Сервер: DC02 (10.1.1.2)
Первичный DNS - 10.1.1.1
Вторичный DNS - 127.0.0.1
Потому что, как только вы знаете, что делаете, ваша жизнь становится бесконечно лучше. AD позволяет централизовать управление пользователями и компьютерами, а также централизовать доступ к ресурсам и их использование. Представьте себе ситуацию, когда у вас в офисе 50 пользователей. Если вы хотите, чтобы у каждого пользователя была собственная учетная запись на каждом компьютере, вам нужно будет настроить 50 локальных учетных записей на каждом ПК. В AD вам нужно только один раз создать учетную запись пользователя, и по умолчанию она может войти на любой компьютер в домене. Если вы хотите усилить безопасность, вам придется сделать это 50 раз. Что-то вроде кошмара, правда? Также представьте, что у вас есть файловый ресурс, к которому вы хотите получить доступ только половине этих людей. Если вы не используете AD, вам придется либо вручную реплицировать их имя пользователя и пароли на сервере, чтобы получить беспрепятственный доступ, либо вам придется создать общую учетную запись и дать каждому пользователю имя пользователя и пароль. Один способ означает, что вы знаете (и должны постоянно обновлять) пароли пользователей. Другой способ означает, что у вас нет контрольного журнала. Не хорошо, правда?
Вы также получаете возможность использовать групповую политику, когда у вас настроена AD. Групповая политика - это набор объектов, связанных с подразделениями, которые определяют параметры для пользователей и / или компьютеров в этих подразделениях. Например, если вы хотите сделать так, чтобы «Завершение работы» не было в меню «Пуск» для 500 лабораторных ПК, вы можете сделать это с помощью одного параметра в групповой политике. Вместо того, чтобы тратить часы или дни на настройку правильных записей реестра вручную, вы создаете объект групповой политики один раз, связываете его с правильным OU или OU и никогда не должны думать об этом снова. Существуют сотни объектов групповой политики, которые можно настроить, и гибкость групповой политики является одной из основных причин того, что Microsoft так доминирует на корпоративном рынке.
Примечание: Этот ответ был объединен с этим вопросом из другого вопроса, который спрашивал о различиях между лесами, дочерними доменами, деревьями, сайтами и OU. Изначально это не было написано как ответ на этот конкретный вопрос.
Вы хотите создать новый лес, когда вам нужна граница безопасности. Например, у вас может быть сеть периметра (DMZ), которой вы хотите управлять с помощью AD, но вы не хотите, чтобы ваш внутренний AD был доступен в сети периметра по соображениям безопасности. В этом случае вам нужно создать новый лес для этой зоны безопасности. Вы также можете захотеть этого разделения, если у вас есть несколько организаций, которые не доверяют друг другу - например, корпорация-оболочка, которая объединяет отдельные предприятия, которые работают независимо. В этом случае вы хотите, чтобы у каждой сущности был свой лес.
На самом деле, они вам больше не нужны. Есть несколько хороших примеров, когда вам нужен дочерний домен. Устаревшая причина заключается в различных требованиях к политике паролей, но это больше не действует, поскольку с Server 2008 доступны детальные политики паролей. На самом деле вам нужен только дочерний домен, если у вас есть области с невероятно плохим сетевым подключением, и вы хотите резко сократить трафик репликации - хорошим примером является круизное судно со спутниковым подключением к глобальной сети. В этом случае каждое круизное судно может быть собственным дочерним доменом, чтобы быть относительно автономным, но при этом иметь возможность использовать преимущества нахождения в том же лесу, что и другие домены той же компании.
Это странный шар. Новые деревья используются, когда вы хотите сохранить преимущества управления одним лесом, но иметь домен в новом пространстве имен DNS. Например corp.example.com может быть корнем леса, но вы могли бы ad.mdmarra.com в том же лесу с использованием нового дерева. Здесь действуют те же правила и рекомендации для дочерних доменов - используйте их экономно. В современных AD они обычно не нужны.
Сайт должен представлять физическую или логическую границу в вашей сети. Например, филиалы. Сайты используются для интеллектуального выбора партнеров по репликации для контроллеров домена в различных областях. Без определения сайтов все контроллеры домена будут обрабатываться так, как если бы они находились в одном физическом местоположении, и реплицироваться в топологии ячеистой сети. На практике большинство организаций логически настроены по принципу «ступица и луч», поэтому сайты и службы следует настраивать с учетом этого.
Другие приложения также используют Сайты и Сервисы. DFS использует его для ссылок на пространство имен и выбора партнера по репликации. Exchange и Outlook используют его для поиска «ближайшего» глобального каталога для запроса. Компьютеры, присоединенные к домену, используют его для определения «ближайшего» контроллера домена (ов) для аутентификации. Без этого ваш трафик репликации и аутентификации будет похож на Дикий Запад.
Они должны быть созданы таким образом, чтобы отражать потребность вашей организации в делегировании полномочий и применении групповой политики. Во многих организациях есть одно подразделение на сайт, потому что они применяют GPO таким образом - это глупо, потому что вы также можете применить GPO к сайту из сайтов и служб. Другие организации разделяют подразделения по отделам или функциям. Это имеет смысл для многих, но на самом деле дизайн OU должен соответствовать вашим потребностям и быть довольно гибким. Не существует «единственного способа» сделать это.
Многонациональная компания может иметь подразделения верхнего уровня North America, Europe, Asia, South America, Africa чтобы они могли делегировать административные привилегии в зависимости от континента. Другие организации могут иметь подразделения верхнего уровня Human Resources, Accounting, Salesи т. д., если это имеет для них больше смысла. Другие организации имеют минимальные потребности в политике и используют "плоский" макет, Employee Users и Employee Computers. Здесь действительно нет правильного ответа, это то, что отвечает потребностям вашей компании.