Мастера active directory

Переименование домена Windows 2008

2012-04-15 · Posted in Active Directory, Windows Server 2008

Недавно я уже публиковал статью, посвященную переимнованию контроллера домена Windows Server 2008. Сегодня я собираюсь опубликовать связанную, но совершенно другую задачу – переимнование домена. Переименование домена это процедура, которую выполняют очень редко в реальном окружении, если вообще когда либо выполняют. Однако например в тестовом окружении это бывает полезно, да и просто для широты кругозора это не помешает знать.

У Microsoft имеется много информации в документации, посвященной переименованию домена и я рекомендую использовать её(ссылка будет в конце статьи), особенно если дело касается домена в промышленной среде. Однако шаги ниже впринципе вполне полностью описывают процедуру переименования и достаточны для тестовых целей. Для начала опишем первоначальные требования к переименованию домена в среде с одним доменом в лесу:

У вас должны быть права Enterprise Administrator.
Домен должен функционировать в нормальном режиме, не должно быть ни каких ошибок.
Функциональный уровень леса должен быть Windows Server 2003 или 2008, и все контроллеры домена должны быть под управлением как минимум Server 2003.
Должна существовать DNS зона для нового домена.
На рядовой сервер необходимо скопировать утилиты Rendom и Gpfixup для выполнения операции переименование. Данная операция не может быть выполнена с контроллера домена.
Дополнительные требования выдвигаются к DFS, перемещаемым профилям, центру сертификации и серверу Exchange. По этим вопросам посмотрите ссылку на документацию на TechNet, которая будет в конце статьи.

Переименование домена выполняется утилитой Rendom, которая устанавливается вместе с Active Directory при запуске dcpromo. Далее выполняем следующие шаги.

Выполните команду“rendom /list” для генерации файла Domainlist.xml, содержащего текущую конфигурацию леса.
Отредактируйте полученный файл, заменив значения полей и на новое имя домена.
Выполните команду“rendom /showforest” для отображения потенциальный изменений. Этот шаг не делает никаких реальных изменений.
Выполните команду “rendom /upload” для загрузки инструкции переименования на контроллер домена с ролью domain naming operations master. Данная инструкция будет реплицирована на все другие контроллеры в лесу. После репликации на все контроллеры инструкция будет готова к применению. Вы можете ускорить репликацию запустив команду “repadmin /syncall”.
Выполните команду “rendom /prepare” для проверки готовности всех контроллеров домена в лесу к процедуре переименования. Все контроллеры должны сообщить о готовности и не должно быть никаких ошибок.
Выполните команду “rendom /do” для проверки готовности всех контроллеров, затем будет запущена процедура переименования для каждого контроллера. На период выполнения будет прерывания работы домена. После окончания процедуры контроллеры будут перезагружены. Если в период выполнения процедуры произойдет ошибка будет выполнен откат изменений. Поэтому любой контроллер домена, который завершил процедуру переименования с ошибкой должен быть понижен до рядового сервера.
Выполните команду “gpfixup” для обновления всех ссылок на групповые политики.
Дважды перегрузите все клиентские компьютеры и рядовые сервера для получения нового доменного имени. Так как при процедуре переименования GUID домена остается старый, членство в домене не затрагивается. DNS суффикс на клиентских машинах будет обновлен автоматически если установлена опция “Change primary DNS suffix when domain membership changes”.
Выполните команду “rendom /clean” для удаления ссылок на устаревшее имя домена из Active Directory.
Выполните команду “rendom /end” для прекращения заморозки конфигурации леса и разрешения дальнейших изменений.

Если у вас проявились какие либо проблемы с определением клиентскими машинами нового имени домена то вы можете удалить их с помощью команды “netdom remove /Domain: /Force”, затем перегрузить и присоединить к новому домену. После того как переименование завершено, нам остается сделать только одно последнее действие. DNS суффикс контроллера домена не был изменен в ходе процедуры и нам необходимо сделать это вручную.

Для дальнейшего изучения публикую обещанную ссылку на документацию TechNet

Предварительные требования

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

Функциональный уровень леса Active Directory. Выполнять задачи по переименованию доменов можно лишь в том случае, если все домены в лесу оснащены как минимум операционной системой Windows Server 2003 (в этом случае по редакциям нет никаких ограничений). Более того, функциональный уровень должен быть повышен по меньшей мере до уровня Windows Server 2003. То есть, если у вас в лесу выбран функциональный уровень Windows Server 2000, то выполнение следующей операции попросту станет невозможным;

Расположение домена. В лесу Active Directory может быть разный уровень доменов. То есть, могут быть либо отдельный домен, либо лес может включать дочерние домены. В том случае если вы будете менять расположение контроллера домена внутри леса, вам придется создать доверительные отношения;

Зона DNS. Еще до выполнения операции переименования домена вам необходимо создать новую зону DNS;

Административные учетные данные. Для выполнения операции переименования домена вы должны выполнить вход в систему под административной учетной записью, которая является членом группы администраторов предприятия (Enterprise Admins);

Серверы распределенной файловой системы (DFS)

Если в вашей корпоративной среде развернуты службы DFS или настроены перемещаемые профили, то обратите внимание на то, что корневые DFS-серверы должны работать, как минимум, под управлением операционной системы Windows Server 2000 с пакетом обновления 3 или под более современными версиями операционных системам;

Несовместимость с серверами Microsoft Exchange. Самый неприятный момент заключается в том, что если в вашем лесу Active Directory развернут почтовый сервер Microsoft Exchange Server 2003 Service Pack 1, то переименование домена будет выполнено без каких-либо проблем, но учетная запись пользователя, под которой будет выполняться сам процесс переименование домена должна быть членом группы Full Exchange Administrator

Все более современные почтовые серверы (включая Exchange Server 2016) несовместимы с операциями переименования доменов.

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

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

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

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

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

Как Domain Naming Master задействуется при переименовании домена

Создавая XML-файл DomainList.XML на основании информации о доменных NC;
Забирая этот файл после редактирования, а после – помещая созданный на основании данных из файла скрипт в атрибут объекта ;
А также помещая новое имя каждого задействованного в переименовании раздела (не забывайте, у домена – одна domain partition, но вы можете насоздавать кучу application partition, привязанных к имени конкретного домена, поэтому переименование домена в лесу может повлечь за собой изменение DN у нескольких NC) в атрибут , который есть у каждого объекта класса ;

Посмотрим теперь, что из похожих операций не относится к власти Domain Naming Master’а.

Удаленное переименование компьютера в доменной сети

Для переименования компьютера или рядового сервера в доменной сети, необходимо использовать системную утилиту netdom, которая идет в редакциях Windows Server. Данная утилита идет в комплекте с Active Directory Domain Services Tools, которую устанавливают на простых ПК для удаленного администрирования серверов под управлением Windows Server. Переименование производиться под доменной ученой записью.

netdom renamecomputer /newname: /userd: ] /usero: ] ] []

Иногда достаточно ввести:

netdom renamecomputer /newname: /userd: /passwordd:

По пунктам подробней:

• renamecomputer — ключ для переименования; компьютер — компьютер до переименования; • /newname: — желаемое имя компьютера после переименования(кавычки не нужны!); • /userd:имя_домена – тут необходимо поставить имя доменного администратора; • /passwordd: — оставить в точности как написано, на самом деле данный ключ определяет символ подстановки при вводе пароля; • /usero: — тут необходимо ввести имя пользователя локального администратора (или повторить ввод доменного, если он имеет права администратора на локальной машине); • /passwordo: — пароль локального администратора.

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

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

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

Переименовываем компьютер

На рабочем месте администратора нам необходима консольная программа netdom, ее можно установить из SupportTools на диске с дистрибутивом ОС.

Параметры команды: netdom renamecomputer компьютер /newname: новое_имя_компьютера /userd: имя_домена имя_администратора /passwordd:* /usero: локальный_администратор /passwordo:* /reboot: время в секундах до автоматической перезагрузки

Описание предыдущей командной строки:

компьютер — текущее имя компьютера.
новое_имя_компьютера — имя, которое вы хотите присвоить компьютеру.
имя_домена имя_администратора — NetBIOS-имя домена и имя учетной записи пользователя, обладающего правами администратора на объект компьютера в домене.
локальный_администратор — это пользователь, обладающий локальными правами администратора. Может совпадать с учетной записью пользователя, указанной для /userd:
Значок «звездочка» (*) — это значение, связанное с параметрами /passwordd: и/passwordo: и указывающее, что для отображения вводимого пароля следует использовать скрытые символы.
Время в секундах до автоматической перезагрузки — это промежуток времени между переименованием компьютера и его перезагрузкой. Если этот параметр не указан, компьютер следует перезагрузить вручную.

Эту команду следует вводить в одну строку, к примеру у нас есть компьютер test в домене example , переименовываем в work-01:

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

Автоматизируем

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

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

Вспомогательные материалы по теме:

Параметры Windows 10

Запускаем параметры операционной системы комбинацией клавши Win+I. Заходим в раздел система и переходим в самую последнюю вкладку «О системе». Кликаем на иконку «Переименовать этот ПК». В более ранних версиях «десятки» возможно название «Переименование компьютера».

Задайте в поле любое имя, которое будет отличаться от тех, которые уже подключились к локальной сети. Нажмите «Далее».

Для завершения переименования нужно будет перезагрузить ПК.

Учтите, что нельзя устанавливать имя на кириллице, а также использоваться некоторые символы (например, нижнее подчеркивание). В противном случае пользователь увидит сообщение «Недопустимое имя компьютера».

Проверка работы и отладка

# ln -s /var/log/samba /etc/samba/log

Запускаем samba и winbind:

# /etc/init.d/samba start
# /etc/init.d/winbind start

Для проверки правильно ли подключение к домену можно посмотреть список пользователей и групп домена (не обязательно):

# wbinfo -u
# wbinfo -g

Если нас не понимают, то подсказываем пароль для wbinfo и смотрим: список доменов в сети, информацию о домене WORKGROUP, список пользователей и групп домена:

# wbinfo --set-auth-user=root%root_password
# wbinfo --all-domains
# wbinfo -D WORKGROUP
# wbinfo -t

Проверяем, как работает NSS. Команда getent показывает инфо о пользователе, который может быть как в домене, так и юниксовый:

# getent passwd | grep pm
pm:x:15000:15000::/home/WORKGROUP/pm:/bin/false

# getent passwd | grep pavel
pavel:x:500:500:Pavel Malahov:/home/pavel:/bin/bash

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

Пример задач, при которых задействуется Domain Naming Master

Задача первая и самая простая – добавление нового домена в лес.

Domain Naming Master будет внимательно смотреть на то, чтобы новый домен не дублировал своим NBname-именем существующий. Понятное дело, что если вы попытаетесь добавить домен с идентичным уже существующему FQDN, то это не выйдет – однако с NBname ситуация интереснее. Дело в том, что при создании домена вы можете выбрать ему NBname, который никак не связан с его FQDN. То есть домен может иметь FQDN вида , а NETBIOS-имя – . Поэтому Domain Naming Master, получив запрос на добавление нового домена, проверит на существование и FQDN, и NBName. Это нужно, потому что возможна ситуация вида:

В лесу есть домен с FQDN = и NBname = ;
Мы пробуем добавить домен с FQDN = и NBname = ;
FQDN у них разные – но NBname одинаковые, поэтому такой домен добавить не получится;

Эта проверка нужна для предотвращения множества конфликтов, самый наглядный из которых – это окно входа на старенькой Windows XP, подключенной к домену – когда в третьей строке выпадающий список “в какой домен вы хотите попасть”. В случае, если в лесу Active Directory будут домены с не-уникальным названием, в этом списке придётся вывести одинаковые имена доменов, что сделает процедуру входа без UPN крайне затруднительной.

Задача вторая – добавление новой application partition и изменение её настроек.

Эти изменения (чтобы их сделать, я запущу утилиту , зайду в раздел , зайду в настройки подключения к серверу , подключусь к текущему серверу командой , и вернусь назад в управление разделами / naming context’ами через команду ) будут проводиться только при живом Domain Naming Master’е – если он будет неактивен, то будет такая вот грустная картинка:

Без работающего Domain Naming Master создать новую partition в лесу Active Directory не выйдет(кликните для увеличения до 859 px на 634 px)Учебный центр Advanced [email protected]://www.atraining.ru/

Я попробовал всего лишь вывести список naming context’ов – казалось бы, это не запись, а всего лишь чтение, и той информации, которая есть в виде реплики на каждом DC в лесу Active Directory – но все равно, для этой операции, чтобы администратор видел самые свежие данные, без оглядки на возможные задержки при репликации, обращение идёт сразу к Domain Naming Master’у – так система страхует от ситуации “другой админ только что создал раздел с таким же именем, подключившись к Domain Naming Master’у, а у вас плохая связь и вы решили, раз уж всего лишь список разделов запрашивается, то можно и с местного DC показать”.

Как только связь с Domain Naming Master’ом восстановится, я смогу и создать раздел, и изменить его параметры.

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

Структура OU в Active Directory

В небольших инфраструктурах AD (20-50 пользователей) необязательно создавать новые OU, можно все складывать в дефолтные контейнеры в корне (Users и Computer). В большой инфраструктуре желательно разделить все объекты на разные контейнеры. В основном используется иерархический дизайн Organizational Unit в AD, по географическому или функциональному принципу.

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

Понижение контроллера домена

Первым шагом понизим наш сервер до рядового сервера. Это можно сделать с помощью графического интерфейса, Powershell или командной строки.

Графика

Открываем Диспетчер серверов и переходим в Управление — Удалить роли и компоненты:

Если откроется окно с приветствием, то просто нажимаем Далее (при желании, можно поставить галочку Пропускать эту страницу по умолчанию):

В окне «Выбор целевого сервера» выбираем сервер, для которого мы будем понижать уровень AD:

… и нажимаем Далее.

Снимаем галочку Доменные службы Active Directory. откроется окно в котором отобразится список компонентов для удаления — нажимаем Удалить компоненты:

В следующем окне мы увидим предупреждение о том, что компьютер будет перезагружен и возможность принудительно понизить уровень — просто нажимаем Далее:

Система отобразит роли AD, которые будут удалены. Ставим галочку Продолжить удаление и нажимаем Далее:

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

Кликаем по Понизить уровень:

Процесс займет какое-то время. После мы увидим «Уровень контроллера домена Active Directory успешно понижен»:

Сервер автоматически будет перезагружен.

Powershell

Открываем консоль Powershell от администратора и вводим:

Uninstall-ADDSDomainController

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

LocalAdministratorPassword: **********
Подтвердить LocalAdministratorPassword: **********

Мы получим предупреждение о перезагрузки сервера. Соглашаемся:

После завершения этой операции сервер будет автоматически перезапущен. Когда вы удалите доменные службы Active
Directory на последнем контроллере домена, этот домен перестанет существовать.
Вы хотите продолжить эту операцию?
Да — Y Да для всех — A Нет — N Нет для всех — L Приостановить — S Справка
(значением по умолчанию является «Y»): A

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

Проверка требований

