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

Ошибки в выборе имени Active Directory

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

• Я уверен, что большинство из вас знают, что DNS имена в интернете строятся по определенному принципу, оно состоит только из цифр, букв, точек и тире (про различные виды записей DNS я не говорю)..com. Есть стандарт из документа RFC 1123 об именовании доменов, где черным по белому прописано, что в названиях не должны присутствовать вот такие спецсимволы: знак собаки @, тильда ~, знак номера #, слэш / и \, нижнее подчеркивание, если вы по своему незнанию в качестве доменного имени выбрали, что то содержащее нижнее подчеркивание, то у вас например будут большие проблемы с почтовым сервером MS Exchange. Если бы не было стандартов, был бы хаос.
• В качестве локальных имен Active Directory, люди выбирают внешние адреса, точнее имена второго уровня. Простой пример, у меня допустим есть предприятие Pyatilistnik.inc и администратор решил установить контроллер Active Directory и создать доменную структуру, но в качестве локального имени для него он взял pyatilistnik.. Представьте какой хаос начнется, когда людям нужно будет до него достучаться из локальной сети, будет конфликт с именем AD, вам чтобы решить проблему придется держать и внешнюю зону DNS и внутреннюю, что не удобно и приведет к ошибкам. Ниже я расскажу как правильно назвать домен active directory
• Имена зон не входящие в глобальный официально зарегистрированный реестр ICANN. Примерами может служить зоны.local или например.nn, хотя я уверен, что и до них дойдет стандарт, так как данной организации выгодно делать деньги из воздуха, продавая имена, каких сейчас доменов уже не встретишь, но речь сегодня не об этом. Эти имена не правильно использовать в Activer Directory, так как их нельзя будет использовать за пределами вашей конторы, нельзя будет выпустить ssl сертификат на домен .

Хотя если вы делаете это в тестовой среде, то можно

• Disjoint Namespace > бывают ситуации, когда DNS имя контроллера домена или компьютера не совпадают с его NETBIOS именем, например если бы у меня контроллер имел NETBIOS имя dc6, а доменное dc.сайт. Такие конструкции работоспособны и могут быть при слиянии предприятий, но при Disjoint Namespace могут быть и грабли с тем же MS Exchenge. Ниже пример совпадения и NETBIOS и DNS имени.

Как правильно назвать домен active directory

Как неправильно делать мы поняли и знаем, сделаем теперь все красиво, сразу повторюсь, что если у вас тестовая среда называть AD вы можете как вам захочется, хоть microsoft.com. А если по серьезному, то вернемся к нашей компании Pyatilistnik.inc. Для доменной зоны Active Directory я бы выбрал зону третьего уровня, ad.сайт. Веб сайт компании повесил бы на логичный сайт. Благодаря этому не было бы проблем с MS Exchange сервером. Если у вас несколько филиалов, то я советую вам использовать один лес, пример есть Нижний Новгород и Москва, для Москвы я выбираю ad..ad.сайт. Надеюсь вы теперь поняли как лучше и правильнее называть домен Active Directory.

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

Стоимость домена второго уровня (например, bissquit.com) составляет чуть больше 500 рублей в год. Это очень мало даже для обычных граждан, как мы с вами, и это сущие копейки для компаний тем более. Свой домен я приобрел ещё задолго до того, как появилась идея «запилить» этот бложик. Это просто удобно. Возьмем даже удаленное подключение по rdp — я ввожу имя своего домена, вместо унылого ip-адреса.

В интернете на запрос «active directory domain best practices» почти на каждом сайте написаны исчерпывающие рекомендации по именованию доменов AD и даны объяснения почему нужно сделать именно так. Давайте рассмотрим подробнее о каких рекомендациях идет речь:

• Для именования домена AD используйте поддомен вашего официально зарегистрированного домена организации.

Вы все поняли правильно, только один совет. Это все! Можно много рассуждать о деталях и мелких нюансах, но 80-90% рассуждений сводятся к одному единственному совету, озвученному выше. Все проблемы исходят из того, что человек знает, что так нужно делать, но не понимает почему нельзя или крайне не рекомендуется делать по-другому. С этого момента подробнее.

1. Почему нельзя использовать внутренние, неразрешаемые снаружи имена типа.local, .corp, .lan?

Можно. Ещё как можно. Большинство именно их и используют. У меня есть примеры среди знакомых, у которых в организациях 2000+ человек и используется домен.local. Все трудности начнутся, если вдруг станет нужен реальный домен AD. Такое может случиться при использовании гибридных облачных развертываний (яркий тому пример Exchange + Office365). «Почему бы просто не переименовать домен, ведь с определенной версии AD это вполне возможно?» — спросите вы. Да в принципе можно, однако вам предстоит столкнуться со сложностями миграции доменнозависимых сервисов. Среди них все тот же Exchange и др., но тут и одного Exchange более чем достаточно.

2. «Ок, покупаем реальное внешнее имя — my-company.com, также назовем и домен AD» — тоже не вариант. Возникнут проблемы с разрешением других ресурсов, расположенных на адресе my-company.com, например, веб-сайт компании. Да и к тому же ваши DNS-серверы не будут являться авторитативными для этого домена, хотя будут считать себя таковыми. Это тоже вызовет проблемы.

Есть и другие соображения касательно именований доменов, среди них создание аналогичного реальному домена но в другом TLD. Но мне кажется большого смысла так делать нет, ведь часть проблем все равно остается, а явных преимуществ в сравнении с использованием домена corp.my-company.com (имя взято для примера) просто нет.

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

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

Что такое контроллер домена

Контроллер домена обеспечивает централизованное управление сетевыми устройствами, то есть доменами. В контроллере хранится вся информация с учетных записей и параметров пользователей сети. Это параметры безопасности, локальной политики и многие другие. Это, своего рода, сервер, который полностью контролирует определенную сеть или сетевую группу. Контроллер домена - это, своего рода, набор специального программного обеспечения, которое осуществляет запуск различных служб Active Directory. Контроллеры работают под управлением определенных операционных систем, таких как Windows server 2003. Мастер установки Active Drive позволяет создавать контроллеры доменов.

В операционной системе Windows NT, как основной сервер, используется основной контроллер домена. Другие используемые серверы используются как резервные контроллеры. Основные контроллеры PDС могут решать различные задачи, связанные с членством пользователей в группах, создание и изменение паролей, добавление пользователей и многие другие. После чего данные передаются на дополнительные контроллеры BDC.

В качестве контроллера домена может использоваться программное обеспечение Samba 4, если установлена операционная система Unix. Это ПО также поддерживает и другие операционные системы, такие как windows 2003, 2008, 2003 R2 и 2008 R2. Каждая из операционных систем при необходимости может расширяться в зависимости от конкретных требований и параметров.

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

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

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

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

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

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

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

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

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

Для того чтобы контроллер домена работал правильно, необходимо произвести некоторые подготовительные работы. Первое, что нужно сделать, это проверить параметры TCP/IP, они должны быть правильно установлены для сервера. Важнее всего проверить DNS имена на сопоставления.

Для безопасной работы контроллера домена необходимо использовать файловую систему NTFS, обеспечивающую более высокую безопасность в сравнении с файловыми системами FAT 32. Для установки на сервере нужно создать один раздел в файловой системе NTFS, на котором будет находиться системный том. Также обязательно необходим доступ к DNS серверу с сервера. Служба DNS устанавливается на этом или дополнительном сервере, который должен поддерживать ресурсные записи.

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

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

Данная процедура гораздо сложнее, чем переименование рядового сервера, являющегося обычным членом домена. Для этой задачи нам понадобится утилита "NETDOM ", которая начиная с Windows 2008 входит в состав ОС , а для Windows 2003 понадобится установить "Support Tools ".

Для переименования контроллера домена действуем следующим образом:
1. Сначала убеждаемся в том, что функциональный уровень домена не ниже Windows 2003 и проверяем наличие прав "Domain Admins " ("Администраторы домена ").
2. Открываем командную строку с повышенными привилегиями и добавляем для контроллера дополнительное имя, в которое мы собираемся переименовать (в нашем примере SRV-DC1-OLD.TEST.LOCAL переименовываем в SRV-DC1.TEST.LOCAL ):

NETDOM computername SRV-DC1-OLD.TEST.LOCAL /add:SRV-DC1.TEST.LOCAL

3. С помощью редактора "ADSIEDIT.msc " убеждаемся, что имя добавлено корректно. В редакторе находим объект контроллера домена и проверяем значение свойства "msDS-AdditionalDnsHostName ", которое должно быть равно "SRV-DC1.TEST.LOCAL ".

4. Теперь необходимо убедиться, что обновленные SPN атрибуты успели полностью реплицироваться на остальные контроллеры домена в лесу. В этом нам поможет утилита "REPADMIN " или "REPLMON " для Windows 2003 .

Для ускорения процесса репликацию можно форсировать в оснастке "DSSITE.msc ". Просто кликните правой кнопкой мыши на подключении и выберите "Реплицировать сейчас ".

5. Теперь делаем первичным новое имя контроллера домена:

NETDOM computername SRV-DC1-OLD.TEST.LOCAL /makeprimary:SRV-DC1.TEST.LOCAL

6. Перегружаем сервер.
7. Снова проверяем, что обновлённые SPN атрибуты и записи в DNS успели полностью реплицироваться на остальные контроллеры домена и сервера DNS в лесу, а значение свойства "msDS-AdditionalDnsHostName " теперь равно старому имени сервера.

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

NETDOM computername SRV-DC1.TEST.LOCAL /remove:SRV-DC1-OLD.TEST.LOCAL

9. Форсируем или дожидаемся полной репликации, и в завершении перегружаем и проверяем прямые и обратные доменные зоны DNS на наличие записей со старым именем. Если находим таковые - удаляем или исправляем при необходимости на новое имя. Также стоит ещё раз проверить значение атрибута "msDS-AdditionalDnsHostName ", которое должно быть пустым.

В конце процедуры, когда вышеописанные шаги пройдены, внимательно проверяем логи Active Directory на всех контроллерах домена на наличие ошибок и с помощью утилиты "DCDIAG " убеждаемся в корректности работы леса.

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

С удовольствием читаю ваш блог, много полезного для себя узнал, хотел узнать ваше мнение по поводу имени домена 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

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