Сибирский ТАМ

Как сделать жизнь ИТ-систем без аварий с минимальным количеством персонала. Основные темы: сопровождение и приведение в порядок ИТ-систем, грамотная инфраструктура Microsoft, мониторинг и управление, немного о безопасности.

AD:Роли FSMO и самая важная роль контроллера домена

AD:Роли FSMO и самая важная роль контроллера домена

  • Comments 12
  • Likes

В фундаменте инфраструктуры Microsoft находится каталог Active Directory. Как и положено «становому хребту» каталог AD – это чертовски крепкая вещь. Также, это один из примеров «Next-Next-Next – работает!» продуктов, которые без дополнительного сопровождения работают годами. Но есть ряд мифов и неточностей, которые просто необходимо каждый раз обсуждать с администраторами, сопровождающими каталог AD.

Кто главнее?Сегодня я хочу поговорить о такой вещи как роли контроллеров домена. Многие знают, что они называются FSMO или мастера операций. Очень часто на собеседованиях спрашивают: «Какие существуют роли в AD для контроллера домена(DC)?. Зачем они нужны и что будет, если они недоступны?» Но, к сожалению, очень редко случается услышать полный и правильный ответ. Для начала, выскажу достаточно “крамольную мысль”, что безо всех FSMO ролей можно жить месяцами и даже этого не заметить…

Во встроенной справке, многочисленных р��ководствах и книгах, в том числе в отличных книгах Федора Зубанова написаны сотни страниц теории на эту тему. Но как показывает практика – это больше напускает туману в головы администраторов. Особенно это важно в том случае, когда кроме AD есть еще десяток систем для сопровождения. Рассмотрим этот вопрос с практической точки зрения, т.е. что нужно обязательно помнить, а что можно немного и «забыть».

Пять FSMO ролей Active directory и… глобальный каталог.

О ролях кратко и ёмко написано в статье "Роли FSMO службы Active Directory в Windows 2000". Обязательно прочитайте ее, чтобы освежить информацию, даже если вы чувствуете себя уверенно в Active Directory. Можно использовать статью как памятку о том, что конкретно делают сервера FSMO.

Большинство привычных операций, например, заведение пользователей и групп можно делать на любом контроллере домена. Служба репликации AD берет на себя копирование этих данных в рамках каталога. Устранение конфликтов делается простым методом – кто последний тот и прав. Этот механизм обеспечивает одинаковость базы Active Directory всех контролеров одного домена, т.е. любой контроллер домена содержит ВСЮ существенную информацию. Смело можно считать, что домен работает до тех пор, пока работает хотя бы один из контроллеров этого домена. Другими словами единица выживания всего каталога – это один сервер для каждого из доменов леса.

Существует несколько действий, при которых недопустимы конфликты. Если два администратора решили в одно время создать по домену Siberia в лесу outof.ru, то система сама никогда не сможет определить какой из них нужно оставить, а какой удалить. Поэтому и существуют сервера с ролями flexible single master operation (FSMO). Их задача НЕДОПУСКАТЬ таких конфликтов. На мой взгляд, многие переводы термина FSMO на русский язык не так легки для понимания, а смысл там прост: главный сервер для роли может быть только один, но ее можно в любой момент легко передать другому контроллеру домена.

 

Роль сервера (FSMO)

Описание

 

Существуют только по одному на ВЕСЬ любой лес

Хозяин именования домена
(
Domain naming master)

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

Хозяин схемы
(Schema master)

Эта роль необходима для расширения схемы леса Active Directory, в большинстве случаев просто для выполнения команды adprep /forestprep.

 

По одному на каждый домен, т.е. больше доменов – больше серверов

Хозяин инфраструктуры (Infrastructure Master)

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

Это просто – т.к. если сервер не глобальный каталог(GC), то в его базе физически нет данных о пользователях других доменов. НО! Мы знаем, что в локальные группы домена мы можем добавлять любых пользователей. А группа в базе AD должна физически иметь ссылки на всех пользователей. Коллизия? ДА! Вот ее и решили специальным объектом фантомом(phantom), который никак через ldap не увидеть, но он есть. Именно работой с фантомами занимается мастер инфраструктуры.

Эмулятор PDC
(PDC emulator).

Очень важная роль, если у вас есть NT4 домен или клиенты до 2000. Работает как основной обозреватель сети Windows. Отслеживает блокировки пользователей при ошибках паролей. Является эталоном времени для домена. Роль также заслуживает отдельного поста – это в планах.

Хозяин RID
(RID Master)

Сервер с этой ролью раздает другим контроллерам домена пачки по 500 заготовок для создания уникальных SID. У каждого пользователя и группы обязательно есть SID(Security Identifier). Сам SID это такая строка вида S-1-5-21-165875785-1005667432-441284377-1023, которую вы иногда видите вместо имени пользователя или группы.

