Главная Windows, Без рубрики, Новое Active Directory : “Активная директориЯ” – от А до Я (Рассказ 0)
  • Active Directory : “Активная директориЯ” – от А до Я (Рассказ 0)

    5 Наш путь извилист, но перспективы светлые.

    Мао

    Привет. Этой статьёй я начну достаточно амбициозный личный проект – сделать цикл статей, в которых максимально полно осветить тематику ключевой инфраструктурной службы – Active Directory. Рассматриваться будет текущая версия Active Directory – на платформе NT 6.1.

    NT 6.1 – это Windows Server 2008 R2. Так короче.

    На фотографии – Одри Хепберн. Потому что я долго думал, какие картинки добавлять к циклу статей, и ничего умнее не придумал.

    Что особенного будет в этом материале? Основное, что хочу подчеркнуть – подавляющее большинство материала про Active Directory, существующего сейчас, является наслоением дельт изменений в AD, начиная с Windows Server 2000. Т.е., грубо говоря, берётся фундаментальное базовое исследование – например, материал того же Зубанова, и рассказывается на основе его нечто вида “а вот тут новое появилось – такое-то и такое-то”.

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

    Мотив – рассказать о современной реализации службы Active Directory – с оглядкой на предыдущие реализации и разбором отличий. А не про оригинальную Active Directory 1999 года выпуска с “новыми изменениями” от 2001 года. 😉

    Логика цикла статей будет следующая – последовательно будет разбираться:

    1. Подготовка к развертыванию Active Directory – компоненты и сервисы.
    2. Само развёртывание Active Directory – step-by-step с остановкой на важных моментах.
    3. Базовое конфигурирование Active Directory – здесь планируется усилить темп и тут начнутся, наверное, “интересности” – ну, по крайней мере технический уровень изложения и предыдущее освещение событий должно дать возможность не отвлекаться на совсем уж базовые вопросы.
    4. Типовые операции обслуживания и инциденты – что делать со всем счастьем из пунктов 1, 2 и 3.
    5. Взаимодействие со внешними службами – кто и как будет использовать всё это.

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

    Ещё бы и выполнить это всё – вообще шикарно было бы. Ну да ладно.

    Пролог

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

    В частности, что включает в себя это понятие:

    1. Инфраструктура – один или несколько лесов Active Directory.
    2. Внешние службы каталогов, с которыми взаимодействует Active Directory.

    Как взаимодействует – напрямую, через external trust, или через сервисы интеграции – Forefront Identity Manager 2010 (который раньше Identity Lifecycle Manager 2010 / Identity Lifecycle Manager v2 / Identity Lifecycle Manager 2007 / Microsoft Identity Integration Service 2003 / Metadirectory 2.1) – сейчас не важно.

       3. Другие сервисы, пользующиеся Active Directory.

    Какие же технологии включает в себя Active Directory? Их, по сути, довольно-таки немало. В частности, это:

    1. Основная служба авторизации, работающая на базе модифицированной версии протокола Kerberos v5.

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

    Ну, иногда она не вторичная, а основная, потому что протокол Kerberos не обрабатывает 100% ситуаций авторизации. Иначе бы Lan Manager можно было бы совсем выключить, что не реализуемо, да и не нужно.

    3. Служба каталогов (LDAP), совместимая со стандартом x.500, но претерпевшая множество изменений.

    Фактически, в Active Directory параллельно работают 2 службы каталогов – это сами контроллеры доменов (Domain Controller – DC) и так называемые сервера глобального каталога (Global Catalog – GC). Технологически это представляет из себя два сопряжённых подмножества LDAP-серверов – каждое со своей структурой, схемой взаимодействия, логикой работы, спецификой настроек, разграничением доступа, функционалом и хранимой информацией. Вторые – т.е. сервера глобального каталога – невозбранно паразитируют на первых – контроллерах домена. Так-то. В самих службах каталогов – свои внутренние сервисы – ISTG, KCC, и другие.

    4. Служба точного времени (не NTP / SNTP) и синхронизации оного.

    Эта служба жизненно важна для работы протокола Kerberos, например.

    5. Службу разрешения имён – DNS.

    Службу NBNS (NetBIOS Name Service – чаще называется WiNS в силу практической приватизации фирмой Microsoft данного диалекта стека протоколов NetBIOS) не рассматриваем, как отдельный пункт – на одном nbname работа идти не сможет. То есть будет работать некоторый комплект сервисов, но это – явно меньше “прожиточного минимума”. Без той же PKI работать не будет куда как больше, поэтому про неё – отдельный пункт.

    6. Служба репликации файловых хранилищ, использующая для доступа протокол SMB / SMBv2, а для репликации содержимого – либо службу FRS (хуже), либо DFS (лучше).

    7. Службу обработки и применения централизованных настроек – групповых политик.

    8. Основную систему proxy-авторизации – т.н. доверительные отношения (trusts).

    Есть и другие системы – Active Directory Federation Services, например.

    9. Службу PKI.

    Эти 9 пунктов будут присутствовать в любом современном работоспособном решении, про которое можно сказать “Здесь развёрнута и функционирует Active Directory”. При отсутствии любого из указанных пунктов не будет работать какой-то ощутимый кусок крайне необходимого функционала. При отсутствии некоторых – так и вообще ничего (п.3, например). Также предполагается, что на момент начала работы с Active Directory решены все проблемы сетевого уровня, т.е. реализована непротиворечивая и функциональная сетевая топология – есть IP-подсети, установлены их взаимодействия, созданы виртуальные сети, IPv4/v6 трафик путешествует от точки А до точки Б корректно, в коммутации нет петель, и всё прочее в том же духе. Если этого нет – я буду упоминать, что необходимо на сетевом уровне для той или иной реализуемой подсистемы.

    Требования

    Предполагается, что Вы:

    – Знаете сетевые настройки (топологию) своего предприятия

    – На базовом уровне обладаете знанием того, какие рабочие станции и сервера (ОС) будут использоваться

    – Можете планировать/предполагать – хотя бы примерно – перспективы изменения топологии, количественного и качественного состава используемых систем хотя бы на год/два

    – Можете влиять на сетевые настройки (гарантировать отсутствие административных проблем при пробросе нужного трафика от точки А до точки Б)

    Последний пункт важен и зачастую забывается при работе в крупных организациях, что приводит к нехорошим сюрпризам, срыву сроков и зачастую – даже так называемому “Жоб.Ру”.

    Рассказ номер 0. Windows Server 2008 R2 как сервер для Active Directory.

    Некоторое время он молча жевал табак, потом  сплюнул  и  обратился  к Долговязому Джону:
         – Скажи, Окорок, долго мы  будем  вилять,  как  маркитантская  лодка?
    Клянусь  громом,  мне  до  смерти  надоел  капитан!  Довольно   ему   мной
    командовать! Я хочу жить в капитанской каюте, мне нужны ихние разносолы  и вина.
         – Израэль, – сказал Сильвер,  –  твоя  башка  очень  недорого  стоит,
    потому что в ней никогда не бывало мозгов.

    “Остров сокровищ”

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

    Изначально он у нас выглядит так (показана стандартная консоль Service Manager):

    image

    Всё, что было выполнено в различии от default конфигурации – был выдан статический IPv4 адрес и включен Remote Desktop.

    Давайте разбираться.

    Адрес IPv6 сконфигурирован не был; надпись IPv6 enabled обозначает только то, что хотя бы на одном сетевом интерфейса включён сам компонент IPv6, и он, безусловно, сформировал у себя т.н. Link-local адрес.

    Теперь пройдёмся по всему нарисованному на экране.

    Роли (Roles) и компоненты (Features)

    Нет ни одной. Появятся.

    Название компьютера

    Название сервера должно выполнять 2 функции:

    – Быть однозначным идентификатором в пределах AS

    AS – Autonomous System – Автономная система. Термин сетевых технологий, идентифицирующий группу ресурсов, находящуюся под одним административным управлением. Ну вот например. Сеть предприятия, где IP-сети уникальны, и имена серверов тоже – просто потому, что их так задали для своего удобства IT-специалисты – это AS. А вот сеть Вашего предприятия и соседнего – не AS, т.к. легко может сложиться так, что и Вы выбрали, например, 192.168.0.0/24, и они. И контроллер домена главный Вы назвали dc1, и они тоже. Кто прав? Да все правы; просто Вы – в разных AS.

    – Не быть привязанным к конкретной роли сервера

    В современной практике роли серверов могут добавляться и удаляться, и фиксация в названии какой-то одной – неудобно. Т.е. если у Вас, допустим, у сервера 3 задачи – сервер баз данных, сервер Microsoft Operations Manager и FTP-хранилище, то даже если Вы однозначно сможете выбрать какую-то одну функцию главной и назвать сервер в честь её (dbsrv1, mom1, ftp1), то со временем ситуация практически со 100% гарантией изменится и Вы будете перед перепутьем – или периодически переименовывать сервера, чтобы их фактический функционал совпадал с названием, или забить на это дело, но тогда иметь крайне “удобную” систему “на dc2 у нас sql, а dc там нет – так сложилось исторически…”. Поэтому сервера должны именоваться абстрактно, без привязки к функционалу.

    Распространённое заблуждение, что “всё равно потом переставлять кучу раз, заодно и переименуем” лучше забывать. Добавление-удаление серверного ПО и ролей/компонентов на сервер проходит безболезненно. Во времена Windows 2000 – да, были проблемы. Сейчас – практически нет.

    Плюс, со временем у Вас могут появиться сервисы, привязанные настройками конфигурации к конкретным именам других серверов. В случае переименования – у Вас дополнительная работа по изменению настроек этих сервисов, притом, по сути, лишняя – по не зависящим от них причинам. Например, есть сервер с Windows SharePoint Services. У него в качестве сервера для БД указан, допустим, некий “wwwsrv”, который так называли, потому что в своё время там был веб-сайт фирмы. Теперь появилась мысль – переименовать “wwwsrv” в “dbsrv”, потому что веб-сайта там нет. Из-за этой операции Вам придётся перенастраивать сторонний сервер (который с Windows SharePoint Services).

    В дополнение напомню, что Microsoft Windows Server 2008 R2 нуждается в активации. При переустановке Вам придётся проводить эту процедуру повторно, что, в случае VLK-ключей, не всегда удобно – если Вы будете часто переставлять сервера, то могут возникнуть проблемы с повторным запросом/регенерацией ключей.

    Не раскладывайте себе грабли заранее – их и без этого будет хватать. Я гарантирую это.

    Поэтому – называем абстрактно. Мой сервер, на котором всё показывается, называется s02 (типа “Сервер номер 02”).

    Обращаю внимание – имя сервера указано со строчной буквы. Почему?

    Дело в том, что у любого сервера будет два имени – одно в формате FQDN, другое – имя для протокола NetBIOS. Например, у сервера megaserver из домена domain.local они будут такими: “megaserver.domain.local” и “MEGASERVER”.

    В именах NetBIOS максимальная длина – 16 байт (в зависимости от реализации это – или 15 или 16 ASCII символов; у Microsoft – 15, один байт уходит на код сервиса). А в случае с FQDN каждый компонент полного имени ограничен 63 символами.

    Тонкость – обратите внимание; NetBIOS стандартизирован исходя из размерности в байтах – его идентификатор – это 16 БАЙТ, а в системе DNS считают в СИМВОЛАХ. Это начинает играть роль, когда речь идёт об UNICODE – тогда имена DNS остаются в пределах 63 символов, но вырастают в фактической, байтовой размерности. NetBIOS же UNICODE не любит и даже боится, и расти не умеет.

    Соответственно, мы будем говорить о FQDN-именах, если явно не указано иное. Вот для этих имён стандартными являются строчные буквы. Т.е. из нашего имени сервера будет сделано FQDN-имя простым добавлением суффикса с именем домена, поэтому имя хоста должно быть такое, чтобы FQDN-имя получилось стандартным. Если мы назовём сервер сразу MEGASERVER, то FQDN у него будет вида MEGASERVER.domain.local, что нехорошо. Протокол же NetBIOS сам умеет писать с зажатой кнопкой Shift, за него не беспокойтесь.

    Ну, умеет не всегда – только для первой половины ASCII-таблицы. ;). Т.е. если Вы предполагаете, что, допустим, имя хоста на норвежском будет также превращено в UPPERCASE, просто подумайте – тогда ведь в каждой реализации NetBIOS должны быть таблицы для всех национальных алфавитов – как из символа “ы” сделать символ “Ы”. Этого, безусловно, не наблюдается. Напомню – NetBIOS дружит с национальными алфавитами, но крайне платонически.

    С названием сервера в общих чертах разобрались – двигаемся дальше.

    Имя рабочей группы

    В случае работы вне домена узлы можно объединять в рабочие группы. Всё, что это принесёт – некоторое упрощение процедуры поиска общих ресурсов NetBIOS (папок и принтеров) в одноранговой сети. Не наш случай. Поэтому не обращаем внимание – имя домена у нас уже в голове, двигаемся дальше.

    В случае, если нужны внедоменные узлы – например, в DMZ – целесообразно сделать им случайные имена рабочих групп. Каждому. Зачем им то, что облегчает поиск друг друга, если эта функция в их ситуации не нужна?

    Настройки сетевого интерфейса:

    Корректные настройки сетевого интерфейса критически необходимы для безопасной и эффективной работы контроллера домена Active Directory. В нашем случае перечень сетевых интерфейсов будет выглядеть так:

    image

    Переименуем интерфейс из Local Area Connection в LAN (чтобы в случае работы через командную строку не набирать длинное название) и зайдём в свойства.

    image

    Такая картинка характерна для “чистой” установки Windows Server 2008 R2. В случае, если установка производилась путём обновления, картинка может отличаться. Что критично для нас:

    1. Убедитесь, что компонент QoS Packet Scheduler добавлен. В ранних версиях Windows Server (например, 2003) он не ставился автоматически, поэтому если Вы обновлялись, то не факт, что он будет присутствовать. QoS PS нужен, чтобы усилия приложений по формированию приоритетов данных не пропадали – если его не будет, или он будет выключен на интерфейсе, то, допустим, приложение будет помечать трафик, как приоритетный, а по факту в исходящей очереди сетевого интерфейса в заголовки IPv4 пакетов (там есть поле специальное – IP Type of Service) пометки устанавливаться не будут.

    2. Убедитесь, что IPv6 включен. В ранних версиях Windows Server (тот же 2003й) он был опциональным, и не требовался для работы Active Directory. Сейчас же он – предпочтительный и эффективный, поэтому включите его.

    Можно ещё добавить Reliable Multicast Protocol (который PGM – Pragmatic General Multicast); он добавит к многоадресным рассылкам TCP-подобные возможности по исправлению ошибок, гарантии доставки и некоторые другие функции, но для сервисов Active Directory он не критичен.

    Пойдём в настройки компонентов. Настроить можно будет только IPv4 и IPv6. Начнём с первого.

    Настройка IPv4

    Для работы Active Directory нам потребуется свой личный сервер DNS – на этом же узле. Можно поднять контроллер домена и без DNS “под ним”, и будет корректно работать, но у нас случай развёртывания с нуля.

    Следовательно, динамический IPv4 адрес нам не подойдёт. Выбираем произвольный статический, устанавливаем маску, соответствующую IP-сети, в которой находимся, и продолжаем.

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

    В качестве IPv4 адресов DNS-серверов мы укажем свой собственный. Почему? Есть ведь вариант – не указать никакого, и получить при применении настроек сообщение, что в связи с отсутствием адреса DNS-сервера будет использоваться адрес 127.0.0.1 . Это неправильно. Причины следующие:

    1. DNS-сервер может быть привязан (“слушать”) на ограниченном перечне интерфейсов; адрес же 127.0.0.1 является “ничьим” с точки зрения принадлежности к оным. Соответственно, лучше в явном виде указать – на какой IP-адрес (даже учитывая, что он свой) отдавать DNS-запросы – чтобы не попасть в ситуацию, когда система делает некие неявные и неоднозначные преобразования.

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

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

    В общем, задаём адрес сервера в явном виде.

    Автор весь курс будет отговаривать Вас от “неявных действий системы, которыми она умеет неправильно решать вопросы, кажущиеся простыми и очевидными”.

    Теперь нажимаем кнопку Advanced и пробегаемся по дополнительным настройкам IPv4.

    Вкладка IP Settings

    Перечень IPv4 адресов нам не очень интересен – у нас один адрес, он уже есть. Если что – именно тут можно добавить на интерфейс несколько дополнительных адресов. Первый, заметьте, всегда будет главным – аналог primary address. От него, при прочих умолчаниях, будут с этого интерфейса отправляться сетевые пакеты.

    Перечень шлюзов – тоже. Здесь можно будет указать несколько шлюзов IPv4, но вообще, эта технология крайне редко применима в реальных сетевых решениях. Причина – наличие множества других технологий класса FHR (First Hop Redundancy) – HSRP, FHRP, VRRP, GLBP – да и откровенно слабая реализация избыточности шлюзов в IPv4.

    Если Вы вспомнили технологию Dead Gateway Detection, существующую в Windows с версии 95 – забудьте. Она не про IP, а про TCP. Это слегка разное. 😉

    Говоря проще, встроенной в IPv4 эффективной технологии, позволяющей понять, что шлюз нерабочий – нет. Есть ряд решений, покрывающих части проблемы. IPv4 хост глупый и сам ничего не умеет. В IPv6 всё гораздо лучше.

    Автоматическое выставление метрики – оставляем. Конечно, механизм, разработанный фирмой Microsoft, дикий, но сейчас это некритично.

    Метрика у Microsoft считается исходя из номинальной скорости интерфейса. Т.е. есть табличка вида:

    – Метрика равна 50, если номинальная скорость канала – до 500Кбит/с

    – Метрика равна 40, если номинальная скорость канала – от 500Кбит/с до 4Мбит/с

    – Метрика равна 30, если номинальная скорость канала – от 4Мбит/с до 20Мбит/с

    – Метрика равна 20, если номинальная скорость канала – от 20Мбит/с до 200Мбит/с

    – Метрика равна 10, если номинальная скорость канала – от 200Мбит/с и выше

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

    Почему такие большие зазоры? Добрый Windows NT не разменивается на такую мелочь, как дуплексный/полудуплексный режим работы канала, поэтому запас взят такой, чтобы нейтрализовать вопрос “а если я канал в 100Мбит переключу с half-duplex на full-duplex, то метрика изменится?”. Не изменится. Два раза по 100Мбит – это же не больше 200Мбит. 😉

    Подумайте, как смешно получится, когда этот метод измерения метрики столкнётся, допустим, с тем же, поддерживаемым обычным Windows Server 2008 R2, протоколом динамической маршрутизации RIPv2 😉

    В общем – не трогаем; пока не нужно.

    Настройка DNS

    Теперь что нужно отметить здесь.

    Первое – список DNS-серверов. Ну, первые две строчки в нём будут совпадать с Preferred и Alternate DNS Server, которые мы видели ранее.

    Терминологический момент – когда-то эти сервера – “первый опрашиваемый” и “второй опрашиваемый”, назывались в Windows “Primary DNS” и “Secondary DNS”. Благодаря усилиям неназванных лиц коллективу разработчиков Windows удалось объяснить, что словами Primary и Secondary в терминологии технологии DNS называется другое. Не путайте.

    Зачем же остальные? Затем, что всего опрашиваться могут до 12 DNS-серверов.

    Есть домысел, что чем больше серверов, тем дольше работает запрос. Это не так. Дело в том, что запрос передаётся следующему серверу в списке (от preferred к alternate, от alternate к 3му по порядку, и далее) только в двух случаях – если сервер ничего не ответил по тайм-ауту, или если сервер вернул разборчивый ответ “я сломался” – “Server failure”. В случае получения любого иного разборчивого ответа (т.е. в неповреждённом пакете), опрос следующего сервера не производится. Т.е. нет логики вида “ааа, ты не знаешь, что за узел www.itband.ru – пойду, спрошу у следующего”. Подсистема распознавания имён завершает фазу resolving by DNS сразу же по получению ответа.

    Кому нужны 12 DNS? Ну, 12 не знаю, но 4 – вполне; 2 сервера в крупном региональном филиале и 2 резервных в центре – вполне возможная ситуация.

    Теперь настройка работы с FQDN-именем. Замечу, что настройка эта есть на любом интерфейсе, но вот делается она – централизованно. Т.е. если Вы её поменяете на одном из интерфейсов multihomed узла, то на другом будет всё то же самое.

    Настройка состоит в выборе метода добавления суффикса. Идея в следующем. У Вас есть узел, у которого есть имя – s02 в нашем варианте, и доменный суффикс – domain.local, например. В сумме эти компоненты дают Fully-Qualified Domain Name – s02.domain.local . Теперь представьте, что Вы набираете в командной строке команду:

    C:\>ping s03

    Что должна сделать система? Первым делом – узнать IPv6/v4 адрес узла s03.

    Именно в таком порядке, заметьте. Т.е. будут обе записи в DNS – и A для IPv4, и AAAA для IPv6 – по умолчанию отдаст IPv6.

    Но узла s03 в DNS-сервере нет. Там есть зона domain.local, в которой есть запись s03. Следовательно, система должна догадаться, что когда узел из domain.local (наш s02) ищет “просто s03”, он имеет в виду соседа по пространству имён (т.е. узел с таким же суффиксом). Именно это и является дефолтной настройкой – “Append primary and connection specific DNS suffixes”. Другие варианты настройки DNS Resolver – после, сейчас они не очень критичны.

    Следующие настройки уже per interface – т.е. “общими” для всех интерфейсов были лишь настройки DNS Resolver.

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

    Обратите внимание на пункт “Регистрировать адрес этого подключения в DNS”. Он должен быть включён. Если этот пункт выключен, то система, при поступлении запроса на регистрацию себя в DNS (например, путём выполнения вызова команды “ipconfig /registerdns”, периодического запроса refresh или чего-нибудь другого), не будет регистрировать пары “свой FQDN – каждый IP адрес этого интерфейса”. Такое иногда надо – например, на шлюзовых решениях, когда один интерфейс внутренний, а другой – внешний; тогда внешний интерфейс во внутридоменном DNS регистрировать смысла нет – узел доступен по внутреннему интерфейсу.

    Пункт “Использовать суффикс DNS, специфичный для этого интерфейса, при регистрации” имеет смысл, если этот суффикс – специфичный для интерфейса – есть. У нас его нет, поэтому оставим, как есть.

    Вкладка WINS

    Перечень серверов NBNS – пуст. Они нам не нужны.

    Пункт “Enable LMHOSTS lookup” – счищайте. Нет сейчас информации в lmhosts важной. Разве что самые убогие вирусы туда пишут, да и то – по неграмотности путая hosts и lmhosts. Чтобы не попасть в ситуацию, когда там ВНЕЗАПНО появится какая-то информация, и начнёт влиять на процесс разрешения имён (хоть в нём она и самая последняя) – выключайте эту возможность. Файл lmhosts.sam должен остаться историей.

    Настройки NetBIOS – что здесь? Для корректной работы контроллера нам нужна поддержка NetBT – реализации стека NetBIOS поверх TCP/IP. Это достигается запуском одноименной системной службы плюс включении NetBT на сетевых интерфейсах, через которые будет идти обращение к ряду функций контроллера домена. По умолчанию эта настройка сделана так – NetBT как бы включен, но по сути – ждёт сигнала от DHCP-сервера, который в пакете с настройками для узла (в расширенной части этого пакета – DHCP-опция по включению/выключению NetBT не стандартная) может сообщать – включать NetBT или нет.

    Проще и лучше (и, в общем-то, строго необходимо – хотя бы потому, что у нас статический адрес, и никаких настроек от DHCP-сервера мы не дождёмся) включать NetBT в явном виде, что мы и делаем.

    Настройки IPv4 завершены. Нажимаем несколько раз кнопку OK и попадаем в окно с перечнем компонентов интерфейса, где выбираем теперь IPv6.

    Настройка IPv6

    Окно выглядит страшно – для адресов – длинные строчки, плюс без разметки на октеты. Это, на самом деле, только хорошо. Адреса сейчас не вводим – оставляем на момент, когда мы будем поднимать второй DC и работать внутри сайта. Переходим к Advanced и видим там 2 вкладки – те же, что и в IPv4, но без WINS. Настройки совершенно такие же, что и выше, поэтому останавливаться не будем.

    Закрываем сетевые настройки и возвращаемся в окно Server Manager.

    Remote Desktop

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

    Server Manager Remote Management

    Это – новая система по удалённому управлению серверной ОС и её компонентами. Ещё известна как WinRM. Сделана на основе глобального стандарта WS-Management, поддерживает версии 1.1 и 2.0. Здесь – в окне Server Manager – мы можем её глобально включить или выключить. То же самое потом мы сможем сделать утилитой winrm. Из использующих её широко известных приложений – например, Microsoft Exchange Server 2010 – его консоль подцепляется к серверной части именно через WS-Management. Пока не включаем – нет смысла, ни на что в ближайшее время не повлияет.

    Из остального – замечу, что ОС пока не проверялась на обновления. Это нужно будет сделать в ближайшее время – как только DNS Server поднимем, так сразу и запустим.

    В общих чертах – узел готов. Открываем пункт Roles, нажимаем Add Roles и видим окно с выбором ролей, где ставим отметку напротив DNS Server:

    image

    Дальше – в следующем разговоре.

    Карманов Руслан