# smbd -b | grep KRB

   HAVE_KRB5_H
   HAVE_ADDRTYPE_IN_KRB5_ADDRESS
   HAVE_DECODE_KRB5_AP_REQ
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
   HAVE_KRB5_C_ENCTYPE_COMPARE
   HAVE_KRB5_C_VERIFY_CHECKSUM
   HAVE_KRB5_ENCRYPT_BLOCK
   HAVE_KRB5_ENCRYPT_DATA
   HAVE_KRB5_FREE_AP_REQ
   HAVE_KRB5_FREE_DATA_CONTENTS
   HAVE_KRB5_FREE_KEYTAB_ENTRY_CONTENTS
   HAVE_KRB5_FREE_KTYPES
   HAVE_KRB5_FREE_UNPARSED_NAME
   HAVE_KRB5_GET_PERMITTED_ENCTYPES
   HAVE_KRB5_GET_RENEWED_CREDS
   HAVE_KRB5_KEYBLOCK_IN_CREDS
   HAVE_KRB5_KEYTAB_ENTRY_KEY
   HAVE_KRB5_KEYUSAGE_APP_DATA_CKSUM
   HAVE_KRB5_KT_FREE_ENTRY
   HAVE_KRB5_LOCATE_KDC
   HAVE_KRB5_MK_REQ_EXTENDED
   HAVE_KRB5_PRINCIPAL2SALT
   HAVE_KRB5_PRINC_COMPONENT
   HAVE_KRB5_SET_DEFAULT_TGS_KTYPES
   HAVE_KRB5_SET_REAL_TIME
   HAVE_KRB5_STRING_TO_KEY
   HAVE_KRB5_TKT_ENC_PART2
   HAVE_KRB5_USE_ENCTYPE
   HAVE_LIBGSSAPI_KRB5
   HAVE_LIBKRB5
   HAVE_MAGIC_IN_KRB5_ADDRESS
   HAVE_TICKET_POINTER_IN_KRB5_AP_REQ
   KRB5_VERIFY_CHECKSUM_ARGS

Также проверим что поддерживается LDAP

# smbd -b | grep LDAP

   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_ADD_RESULT_ENTRY
   HAVE_LDAP_DN2AD_CANONICAL
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS

Для корректной работы Samba в домене Windows 2003 нужны версии MIT Kerberos version >=1.3.1. Проверим:

# dpkg -l | grep krb

ii  krb5-config    1.22                       Configuration files for Kerberos Version 5
ii  libkrb53       1.6.dfsg.4~beta1-5lenny1   MIT Kerberos runtime libraries

Для корректной работы с Windows 2008 серверами сама Samba должна быть достаточно свежая:

# smbd -V

Version 3.2.5

Уточнить или обобщить

В литературе можно встретить советы называть домены (особенно корневой) обобщенным словом, вроде Bank , Company или Corp . На то есть причины, так как в наше время компании могут регулярно переживать слияния и поглощения, смену торговой марки. А имя домена, как известно, поменять очень сложно.

С другой стороны, при том же слиянии и поглощении компаний весьма вероятна миграция пользователей из одного домена в другой. На практике мне встречалась ситуация, когда нужно было мигрировать пользователей из десятка доменов с одним и тем же именем Bank . Как известно, установка доверительных отношений между доменами с одинаковыми именами (будь то DNS или Netbios) не возможна. Придется либо переименовывать эти домены, либо мигрировать данные в два этапа, через третий домен.

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

Как выглядит зона ответственности Domain Naming Master

Описания и параметры naming context’ов будут располагаться в контейнере раздела – мы залезем в него, используя ADSI:

Где в домене находятся naming context-ы(кликните для увеличения до 862 px на 572 px)Учебный центр Advanced [email protected]://www.atraining.ru/

Наш домен, как понятно из картинки, называется , в нём:

три стандартных NC – доменный (), конфигурация леса (), и схема ();
две стандартных (с Windows Server 2003) application partition – Domain DNS Zones () и Forest DNS Zones ();
и одна просто так созданная вручную application partition с DN = – исключительно чтобы не дефолтную конфигурацию рассматривать

Если мы захотим сделать какие-либо изменения в этих данных – то есть или добавить новый домен в лес, или убрать домен из леса (удалив последний контроллер), или создать новый NC, или изменить параметры существующего NC – нам нужен присутствующий в онлайне владелец роли Domain Naming Master, потому что все записи в лесу в данный кусок идут через этот выбранный DC. Подчеркну – он не держит каких-то уникальных данных; вы можете назначить на эту роль любой контроллер, главное – что все указанные операции пойдут через него, и это уберёт целый пласт ситуаций вида “у нас большой лес, и два администратора в двух удалённых сайтах одновременно добавляют домен с одинаковым названием” – все такие операции на уровне леса будут реализовываться строго последовательно через владельца роли Domain Naming Master, поэтому конфликта в приведённом случае не будет – просто вторая попытка добавить домен с названием, которое уже есть, будет неудачной.