Глобальный Каталог(GC) - незаслуженно забытая роль

Существует еще важная шестая роль контроллера домена – это глобальный каталог(Global Catalog = GC). Такую роль может иметь любой контроллер в домене, т.е. она не относится к единственно возможной ни для леса, ни для домена. Другими словами, Global Catalog это НЕ FSMO – flexible single master operation. Наверное, именно поэтому, на вопрос о важных ролях контроллера домена, практически никогда не говорят о глобальном каталоге(GC).

Глобальный каталог по определению слушает LDAP порт 3268 и содержит в себе не только информацию о своем домене, но и часть информации обо всех остальных доменах, т.е.

  1. На глобальном каталоге можно запросом получить всех пользователей леса Active Directory!
  2. Из глобального каталога можно узнать членство пользователя во всех группах всех доменов.
  3. Глобальная адресная книга для Exchange запрашивается именно из глобального каталога (GC)

Важный вывод из определения:

  1. Если у вас есть только один домен, то включение роли глобального каталога только и только запускает LDAP сервис на порту 3268. Трафик репликации и размер базы не изменяются, т.к. просто НЕТ других доменов.
  2. Мастер инфраструктуры не работает на глобальном каталоге, потому что в его базе есть ВСЕ объекты леса. Там нет фантомов по определению, т.к. они не нужны.
  3. Если у вас все контроллеры в домене глобальные каталоги, то где находится и работает ли мастер инфраструктуры для вас совершенно не важно. Т.к. он просто не нужен.

Глобальный каталог - самая важная с практической точки зрения роль контроллера домена

Кратко вспомнили основные роли мастеров операций (FSMO роли) и что такое глобальный каталог (GC). Теперь переходим к самому интересному – что будет, если у нас недоступна каждая из ролей.

  • Хозяин схемы (Schema master FSMO) – не сможем произвести модификацию схемы. Схему модифицируют единичными случаями раз в несколько лет: установка новой версии ОС для доменов, установка Exchange, иногда других приложений.
  • Хозяин именования домена(Domain naming master FSMO) – не сможем добавить или удалить новый домен.
  • Хозяин RID (RID Master FSMO) – через некоторый, и что важно для реальной жизни, довольно длительный промежуток времени не сможем заводить новых пользователей и группы. Лимит жизни до 500 пользователей или групп. Есть организации, где людей работает всего 100 человек.
  • Эмулятор PDC(PDC emulator) – клиенты до 2000 windows не смогут попадать в домен плюс некоторые послабления при вводе неправильного пароля пользователем. синхронизация времени не остановится, но ошибки в event log обеспечены.
  • Хозяин инфраструктуры (Infrastructure Master) – если у нас много доменов, на контроллерах домена, которые не глобальные каталоги может нарушаться членство в локальных группах домена.

ДА… звучит, конечно, страшно, но в реальной жизни даже для относительно большой компании можно действительно жить без FSMO серверов днями. Редко кто заводит по 500 новых пользователей ежедневно. Время на 15 минут рассинхронизироваться тоже за пару дней врят-ли сможет. А проблему с паролями можно даже и не заметить совсем.

Само по себе такое поведение предсказуемо и логично. Революция в архитектуре Active Directory по сравнению с каталогами NT4 как раз и была в том, что нет таких единственных ролей сервера, при выходе из строя которых, вы теряете основную фунциональность домена. Ведь в NT4 отказ PDC приводил к тому, что домен переходил в режим “только для чтения”.

А что будет, если у нас вдруг перестанут работать все глобальные каталоги? Такое для небольших внедрений AD встречается гораздо чаще, чем это может показаться на первый взгляд. Например, есть два сервера – один GC, а второй, как это часто бывает, нет. Выключаем мы сервер, где работает глобальный каталог, пропылесосить и что мы увидим?

При отказе последнего глобального каталога (GC) – пользователь не сможет войти в свой компьютер. А сервер Exchange не будет работать с почтой.

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

Для больших структур AD при отказе в це��тре, например, Exchange вдруг станет работать гораздо медленнее, хотя нагрузки на самом почтовом сервере нет. В случае сбоя связи удаленного филиала с центром пользователи не входят в домен. А ведь именно для “независимого входа в сеть” и ставили контроллер домена в филиал, верно?

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

Часто получается, что роль глобального каталога, предназначенная для работы на многих серверах, используется на единицах машин. Это опасно для здоровья active directory и нервов системного администратора. Поэтому не стесняйтесь делать каждый контроллер домена глобальным каталогом – жить будет легче.

