Tw-city.info

IT Новости
15 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Уровень домена active directory

Определение функционального уровня домена или леса

Функциональные уровни определяют возможности службы AD DS (Active Directory Domain Services), доступные в домене или в лесу. Они также ограничивают версии операционных систем Windows Server, которые можно использовать на контроллерах домена в домене или в лесу. Но функциональные уровни не влияют на то, какие операционные системы могут использоваться на рабочих станциях и рядовых серверах, входящих в домен или лес.

При создании нового домена или нового леса устанавливайте максимально возможные функциональные уровни домена и леса, которые может поддерживать среда. Таким образом, можно будет пользоваться преимуществами максимального количества возможностей службы AD DS. Например, если известно, что в домен или лес никогда не будут добавлены контроллеры домена с операционной системой Windows Server 2008 (или более ранней версией), выберите режим работы Windows Server 2008 R2. С другой стороны, если существует вероятность того, что будут добавлены или оставлены контроллеры домена с операционной системой Windows Server 2008 или более ранней версией, выберите при установке режим работы Windows Server 2008. Повысить функциональный уровень можно и после установки, когда появится уверенность в том, что подобные контроллеры домена не используются и не будут добавляться.

При установке нового леса будет предложено определить функциональный уровень леса, а затем функциональный уровень домена. Нельзя определить для функционального уровня домена значение, меньшее функционального уровня леса. Например, если установлен режим работы леса Windows Server 2008 R2, можно установить только режим работы домена Windows Server 2008 R2. Режимы работы домена Windows 2000, Windows Server 2003 и Windows Server 2008 на странице мастера Задание режима работы домена будут недоступны. Кроме того, всем доменам, впоследствии добавляемым в лес, по умолчанию будет назначаться режим работы домена Windows Server 2008 R2.

После установки значения режима работы домена его нельзя отменить или понизить, за исключением следующего случая: режим работы домена повышается до Windows Server 2008 R2, а для леса установлен уровень работы Windows Windows Server 2008 или ниже. В этом случае можно восстановить режим работы домена Windows Server 2008. Режим работы домена может быть понижен только с Windows Server 2008 R2 до Windows Server 2008. Режим работы домена Windows Server 2008 R2 нельзя понизить, например, до Windows Server 2003.

После установки значения режима работы леса его нельзя отменить или понизить, за исключением следующего случая: режим работы леса повышается до Windows Server 2008 R2, а корзина Active Directory не включена. В этом случае можно восстановить режим работы леса Windows Server 2008. Режим работы леса может быть понижен только с Windows Server 2008 R2 до Windows Server 2008. Режим работы леса Windows Server 2008 R2 нельзя понизить, например, до Windows Server 2003.

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

Возможности, доступные на функциональных уровнях доменов

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

  • Универсальные группы как для групп рассылки, так и для групп безопасности
  • Вложенные группы
  • Преобразование групп, позволяющее выполнять преобразование между группами рассылки и группами безопасности
  • Журнал идентификаторов безопасности
  • Для переименования контроллера домена доступно средство управления доменом Netdom.exe.
  • Обновление метки времени входа в систему. Атрибут lastLogonTimestamp получит значение времени последнего входа в систему пользователя или компьютера. Этот атрибут реплицируется внутри домена. Обратите внимание, что этот атрибут не может быть обновлен, если проверку подлинности учетной записи осуществляет контроллер домена только для чтения (RODC).
  • В качестве эффективного пароля для объектов inetOrgPerson и объектов пользователей может быть определен атрибут userPassword.
  • Возможно перенаправление контейнеров пользователей и компьютеров. По умолчанию предусмотрено два общеизвестных контейнера для размещения учетных записей компьютеров и пользователей/групп: cn=Computers, и cn=Users, . Благодаря этой возможности можно определить новое общеизвестное местонахождение этих учетных записей.
  • Диспетчер авторизации может хранить свои политики авторизации в службе AD DS.
  • Ограниченное делегирование, позволяющее приложениям использовать преимущество защищенного делегирования учетных данных пользователя с помощью протокола проверки подлинности Kerberos. Делегирование можно настроить так, чтобы оно было доступно только конкретным целевым службам.
  • Поддержка выборочной проверки подлинности, позволяющая задать пользователей и группы из доверенного леса, которым разрешено проходить проверку подлинности на серверах ресурсов доверяющего леса.
  • Поддержка репликации распределенной файловой системы (DFS) для SYSVOL, обеспечивающая более надежную и подробную репликацию содержимого SYSVOL. Чтобы использовать репликацию DFS для SYSVOL, может понадобиться выполнить дополнительные действия. Для получения дополнительных сведений см. описание файловых служб (http://go.microsoft.com/fwlink/?LinkId=93167).
  • Поддержка расширенных служб шифрования (AES 128 и 256) для протокола Kerberos.
  • Сведения о последнем интерактивном входе в систему, показывающие время последнего успешного входа пользователя в систему, с какого компьютера был выполнен вход, также количество неудачных попыток входа с последнего входа в систему.
  • Детальные политики паролей, позволяющие определять для пользователей и глобальных групп безопасности в домене политики блокировки учетных записей и паролей.
  • Контроль механизма проверки подлинности, позволяющий определить примененный пользователем метод входа в систему (смарт-карта или имя пользователя и пароль) по его токену Kerberos. Если этот компонент включен в сетевой среде, в которой развернута инфраструктура управления федеративными удостоверениями (например, службы федерации Active Directory (AD FS)), данные токена могут извлекаться при каждой попытке доступа пользователя к поддерживающим утверждения приложениям, которые предназначены для определения авторизации на основе метода, применяемого пользователем для входа в систему.

Возможности, доступные на функциональных уровнях лесов

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

  • доверие леса;
  • переименование домена.
  • Репликация связанных значений (изменения членства в группах, чтобы сохранить и реплицировать значения для отдельных членов вместо репликации всего членства как единого блока). Это изменение приводит к уменьшению используемых пропускной способности локальной сети и ресурсов процессора при репликации, а также устраняет возможность потери обновлений при одновременном добавлении или удалении различных членов на различных контроллерах домена.
  • Возможность развертывания RODC
  • Улучшенные алгоритмы и масштабируемость проверки согласованности знаний (KCC). Генератор межсайтовой топологии (ISTG) использует улучшенные алгоритмы, масштабируемые для поддержки лесов с увеличенным количеством сайтов, чем может поддерживаться на функциональном уровне леса Windows 2000.
  • Возможность создавать экземпляры динамического вспомогательного класса dynamicObject в разделе каталога домена.
  • Возможность преобразовывать экземпляр объекта inetOrgPerson в экземпляр объекта пользователя и обратно.
  • Возможность создавать экземпляры новых типов групп, называемых базовыми группами приложений и группами запросов LDAP, для поддержки авторизации на основе ролей.
  • Деактивация и переопределение атрибутов и классов в схеме
  • Корзина, предназначенная для полного восстановления удаленных объектов во время работы служб AD DS.

Все домены, впоследствии добавленные в лес, по умолчанию будут работать в режиме Windows Server 2008 R2.

Если планируется использовать во всем лесу только контроллеры домена с операционной системой Windows Server 2008 R2, для удобства администрирования можно выбрать этот режим работы леса. В этом случае не понадобится повышать функциональный уровень домена ни для каких доменов, создаваемых в лесу.

Как узнать режим работы леса и режим работы домена Active Directory

Как узнать режим работы леса и режим работы домена Active Directory

Как узнать режим работы леса и режим работы домена Active Directory-01

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

Читать еще:  Ntdsutil удаление контроллера домена

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

Как узнать режим работы домена Active Directory через оснастку ADUC

Открываем оснастку пользователи и компьютеры, делается это через Пуск-Администрирование или ввод в меню Выполнить команды dsa.mac

Как узнать режим работы леса и режим работы домена Active Directory-02

Щелкаем правым кликом по вашему домену и выбираем Повысить режим работы домена

Как узнать режим работы леса и режим работы домена Active Directory-03

И видим что текущий режим Windows Server 2008 R2.

Как узнать режим работы леса и режим работы домена Active Directory-04

Как узнать режим работы леса и режим работы домена Active Directory через оснастку домены и доверие

Открываем оснастку домены и доверие через меню пуск-Администрирование, либо в меню выполнить введите domain.msc.

Как узнать режим работы леса и режим работы домена Active Directory-05

Щелкаем правым кликом по Active Directory — домены и доверие и из контекстного меню выбираем Изменить режим работы леса

Как узнать режим работы леса и режим работы домена Active Directory-06

и видим что лес работает в режиме Windows Server 2008 R2.

Как узнать режим работы леса и режим работы домена Active Directory-07

Если щелкнуть правым кликом там же но по домену и выбрать изменение режима работы домена, то вы так же увидите в каком режиме работает ваш домен.

Как узнать режим работы леса и режим работы домена Active Directory-08

Как узнать режим работы леса и режим работы домена Active Directory через powershell

Для этого дела у Microsoft естественно есть свои командлеты. Для начала давайте откроем powershell от имени администратор через правый кликом и посмотрим список доступных модулей powershell с помощью команды

Если среди них нет модуля Active Directory то он устанавливается командой

И загружаем модуль Active Directory с помощью команды

Как узнать режим работы леса и режим работы домена Active Directory-09

Для вывода информации по домену мы вводим команду, и в поле DomainMode видим что это уровень Windows Server 2008 R2.

Как узнать режим работы леса и режим работы домена Active Directory-10

Для вывода информации по лесу мы вводим команду. и в поле ForestMode видим что это уровень Windows Server 2008 R2.

Как узнать режим работы леса и режим работы домена Active Directory-11

Вот так вот просто узнать режим работы леса и режим работы домена Active Directory через оснастки и командную строку.

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

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

  • Главная
  • Обновление схемы Active Directory

Обновление схемы Active Directory

  • Автор: Уваров А.С.
  • 14.05.2013

Как известно — ничего вечного нет, все меняется, особенно в такой отрасли как IT. Развернутая один раз инфраструктура постоянно развивается, расширяется, совершенствуется и наступает момент когда в вашу Active Directory требуется ввести контроллер домена под управлением более поздней версии операционной системы.

Казалось бы — в чем проблема? Но, как показывает практика, проблемы возникают, во многом от того, что системные администраторы слабо владеют теорией и откровенно путаются в данном вопросе. Поэтому самое время разобраться в том, что такое схема AD и какое отношение она имеет к нашему случаю.

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

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

Вроде бы понятно, но не совсем, поэтому перейдем к распространенным ошибкам и заблуждениям.

  • Обновление схемы необходимо для включения в домен ПК под управлением более новых версий ОС Windows. Это не так, даже самые последние версии Windows могут вполне успешно работать в домене уровня Windows 2000 без обновления схемы. Хотя, если вы все-таки обновите схему, то ничего страшного не произойдет.
  • Для включения в домен контроллера под управлением более новой ОС требуется повысить уровень работы домена (леса). Это тоже не так, но в отличие от предыдущего случая, данная операция сделает невозможным использование контроллеров домена под управлением ОС ниже, чем режим его работы. Поэтому в случае ошибки вам придется восстанавливать вашу структуру AD из резервной копии.

Также заострим ваше внимание на режиме работы леса и домена. Домены входящие в лес могут иметь различные режимы работы, например один из доменов может работать в режиме Windows 2008, а остальные в режиме Windows 2003. Схема работы леса не может быть выше, чем схема работы самого старого домена. В нашем примере режим работы леса не может быть выше, чем Windows 2003.

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

Ознакомившись с теорией, перейдем к практическому примеру. Допустим у нас есть домен уровня Windows 2000 (смешанный режим) — самый низкий уровень AD — в котором имеется контроллер под управлением Windows 2003, а наша цель — создать новый контроллер взамен вышедшего из строя.

Новый сервер работает под управлением Windows 2008 R2. Заметьте, у нас не возникло никаких сложностей по включению данного сервера в существующий домен.

Однако при попытке добавить новый контроллер домена мы получим ошибку:

Для успешного включения контроллера под управлением более новой версии ОС нам потребуется обновить схему леса и схему домена. Исключение составляет Windows Server 2012, который при добавлении нового контроллера домена произведет обновление схемы самостоятельно.

Для обновления схемы используется утилита Adprep которая находится в папке supportadprep на установочном диске Windows Server. Начиная с Windows Server 2008 R2 эта утилита по умолчанию 64-разрядная, при необходимости использовать 32-разрядную версию следует запускать adprep32.exe.

Для выполнения обновления схемы леса данная утилита должна быть запущена на Хозяине схемы, а для обновления схемы домена на Хозяине инфраструктуры. Чтобы узнать какие из контроллеров имеют необходимые нам роли FSMO воспользуемся командой:

В Windows 2008 и новее данная утилита установлена по умолчанию, а в Windows 2003 ее нужно установить с диска из директории supporttools

Результатом вывода данной команды будет перечисление всех ролей FSMO и контроллеров имеющих данные роли:

В нашем случае все роли находятся на одном контроллере, поэтому копируем папку supportadprep на жесткий диск (в нашем случае в корень диска C:) и приступаем к обновлению схемы леса. Для успешного выполнения операции ваш аккаунт должен входить в группы:

  • Администраторы схемы
  • Администраторы предприятия
  • Администраторы домена, в котором находится хозяин схемы
Читать еще:  Домен сервера exchange

Чтобы обновить схему леса выполните команду:

Ознакомьтесь со стандартным предупреждением и продолжите нажав C, затем Enter.

Начнется процесс обновления схемы. Как видим ее версия изменится с 30 (Windows 2003) до 47 (Windows 2008 R2).

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

Для успешного обновления схемы домена эту операцию следует производить на Хозяине инфраструктуры и иметь права Администратора домена. Выполняем команду:

И внимательно читаем выводимую информацию. Обновляя схему домена с уровня Windows 2000 или Windows 2003 необходимо выполнить изменение разрешений файловой системы для групповых политик. Данная операция производится один раз и в дальнейшем, например обновляя схему с уровня 2008 на 2008 R2, выполнять ее нужно. Для обновления разрешений объектов GPO введите команду:

В версиях AD начиная с Windows 2008 появился новый тип контроллеров домена: контроллер домена только для чтения (RODC), если вы планируете развернуть такой контроллер, то вам нужно подготовить схему. Вообще мы рекомендуем выполнить данную операцию вне зависимости от того, собираетесь вы в ближайшее время устанавливать RODC или нет.

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

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

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

blog.eaglenn.ru | Заметки IT инженера

Microsoft, Linux, Lync и etc……

Выбор имени домена Active Directory

Введение

Вчера, к нам в студию, поступило письмо от нашего постоянного читателя Андрея, с вопросом:

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

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

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

1. Домен с именем example.local

Лидером нашего хит-парада является именование домена с окончанием на local. Существуют и другие вариации на эту тему, например test, firma, factory, nn, loc, и так далее. Сейчас даже уже и не вспомнишь откуда пошла такая любовь, во всех своих книгах компания Microsoft всегда использует свои именование вида contoso.com, где мы четко видим формат именования домена. Однако на протяжении почти 10 лет домен .local занимал лидирующие позиции. Ситуация стала выравниваться с приходом сервисов использующих в своей работе SSL сертификаты. Где использование доменов «пофиг и так сойдет» становится не возможным. Смотрите, предположим, что ваша компания использует внутри организации Exchange server, которому необходим ssl сертификат для шифрования клиентских подключений. Согласно вашему сценарию для реализации этой задачи вам необходим сертификат внешнего центра сертификации, в котором необходимо указать все имена серверов используемых для внешнего подключения. Казалось бы что такого, записываем все имена серверов и подаем заявку на выпуск сертификатов, но есть одно но. С именем такого домена вы не сможете пройти валидацию, так как домен «пофиг и так сойдет» не существует и на попытку объяснить внешнему центру сертификации, что вам в SAN нужно засунуть FQDN имя не существующего домена получите мягкий отказ:

It’s not possible, we issue only certificates for real domain names.

Но существует еще одна неприятность. Использование доменного имени не принадлежащего вам в имени домена может привести к плачевным последствиям. Представьте ситуацию если зона local будет иметь статус публичной. Как зона com или ru. Дальше я думаю продолжать не стоит

2. Имя домена совпадает с внешним именем домена

Второе место нашего хит-парада. Не смотря на то, что такой сценарий является менее популярным, он все же имеет право на жизнь. Кроме того, что в ближайшем будущем вы все же получите некоторые неудобства при обслуживании сети, больше вам ничего не угрожает. Основной проблемой в этом сценарии будет то, что вам придется поддерживать два DNS сервера: внутренний и внешний. При таком условии компьютеры находящиеся внутри сети будут использовать для разрешения имен внутренний DNS сервер, а компьютера за периметром компании внешний. Предположим ваш домен носит гордое название example.com. В DMZ зоне у вас находится сайт компании с именем example.com. В описанном сценарии выше компьютеры находящиеся внутри организации не смогут получить к нему доступ ввиду того что для них example.com это имя домена и при вводе этого адреса в браузере они будут попадать на контроллер домена. Как я уже отметил выше кроме неудобства это ни к чему не приведет. Вы всегда можете использовать костыли, которые будут перебрасывать вас на внешний сайт, но согласитесь это не нужная двойная работа, либо внутри сети использовать имя сайта начинающееся с www, либо снаружи.

3. Имя домена из одного слова

Пожалуй самый не правильный вариант из приведенных выше. Одноуровневые домены: Single-label domain — это домен, который содержит только одну составляющую. По всей видимости их начали использовать во времена NT, когда компания Microsoft переняла удачный опыт компании Novell. Так сложилось, что изначально я был администратором FreeBSD и большого парка серверов NetWare начиная с версии 4.11, так вот в те стародавние времена NetWare использовала в своей работе Bindery, которая как раз имена схему одноуровнего домена, которую потом и переняла компания Microsoft.

Best practices

Пора подвести итог. Какое же именование домена использовать? Только домен третьего уровня в домене которым вы владеете. Не стоит использовать чужие более красивые доменные имена :-). Пример такого домена вы можете увидеть ниже:

Настройка Active Directory Domain Services

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

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге. Также рекомендую ознакомиться с основной статье по Active Directory — Active Directory Domain Services

Подготовка окружения

Разворачивать роль AD я планирую на двух виртуальных серверах (будущих контроллерах домена) по очереди.

  1. Первым делом нужно задать подходящие имена серверов, у меня это будут DC01 и DC02;
  2. Далее прописать статические настройки сети (подробно этот момент я рассмотрю ниже);
  3. Установите все обновления системы, особенно обновления безопасности (для КД это важно как ни для какой другой роли).
Читать еще:  Установка контроллера домена

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

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

Вообще сам подход к администрированию виртуализованных контроллеров домена отличается в виду некоторых особенностей функционирования AD DS 4 5 :

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

На этом основные шаги по подготовке окружения завершены, переходим к этапу установки.

Установка Active Directory

Установка производится через Server Manager и в ней нет ничего сложного, подробно все этапы установки вы можете увидеть ниже:

Сам процесс установки претерпел некоторые изменения 6 по сравнению с предыдущими версиями ОС:

Развертывание доменных служб Active Directory (AD DS) в Windows Server 2012 стало проще и быстрее по сравнению с предыдущими версиями Windows Server. Установка AD DS теперь выполняется на основе Windows PowerShell и интегрирована с диспетчером серверов. Сократилось количество шагов, необходимых для внедрения контроллеров домена в существующую среду Active Directory.

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

Настройка Active Directory

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

Далее весь процесс будет проходить в мастере настройки.

Повышение роли сервера до контроллера домена

Этапы работы мастера подробно описаны в документации 7 . Тем не менее, пройдемся по основным шагам.

Поскольку мы разворачиваем AD с нуля, то нужно добавлять новый лес. Не забудьте надежно сохранить пароль для режима восстановления служб каталогов (DSRM). Расположение базы данных AD DS можно оставить по умолчанию (именно так и рекомендуют. Однако для разнообразия в своей тестовой среде я указал другой каталог).

После этого сервер самостоятельно перезагрузится.

Создание учетных записей администраторов домена/предприятия

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

Сразу же рекомендую настроить и иерархию организации (только не используйте русские символы!).

Настройка DNS на единственном DC в домене

Во время установки AD также была установлена роль AD DNS, поскольку других серверов DNS у меня в инфраструктуре не было. Для правильно работы сервиса необходимо изменить некоторые настройки. Для начала нужно проверить предпочитаемые серверы DNS в настройках сетевого адаптера. Необходимо использовать только один DNS-сервер с адресом 127.0.0.1. Да, именно localhost. По умолчанию он должен прописаться самостоятельно.

Убедившись в корректности настроек, открываем оснастку DNS. Правой кнопкой нажимаем на имени сервера и открываем его свойства, переходим на вкладку «Сервер пересылки». Адрес DNS-сервера, который был указан в настройках сети до установки роли AD DS, автоматически прописался в качестве единственного сервера пересылки:

Необходимо его удалить и создать новый и крайне желательно, чтобы это был сервер провайдера, но никак не публичный адрес типа общеизвестных 8.8.8.8 и 8.8.4.4. Для отказоустойчивости пропишите минимум два сервера. Не снимайте галочку для использования корневых ссылок, если нет доступных серверов пересылки. Корневые ссылки — это общеизвестный пул DNS-серверов высшего уровня.

Добавление второго DC в домен

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

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

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

Настройка DNS на нескольких DC в домене

Для предупреждения проблем с репликацией нужно снова изменить настройки сети и делать это необходимо на каждом контроллере домена (и на существовавших ранее тоже) и каждый раз при добавлении нового DC:

Если у вас больше трех DC в домене, необходимо прописать DNS-серверы через дополнительные настройки именно в таком порядке. Подробнее про DNS вы можете прочитать в моей статье Шпаргалка по DNS.

Настройка времени

Этот этап нужно выполнить обязательно, особенно если вы настраиваете реальное окружение в продакшене. Как вы помните, ранее я отключил синхронизацию времени через гипервизор и теперь нужно её настроить должным образом. За распространение правильного время на весь домен отвечает контроллер с ролью FSMO PDC эмулятор (Не знаете что это такая за роль? Читайте статью PDC emulator — Эмулятор первичного контроллера домена). В моем случае это конечно же первый контроллер домена, который и является носителем всех ролей FSMO изначально.

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

Назовите её как считаете нужным и как объект будет создан, нажмите правой кнопкой — Изменить. Переходим в Конфигурация компьютераПолитикиАдминистративные шаблоныСистемаСлужба времени WindowsПоставщики времени. Активируем политики Включить NTP-клиент Windows и Включить NTP-сервер Windows, заходим в свойства политики Настроить NTP-клиент Windows и выставляем тип протокола — NTP, остальные настройки не трогаем:

Дожидаемся применения политик (у меня это заняло примерно 5-8 минут, несмотря на выполнение gpupdate /force и пару перезагрузок), после чего получаем:

Вообще надо сделать так, чтобы время с внешних источников синхронизировал только PDC эмулятор, а не все контроллеры домена под ряд, а будет именно так, поскольку групповая политика применяется ко всем объектам в контейнере. Нужно её перенацелить на конкретный объект учетной записи компьютера-владельца роли PDC-эмулятор. Делается это также через групповые политики — в консоли gpmc.msc нажимаем левой кнопкой нужную политику и справа у вас появятся её настройки. В фильтрах безопасности нужно добавить учетную запись нужного контроллера домена:

Подробнее о принципе работы и настройке службы времени читайте в официальной документации 8 .

На этом настройка времени, а вместе с ней и начальная настройка Active Directory, завершена.

Ссылка на основную публикацию
ВсеИнструменты 220 Вольт
Adblock
detector
×
×