Комментарии

  1. Ну, наконец-то! Руслан, большой респект за труды по написанию статьи. Всегда было приятно слушать прекрасно проработанный материал на курсах по AD, в данной тематике даже в мелочах всегда находились изъяны, которые не раскрывались (детально не описывались) в документации, а теперь есть подробные статьи. Очень радует тема AD R2 как раз то, что нужно.

  2. Руслан, а зачем ставить DNS Server? Ведь при установке AD DS он ставится автоматически…

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

  4. Утверждение “Для FQDN имён стандартными являются строчные буквы.” является спорным. Прокомментируйте пожалуйста детальнее в части ссылок на RFC 2044 (Вы даете рекомендации в контексте win2008, а не WinNT)

  5. > Утверждение «Для FQDN имён стандартными являются строчные буквы.» является спорным

    Верю. Я просто старый – знаю, что и Unicode можно, но всё же строчные буквы гарантируют совместимость с рядом реализаций dns resolver’ов. :). Т.е. говоря проще, преимуществ использования прописных литер нет, а негативные моменты по части совместимости – есть, хоть и редко. Это не такая некрофилия, как, допустим, AXFRом только пользоваться, потому что IXFR не везде есть, а реально возможная ситуация – когда LOCALHOST8.domain.local вызовет вопросы, допустим, у IDS-системы, следящей за форматом и содержимым EDNS0 трафика.

  6. Поправил дизайн, т.к. догадался сразу править статьи в Live Writer. Вроде покрасивее стало.

  7. Блин, а я ждал продолжения предыдущей статьи 🙁
    Может лучше не располяться и дописать ту?

    А эта статья, если честно не очень понравилась: написанно как-то очень сумбурно, постоянно какие-то отступления (скока там абзацев про то как правильно называть сервера?), спорные моменты преподносятся как единственно правильный путь, не понятно на кого статья рассчитана – с одной стороны вроде на людей совсем не знакомых с продуктом, с другой стороны – при этом знающих все остальное кроме AD 🙂
    Ну и очень медленно идет повествование, если бы не живой язык, читать было бы скучно.

  8. Да, еще картинки не увеличиваются – имхо лучше вообще без картинок чем с такими.
    А то, блин, вглядываешся как дурак, хотя там ничего интересного нет 🙂

  9. > Да, еще картинки не увеличиваются

    Это, кстати, странно. Покопаю.

    Продолжение предыдущей статьи никуда не денется – они друг от друга не зависят.

  10. MaximillianGreat, а вот не соглашусь. Во-первых все нравиться всем и не должно. Темы разные, сложность разная. Во-вторых статьи это не MOC-и, тут нет четкого плана и есть творчество при определении подачи и акцентов.

    P.S Ну это так off-topic)

  11. Если запустить DNS Best Practices в Server manager в windows server 2008 R2 – он попросит первым, т.е. Preferred поставить 127.0.0.1 – так что тут вам никакой неопределенности!

  12. > Если запустить DNS Best Practices в Server manager в windows server
    > 2008 R2 — он попросит первым, т.е. Preferred поставить 127.0.0.1

    Хмм, даже, если нет локального DNS-сервера? 🙂

    Скажем точнее – в случае локального DNS-сервера он просит подставить его адрес, а уже функция присвоения адреса DNS-сервера “превращает” его в 127.0.0.1 . То, что это не самый оптимальный вариант – опИсано в этой статье и будет видно из дальнейших.

  13. Руслан,а возможно Вас попросить поподробней на части ipv6 остановится конкретно интересует сама адресация и имена

  14. Иван, дайте свое мыло, я вам кину нормальное описание, оно несколько дней висело на сайте, но по причине пбликации в журнале, временно убрано.

  15. > Ruslan V. Karmanov
    > Хмм, даже, если нет локального DNS-сервера?
    > Скажем точнее — в случае локального DNS-сервера он просит подставить его
    > адрес, а уже функция присвоения адреса DNS-сервера «превращает» его в
    > 127.0.0.1 . То, что это не самый оптимальный вариант — опИсано в этой
    > статье и будет видно из дальнейших.
    Да вы правы. Если в настройках ДНС точно указать на каких адресах прослушиваться запросы (даже если он один), то более адреса 127.0.0.1 он не просит. Век живи – век учись. жду с нетерппением продолжения.
    Так же вы обошли стороной протоколы канального уровня – зачем они?
    Почему начиная с 2008 сервера в сетевом окружении нет деления на домены, как это было в NT 2k 2к3?
    > Ilya Rud
    И мне тоже скиньте статью про ipv6, если не трудно.

  16. Микас куда? Кому нужно киньте запрос мне на мыло irud@live.ru

  17. Уважаемый Илья!
    Готовлюсь сейчас к Cisco экзамену по ipv6.
    Не откажусь почитать на эту у тему. Если не жалко-p921k@ya.ru

  18. > Готовлюсь сейчас к Cisco экзамену по ipv6.

    Экзамен – по курсу BSCI?

  19. И еще господа критики-харе критиковать, тут документировать свою сеть еле-еле себя заставляешь. А люди(причем тренеры) статьи умные пишут. Критики, напишите лучше.

  20. Иванов Дмитрий, ну не знаю насколько она вам поможет, но кинул. Я не цискарь поэтому там самые основы.

  21. > Почему начиная с 2008 сервера в сетевом окружении нет деления на домены, > как это было в NT 2k 2к3?

    Кстати к чему это я спросил? А вот к чемуЁ! Насколько я понял протоколы канального сканируют всю локальную сеть и строят её топологию. Конечно же не так красиво как в 2к3 🙁 – т.е. без доменов.
    И это очень не удобно, когда есть сеть университета, к примеру, где каждый домен в своём лесу и если нужно настраиваются доверия. Так вот в такой ситуации сетевое окружение выглядит как каша из сетевых устройств.

  22. Про фото ржачно придумал… а в остальном – ничего нового

  23. Очень нужный цикл статей, продолжайте еще.

  24. Рассуждения про наименования серверов не в соответствии с их функциональным назначением в наш век виртуализации… Очень спорно
    Как и принудительное включение netbios для инфраструтуры с AD.

    А так, очень хороший стиль изложения.

  25. жаль нету кнопочки скачать статью в PDF/ 😉

  26. Будет когда серия полностью соберется. Нет смысла плодить 10 файлов.

  27. Илья, спасибо – тема нужная. Систематизация знаний не менее важна, чем их накопление, поэтому буду читать с интересом.
    P.S. Касательно картинок и Одри Хэпбёрн – Vadims Podans (сисадминс.лв) пошёл дальше, у него на главной блога есть ссылка на оф.сайт Теры Патрик 🙂

  28. Руслан спасибо, очень инетерсно. Жду продолжения.

  29. Пока Руслан делает продолжение, советую почитать Active Directory — трудности перевода. Три части. Искать здесь: http://itband.ru/tag/active-directory/

  30. >MaximillianGreat, а вот не соглашусь. Во-первых все нравиться всем и не должно. Темы разные, сложность разная. Во-вторых статьи это не MOC-и, тут нет четкого плана и есть творчество при определении подачи и акцентов.

    С тем что статья мне не обязанна нравится, я согласен. Просто автор не против критики со стороны 🙂

    А вот насчёт “творчества” не согласен, им в технических статьях черезчур увлекаться не стоит. Иначе надо будет сверху писть “фантастическая повесть”.

  31. *не против = вроде не против

  32. MaximillianGreat, ок) согласен.

    З.Ы Форум надо пилить быстрее, комментарии стали неприлично разрастаться.

  33. Хорошая статья, на нее меня навел Олег Крылов.
    Единственное, что поразило – крмво обрезанные скриншоты.
    Вы же сертифицированный тренер – неужели вам незнакомо сочетание клавиш – Alt+PrtScr ?

  34. Сертифицированным тренерам запрещено пользоваться “Alt+PrtScr”. Это одно из условий которые они принимают в Редмонде перед принятие клятвы Биллократа. ))

  35. Почему у меня не отображаются картинки в тексте статьи. IE-8

  36. У меня отображается. IE-8

  37. Одри Хепберн! Замечательный выбор!

  38. Комментарий к введению.

    Забавно и то, что второе издание “AD: подход профессионала, издание 2-е дополненное” и “AD: миграция на платформу Microsoft Windows Server 2003” по сути есть точно такое же наслоение на действительно серьезную работу по Windows 2000 самого же автора.

  39. И где продолжение?

  40. У данного персоонажа все “великие” проекты обычно заканчиваются не начавшись. Этот не стал исключением.

  41. что за муть??? фтопку

  42. Спасибо за новость! Как раз думал об этом! Кстати с Новым годом всех вас

    vacation to maldives

  43. Боже … для кого написана эта статья?
    Настройки сетевого интерфейса можно было описать одним скрином, с кратким описанием.

    Автор же засыпал терминами без их разъяснения: external trust, Lan Manager, ISTG, KCC, NBNS, FRS, DFS, SMB, PKI, Link-local, AS, ASCII, FQDN, DMZ, QoS PS, Reliable Multicast Protocol (который PGM – Pragmatic General Multicast),FHR (First Hop Redundancy) – HSRP, FHRP, VRRP, GLBP, half-duplex, full-duplex, DNS Resolver, LMHOSTS, WINS, WS-Management.

    Человек только начал практическое знакомство с AD а тут такое =)
    TechNet читается легче.

    Не хотел никого обидеть, но надо понимать что человек читающий данную статью еще не получил сертификат MCT =D

  44. Не нужно путать понятия уважаемый автор, из-за таких как вы у начинающих админов складывается неправильное понятие об AD. Вы утверждаете:

    1. Основная служба авторизации, работающая на базе модифицированной версии протокола Kerberos v5.
    2. Вторичная служба авторизации, использующая протоколы семейства Lan Manager.
    Ну, иногда она не вторичная, а основная, потому что протокол Kerberos не обрабатывает 100% ситуаций авторизации. Иначе бы Lan Manager можно было бы совсем выключить, что не реализуемо, да и не нужно.

    Kerberos – это не авторизация.

    http://ru.wikipedia.org/wiki/Kerberos

    Kerberos /kɛərbərəs/ — сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию — оба пользователя через сервер подтверждают личности друг друга.

    Перестаньте писать статьи вводящие в заблуждение, учите мат. часть.