Основные тезисы этой заметкиTips and Tricks

  • FSMO роли хоть и единственные, и действительно требуют внимания, не так уж и важны для ежедневной работы каталога Active Directory. Т.е. отказ контроллера домена с ролью FSMO в течение нескольких дней может быть незаметен для пользователей.
  • Делайте каждый контроллер домена глобальным каталогом. Во-первых, чем их больше, тем лучше для производительности и надежности инфраструктуры. Во-вторых, тогда можно забыть про роль мастера инфраструктуры (Infrastructure master) совсем, он будет не нужен для работы AD.
  • Никогда не используйте кэширование универсальных групп (Universal Group Membership caching) - включайте глобальный каталог!

Материал для домашнего чтения

Comments
  • Статья получилась хорошая и емкая =)

    только опечатку поправить надо "Существует еще важная шестая роль контроллера домена – это контро��лер домена"

    я так понимаю речь все таки о GC идет ? =)

    ---////vladygin: Спасибо, поправил.

  • "Хозяин схемы (Schema master FSMO). В каждом лесу существует один хозяин схемы. Эта роль необходима для расширения схемы леса Active Directory или для выполнения команды adprep /domainprep."

    ---

    Не опечатка ли?

    adprep /domainprep \\ adprep /forestprep

    ----///vladygin Поправил, действительно перепутано было местами. Так-же отправил поправку в нашу KB статью, откуда я "мастер-копию" абзаца делал.

  • "Никогда не используйте кэширование универсальных групп (Universal Group Membership caching)"

    не слишком ли это безответственное заявление? а что же делать, имея сложную почтовую организацию и разветвленную филиальную сеть?

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

    Если вы уточните для какой цели и в каких условиях вы предпочитаете использовать UGMC(можно мне в почту, используя ссылку e-mail на этом сайте), то я попробую подсказать под ваш пример что лучше делать вместо UGMC и почему.

  • К сожалению на [почту] письмо не уходит...

    1. В документации MS чётко указывает когда можно (нужно?) использовать кэширование универсальных групп:

    "In a branch site that has no global catalog server and in a forest that has multiple domains, you can use this procedure to enable Universal Group Membership Caching on a domain controller in the site so that a global catalog server does not have to be contacted across a wide area network (WAN) link for every initial user logon."

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

    2. Кроме этого небольшое замечание по роли Emulator PDC - он отвечает за синхронизацию времени в домене. Если он не доступен - должна возникать проблема с синхронизацией рабочих станций с доменным источником времени... Что может вызвать различные проблемы, вплоть до невозможности работы отдельных клиентов в сети... Если я не прав - поправьте.

    3."Глобальный каталог (GC) – пользователь не сможет войти в свой компьютер." - вот с этим утверждением я согласен частично. Пользователь ранее логинившийся на рабочую станцию после потери связи с GC тем не менее сможет всё-равно залогиниться. В политиках домена windows 2003 это поведение клиента по умолчанию (может быть в windows 2008 это изменено, не могу этого утверждать, так как плотно с windows 2008 ещё не работал). Его можно изменить, но я ещё не встречал, чтобы кто-то менял эту настройку. Тем не менее утверждение бывает верным в случае попытки входа на компьютер пользователя, который ранее не логинился на компьютер. В таком случае, естественно залогиниться не получится

  • У любого ситемного администратора время от времени возникает желание иметь карту своей сети. Разумные

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

    1) DNM - процесс добваления контроллеров домена как реплик к тому или иному контексту (чаще всего к App контексту с зонами DNS).

    2) PDC - процесс AdminSDHolder

    3) PDC - преимущественный контроллер при редактировании групповых политик.

    4) PDC - преимущественный сервер при проблемах разрешения доменных DFS ссылок и SYSVOL/NETLOGON.

  • По поводу GC перебор.

    У меня 3 контроллера DC1, DC2, DC3

    GC включен только на первых двух.

    Выключаю службу NETLOGON на обоих и спокойно регистрируюся на ПК под новой учеткой. Новой, в смысле, что под ней на данном ПК еще ни разу не было входа (кэширование исключено). В CMD набираю SET и вижу строку: LOGONSERVER=\\DC3

  • Отличная статья! А как называется специальная политика, которая позволяет входить пользователю в домен и без доступного глобального каталога, и которая по-умолчанию отключена?

  • Ривечаю сам себе, называется она вот так - http://clip2net.com/page/m3356/921645

  • Отвечаю сам себе, называется она вот так - http://clip2net.com/page/m3356/921645

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

    И пара мелких замечаний по тексту:

    - "Другими словами" - обособляется запятой

    - "НЕ ДОПУСКАТЬ" - пишется раздельно

    - "создать по домену Siberia в лесу outof.ru" - если Siberia это поддомен, то тогда, видимо, лучше будет сказать "в дереве", поскольку упоминание о лесе я обычно воспринимаю как намек на несвязанное пространство имен;

    - "Вот ее и решили специальным объектом фантомом" - проблемы решают, а коллизии обычно устраняют.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment