Роли пользователей windows server

При установке Windows большая часть второстепенных подсистем не активируется или не устанавливается. Это сделано по причинам безопасности. Поскольку система по умолчанию защищена, системные администраторы могут сосредоточиться на проектировании системы, которая будет выполнять исключительно возложенные на нее функции и ничего лишнего. Для помощи при включении нужных функций, Windows предлагает выбрать роль сервера (Server Role).

Роли

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

• Они определяют основную функцию, назначение или цель использования компьютера. Можно назначить компьютер для выполнения одной роли, которая интенсивно используется на предприятии, или для выполнения нескольких ролей, если каждая из них применяется лишь изредка.
• Роли предоставляют пользователям во всей организации доступ к ресурсам, которые управляются другими компьютерами, таким как веб-сайты, принтеры или файлы, хранящиеся на разных компьютерах.
• Они обычно имеют собственные базы данных, в которых создаются очереди запросов пользователя или компьютера либо записываются сведения о сетевых пользователях и компьютерах, имеющих отношение к роли. Например, Службы домена Active Directory содержат базу данных для хранения имен и иерархических связей всех компьютеров в сети.
• После правильной установки и настройки роли функционируют автоматически. Это позволяет компьютерам, на которых они установлены, выполнять назначенные задачи при ограниченном участии пользователя.

Службы ролей

Службы ролей — это программы, которые обеспечивают функциональные возможности роли. При установке роли можно выбрать, какие службы она предоставляет другим пользователям и компьютерам на предприятии. Некоторые роли, такие как DNS-сервер, выполняют только одну функцию, поэтому для них нет служб ролей. Другие роли, такие как службы удаленных рабочих столов, имеют несколько служб, которые можно установить в зависимости от потребностей предприятия в удаленном доступе. Роль можно рассматривать как совокупность тесно связанных, взаимодополняющих служб ролей. В большинстве случаев установка роли означает установку одной или нескольких ее служб.

Компоненты

Компоненты — это программы, которые не являются непосредственно частями ролей, но поддерживают или расширяют функции одной или нескольких ролей либо целого сервера независимо от того, какие роли установлены. Например, компонент «Средство отказоустойчивости кластеров» расширяет функции других ролей, таких как Файловые службы и DHCP-сервер, позволяя им присоединяться к серверным кластерам, что обеспечивает повышенную избыточность и производительность. Другой компонент — «Клиент Telnet» — обеспечивает удаленную связь с сервером Telnet через сетевое подключение. Эта функция расширяет возможности связи для сервера.

Когда Windows Server работает в режиме основных серверных компонентов, поддерживаются следующие роли сервера:

• службы сертификатов Active Directory;
• доменные службы Active Directory;
• DHCP-сервер;
• DNS-сервер;
• файловые службы (в том числе диспетчер ресурсов файлового сервера);
• службы Active Directory облегченного доступа к каталогам;
• Hyper-V;
• службы печати и документов;
• службы потокового мультимедиа;
• веб-сервер (в том числе подмножество ASP.NET);
• сервер обновления Windows Server;
• сервер управления правами Active Directory;
• сервер маршрутизации и удаленного доступа и следующие подчиненные роли:
  • посредник подключений служб удаленных рабочих столов;
  • лицензирование;
  • виртуализация.

Когда Windows Server работает в режиме основных серверных компонентов, поддерживаются следующие компоненты сервера:

• Microsoft .NET Framework 3.5;
• Microsoft .NET Framework 4.5;
• Windows PowerShell;
• фоновая интеллектуальная служба передачи (BITS);
• шифрование диска BitLocker;
• сетевая разблокировка BitLocker;
• BranchCache
• мост для центра обработки данных;
• Enhanced Storage;
• отказоустойчивая кластеризация;
• Multipath I/O;
• балансировка сетевой нагрузки;
• протокол PNRP;
• qWave;
• удаленное разностное сжатие;
• простые службы TCP/IP;
• RPC через HTTP-прокси;
• сервер SMTP;
• служба SNMP;
• клиент Telnet;
• сервер Telnet;
• клиент TFTP;
• внутренняя база данных Windows;
• Windows PowerShell Web Access;
• служба активации Windows;
• стандартизированное управление хранилищами Windows;
• расширение IIS WinRM;
• WINS-сервер;
• поддержка WoW64.

Установка ролей сервера с помощью Server Manager

Для добавления открываем Server Manager, и в меню Manage жмем Add Roles and features:

Картинка с сайта: firstvds.ru

Откроется мастер добавления ролей и компонентов. Жмем Next

Картинка с сайта: firstvds.ru

Installation Type, выбираем Role-based or feature-based installation. Next:

Картинка с сайта: firstvds.ru

Server Selection — выбираем наш сервер. Жмем Next Server Roles — Выберите роли, если необходимо, выберите службы ролей и нажмите кнопку Next, чтобы выбрать компоненты. В ходе этой процедуры Мастер добавления ролей и компонентов автоматически информирует о возникших конфликтах на конечном сервере, которые могут помешать установке или нормальной работе выбранных ролей или компонентов. Также появляется запрос на добавление ролей, служб ролей и компонентов, необходимых для выбранных ролей или компонентов.

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

Открываем Windows PowerShell Вводим команду Get-WindowsFeature, чтобы просмотреть список доступных и установленных ролей и компонентов на локальном сервере. Результаты выполнения этого командлета содержат имена команд для ролей и компонентов, установленных и доступных для установки.

Картинка с сайта: firstvds.ru

Введите Get-Help Install-WindowsFeature для просмотра синтаксиса и допустимых параметров командлета Install-WindowsFeature (MAN).

Картинка с сайта: firstvds.ru

Вводим следующую команду (-Restart перезагрузит сервер, если при установке роли требуется перезагрузка).

Install-WindowsFeature –Name <feature_name> -Restart

Описание ролей и служб ролей

Ниже описаны все роли и службы ролей. Расширенную настройку посмотрим для самых часто встречающихся в нашей практике Web Server Role и Remote Desktop Services

Подробное описание IIS

Картинка с сайта: firstvds.ru

• Common HTTP Features — Основные HTTP компоненты
  • Default Document — позволяет устанавливать индексную страницу у сайта.
  • Directory Browsing — позволяет пользователям видеть содержимое каталога на веб-сервере. Используйте Directory Browsing для того, чтобы автоматически сгенерировать список всех каталогов и файлов, имеющихся в каталоге, когда пользователи не указывают файл в URL-адресе и индексная страница отключена или не настроена
  • HTTP Errors — позволяет настроить сообщения об ошибках, возвращаемых клиентам в браузере.
  • Static Content — позволяет размещать статический контент, например, картинки или html-файлы.
  • HTTP Redirection — обеспечивает поддержку перенаправления запросов пользователей.
  • WebDAV Publishing позволяет публиковать файлы с веб-сервера с помощью протокола HTTP.
• Health and Diagnostics Features — Компоненты диагностики
  • HTTP Logging обеспечивает ведение журнала активности веб-сайта для данного сервера.
  • Custom Logging обеспечивает поддержку создания кастомных логов, которые отличаются от “традиционных” журналов.
  • Logging Tools обеспечивает инфраструктуру для управления журналами веб-сервера и автоматизации общих задач ведения журнала.
  • ODBC Logging обеспечивает инфраструктуру, которая поддерживает ведение журнала активности веб-сервера в ODBC-совместимой базе данных.
  • Request Monitor предоставляет инфраструктуру для мониторинга состояния веб-приложений путем сбора информации о HTTP-запросах в рабочем процессе IIS.
  • Tracing предоставляет инфраструктуру для диагностики и устранения неполадок веб-приложений. При использовании трассировки неудачных запросов, вы можете отследить трудно-фиксируемые события, такие как плохая производительность или сбои аутентификации.
• Performance компоненты увеличения производительности веб-сервера.
  • Static Content Compression предоставляет инфраструктуру для настройки HTTP-сжатия статического содержимого
  • Dynamic Content Compression предоставляет инфраструктуру для настройки HTTP-сжатия динамического содержимого.
• Security компоненты безопасности
  • Request Filtering позволяет фиксировать все входящие запросы и фильтровать их на основании правил, установленных администратором.
  • Basic Authentication позволяет установить дополнительную авторизацию
  • Centralized SSL Certificate Support это функция, которая позволяет хранить сертификаты в централизованном месте, как общий файловый ресурс.
  • Client Certificate Mapping Authentication использует клиентские сертификаты для аутентификации пользователей.
  • Digest Authentication работает путем отправки хэша пароля в контроллер домена Windows, для аутентификации пользователей. Если вам необходимо более высокий уровень безопасности по сравнению с обычной проверкой подлинности, рассмотрите вопрос об использовании проверки подлинности Digest
  • IIS Client Certificate Mapping Authentication использует клиентские сертификаты для аутентификации пользователей. Сертификат клиента представляет собой цифровой ID, полученный из надежного источника.
  • IP and Domain Restrictions позволяет разрешать/запрещать доступ на основе запрашиваемого Ip-адреса или доменного имени.
  • URL Authorization позволяет создавать правила, ограничивающие доступ к веб-контенту.
  • Windows Authentication Эта схема аутентификации позволяет администраторам домена Windows пользоваться преимуществами доменной инфраструктуры для аутентификации пользователей.
• Application Development Features компоненты разработки приложений
• FTP Server
  • FTP Service Включает FTP публикации на веб-сервере.
  • FTP Extensibility Включает поддержку FTP функций, расширяющих возможности
• Management Tools инструменты управления
  • IIS Management Console устанавливает диспетчер IIS, который позволяет управлять Веб-сервером через графический интерфейс
  • IIS 6.0 Management Compatibility обеспечивает прямую совместимость для приложений и сценариев, которые используют Admin Base Object (ABO) и интерфейса службы каталогов (ADSI) API Active Directory. Это позволяет использовать существующие сценарии IIS 6.0 веб-сервером IIS 8.0
  • IIS Management Scripts and Tools предоставляют инфраструктуру для управления веб-сервером IIS программно, с помощью команд в окне командной строки или с помощью запуска сценариев.
  • Management Service предоставляет инфраструктуру для настройки интерфейса пользователя, диспетчера IIS.

Подробное описание RDS

Картинка с сайта: firstvds.ru

• Remote Desktop Connection Broker — Обеспечивает повторное подключение клиентского устройства к программам, на основе сеансов настольных компьютеров и виртуальных рабочих столов.
• Remote Desktop Gateway — Позволяет авторизованным пользователям подключаться к виртуальным рабочим столам, программам RemoteApp и основанных на сессиях рабочим столам в корпоративной сети или через Интернет.
• Remote Desktop Licensing — Средство управления лицензиями RDP
• Remote Desktop Session Host — Включает сервер для размещения программ RemoteApp или сеанса на основе рабочих столов.
• Remote Desktop Virtualization Host — позволяет настраивать RDP на виртуальных машинах
• Remote Desktop WebAccess — Позволяет пользователям подключаться к ресурсам рабочего стола с помощью меню Пуск или веб-браузера.

Рассмотрим установку и настройку сервера терминальных лицензий. Выше рассказано как устанавливать роли, установка RDS не отличается от установки других ролей, в Role Services нам потребуется выбрать Remote Desktop Licensing и Remote Desktop Session Host. После установки в Server Manager-Tools появится пункт Terminal Services. В Terminal Services есть два пункта RD Licensing Diagnoser, это средство диагностики работы лицензирования удаленных рабочих столов, и Remote Desktop Licensing Manager, это средство управления лицензиями.

Запустим RD Licensing Diagnoser

Картинка с сайта: firstvds.ru

Здесь мы видим, что доступных лицензий пока нет, т. к. не задан режим лицензирования для сервера узла сеансов удаленных рабочих столов. Сервер лицензирования указывается в локальных групповых политиках. Для запуска редактора выполним команду gpedit.msc. Откроется редактор локальной групповой политики. В дереве слева раскроем вкладки:

• «Конфигурация компьютера» (Computer Configuration)
• «Административные шаблоны» (Administrative Templates)
• «Компоненты Windows» (Windows Components)
• «Службы удаленных рабочих столов» (Remote Desktop Services)
• «Узел сеансов удаленных рабочих столов» (Remote Desktop Session Host)
• «Лицензирование» (Licensing)

Откроем параметры Use the specified Remote Desktop license servers

Картинка с сайта: firstvds.ru

В окне редактирования параметров политики включаем сервер лицензирования (Enabled) . Затем необходимо определить сервер лицензирования для службы удаленных рабочих столов. В моем примере сервер лицензирования находится на этом же физическом сервере. Указываем сетевое имя или IP-адрес сервера лицензий и нажимаем OK. Если в дальнейшем будет изменяться имя сервера, сервер лицензий, то потребуется изменить в этом же разделе.

Картинка с сайта: firstvds.ru

После этого в RD Licensing Diagnoser можно увидеть, что сервер терминальных лицензий настроен, но не включен. Для включения запускаем Remote Desktop Licensing Manager

Картинка с сайта: firstvds.ru

Выбираем сервер лицензирования, со статусом Not Activated . Для активации кликаем по нему правой кнопкой мыши и выбираем Activate Server. Запустится Мастер активации сервера. На вкладке Connection Method выбираем Automatic Connection. Далее заполняем информация об организации, после этого сервер лицензий активирован.

Active Directory Certificate Services

Службы AD CS предоставляют настраиваемые услуги по выдаче цифровых сертификатов, которые используются в системах безопасности ПО, применяющих технологии открытых ключей, и по управлению этими сертификатами. Цифровые сертификаты, предоставляемые AD CS, можно использовать для шифрования и цифрового подписывания электронных документов и сообщений.Эти цифровые сертификаты можно использовать для проверки в сети подлинности учетных записей компьютеров, пользователей и устройств.Цифровые сертификаты используются для обеспечения:

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

AD CS можно использовать для повышения безопасности путем привязки удостоверения пользователя, устройства или службы к соответствующему закрытому ключу. В число применений, поддерживаемых AD CS, входят безопасные многоцелевые расширения стандарта почты Интернета (S/MIME), защищенные беспроводные сети, виртуальные частные сети (VPN), протокол IPsec, шифрованная файловая система (EFS), вход с помощью смарт-карт, протокол безопасности передачи данных и протокол безопасности транспортного уровня (SSL/TLS) и цифровые подписи.

Active Directory Domain Services

Используя роль сервера доменных служб Active Directory (AD DS), можно создать масштабируемую, безопасную и управляемую инфраструктуру для управления пользователями и ресурсами; кроме того, можно обеспечить работу приложений, поддерживающих каталоги, например Microsoft Exchange Server. Доменные службы Active Directory предоставляют распределенную базу данных, в которой хранятся сведения о сетевых ресурсах и данные приложений с поддержкой каталогов, а также осуществляется управление этой информацией. Сервер, на котором выполняются AD DS, называется контроллером домена. Администраторы могут использовать AD DS для упорядочения в иерархическую вложенную структуру таких элементов сети, как пользователи, компьютеры и другие устройства. Иерархическая вложенная структура включает лес Active Directory, домены в лесу и организационные подразделения в каждом домене. Средства безопасности интегрированы в AD DS в виде проверки подлинности и контроля доступа к ресурсам в каталоге. С помощью единого входа в сеть администраторы могут управлять по сети данными каталога и организацией. Авторизованные пользователи сети также могут использовать единый вход в сеть для доступа к ресурсам, расположенным в любом месте сети. Доменные службы Active Directory предоставляют следующие дополнительные возможности.

• Набор правил — схема, определяющая классы объектов и атрибуты, которые содержатся в каталоге, ограничения и пределы для экземпляров этих объектов, а также формат их имен.
• Глобальный каталог, содержащий сведения о каждом объекте в каталоге. Пользователи и администраторы могут использовать глобальный каталог для поиска данных каталога независимо от того, какой домен в каталоге действительно содержит искомые данные.
• Механизм запросов и индексирования, благодаря которому объекты и их свойства могут публиковаться и находиться сетевыми пользователями и приложениями.
• Служба репликации, которая распределяет данные каталога по сети. Все контроллеры домена, доступные для записи в домене, участвуют в репликации и содержат полную копию всех данных каталога для своего домена. Любые изменения данных каталога реплицируются в домене на все контроллеры домена.
• Роли хозяев операций (известные также как гибкие операции с единым хозяином, или FSMO). Контроллеры доменов, исполняющие роли хозяев операций, предназначены для выполнения специальных задач по обеспечению согласованности данных и исключению конфликтующих записей в каталоге.

Active Directory Federation Services

AD FS предоставляют конечным пользователям, которым требуется доступ к приложениям на защищенном с помощью AD FS предприятии, в партнерских организациях федерации или в облаке, возможности упрощенной и безопасной федерации удостоверений и веб-службы единого входа (SSO) В Windows Server AD FS включают службу роли службы федерации, действующую в качестве поставщика удостоверений (выполняет проверку подлинности пользователей для предоставления маркеров безопасности для приложений, доверяющих AD FS) или в качестве поставщика федерации (применяет маркеры от других поставщиков удостоверений и затем предоставляет маркеры безопасности для приложений, доверяющих AD FS).

Active Directory Lightweight Directory Services

Службы Active Directory облегченного доступа к каталогам (AD LDS) — это протокол LDAP, который обеспечивает гибкую поддержку приложений, работающих с каталогами, без зависимостей и связанных с доменами ограничений доменных служб Active Directory. AD LDS можно запускать на рядовых или изолированных серверах. На одном сервере можно запустить несколько экземпляров AD LDS с независимо управляемыми схемами. С помощью роли службы AD LDS можно предоставить службы каталогов для приложений с поддержкой каталогов, не используя служебные данные доменов и лесов и не требуя единой схемы для всего леса.

Active Directory Rights Management Services

Службы AD RMS можно использовать, чтобы расширить стратегию безопасности в организации, обеспечив защиту документов с помощью управления правами на доступ к данным (IRM). AD RMS позволяет пользователям и администраторам назначать разрешения доступа к документам, рабочим книгам и презентациям с помощью политик IRM. Это позволяет защитить конфиденциальную информацию от печати, пересылки или копирования пользователями, не имеющими на это прав. После того как разрешения для файла ограничены с помощью IRM, ограничения доступа и использования применяются независимо от местоположения информации, так как разрешение для файла хранится в самом файле документа. С помощью AD RMS и IRM отдельные пользователи могут применять свои личные настройки, касающиеся передачи личных и конфиденциальных сведений. Они также помогут организации применять корпоративную политику для управления использованием и распространением конфиденциальных и личных сведений. Решения IRM, поддерживаемые службами AD RMS, используются для обеспечения следующих возможностей.

• Постоянные политики использования, которые остаются с информацией независимо от ее перемещения, отправки или пересылки.
• Дополнительный уровень конфиденциальности для защиты конфиденциальных данных — например, отчетов, спецификаций продуктов, сведений о клиентах и сообщений электронной почты — от намеренного или случайного попадания в чужие руки.
• Предотвращение несанкционированной пересылки, копирования, изменения, печати, передачи по факсу или вставки ограничиваемого содержимого авторизованными получателями.
• Предотвращение копирования ограничиваемого содержимого с помощью функции PRINT SCREEN в Microsoft Windows.
• Поддержка срока действия файла, предотвращающего просмотр содержимого документов по истечении заданного периода времени.
• Внедрение корпоративных политик, управляющих использованием и распространением содержимого в организации

Application Server

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

DHCP Server

DHCP — это технология «клиент-сервер», с помощью которой DHCP-серверы могут назначать или сдавать в аренду IP-адреса компьютерам и другим устройствам, являющимся DHCP-клиентами.Развертывание в сети DHCP-серверов обеспечивает автоматическое предоставление клиентским компьютерам и другим сетевым устройствам на базе IPv4 и IPv6 действительных IP-адресов и дополнительных конфигурационных параметров, необходимых данным клиентам и устройствам.Служба DHCP-сервера в Windows Server включает поддержку основанных на политике назначений и обработку отказов протокола DHCP.

DNS Server

Служба DNS — это иерархическая распределенная база данных, содержащая сопоставления доменных имен DNS с различными типами данных, таких как IP-адреса. Служба DNS позволяет использовать понятные имена, такие как www.microsoft.com, для облегчения нахождения компьютеров и других ресурсов в сетях, работающих на базе протокола TCP/IP. Служба DNS в Windows Server обеспечивает дополнительную улучшенную поддержку Модулей безопасности DNS (DNSSEC), включая регистрацию в сети и автоматизированное управление параметрами.

FAX Server

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

File and Storage Services

Администраторы могут использовать роль «Файловые службы и службы хранилища» для настройки нескольких файловых серверов и их хранилищ, а также для управления этими серверами с помощью диспетчера серверов или Windows PowerShell. Некоторые конкретные приложения включают следующие функции.

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

Hyper-V

Роль Hyper-V позволяет создавать виртуализованную вычислительную среду с помощью технологии виртуализации, встроенной в Windows Server, и управлять ею. При установке роли Hyper-V выполняется установка необходимых компонентов, а также необязательных средств управления. В число необходимых компонентов входят низкоуровневая оболочка Windows, служба управления виртуальными машинами Hyper-V, поставщик виртуализации WMI и компоненты виртуализации, такие как шина VMbus, поставщик службы виртуализации (VSP) и драйвер виртуальной инфраструктуры (VID).

Network Policy and Access Services

Службы сетевой политики и доступа предоставляют следующие решения для сетевых подключений:

• Защита доступа к сети — это технология создания, принудительного применения и исправления политик работоспособности клиента. С помощью защиты доступа к сети системные администраторы могут устанавливать и автоматически применять политики работоспособности, которые включают в себя требования к программному обеспечению, обновлениям для системы безопасности и другие параметры. Для клиентских компьютеров, не соответствующих требованиям политики работоспособности, можно ограничить доступ к сети до тех пор, пока их конфигурация не будет обновлена в соответствии с требованиями политики.
• Если развернуты точки беспроводного доступа с поддержкой 802.1X, вы можете использовать сервер политики сети (NPS) для развертывания методов аутентификации на основе сертификатов, которые более безопасны, чем аутентификация на основе паролей. Развертывание оборудования с поддержкой 802.1X с сервером NPS позволяет обеспечить аутентификацию пользователей интрасети до того, как они смогут подключиться к сети или получить IP-адрес от DHCP-сервера.
• Вместо того чтобы настраивать политику доступа к сети на каждом сервере доступа к сети, можно централизованно создать все политики, в которых будут определены все аспекты запросов на сетевое подключение (кто может подключаться, когда разрешено подключение, уровень безопасности, который необходимо использовать для подключения к сети).

Print and Document Services

Службы печати и документов позволяют централизовать задачи сервера печати и сетевого принтера. Эта роль также позволяет получать отсканированные документы с сетевых сканеров и передавать документы в общие сетевые ресурсы — на сайт Windows SharePoint Services или по электронной почте.

Remote Access

Роль сервера удаленного доступа представляет собой логическую группу следующих технологий сетевого доступа.

• DirectAccess
• Маршрутизация и удаленный доступ
• Прокси-сервер веб-приложения

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

Картинка с сайта: firstvds.ru

В Windows Server роль сервера удаленного доступа обеспечивает возможность централизованного администрирования, настройки и наблюдения за службами удаленного доступа DirectAccess и VPN со службой маршрутизации и удаленного доступа (RRAS). DirectAccess и RRAS можно развернуть на одном пограничном сервере и управлять ими с помощью команд Windows PowerShell и консоли управления (MMC) удаленного доступа.

Remote Desktop Services

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

Volume Activation Services

Службы активации корпоративных лицензий — это роль сервера в Windows Server начиная с Windows Server 2012, которая позволяет автоматизировать и упростить выдачу корпоративных лицензий на программное обеспечение Microsoft, а также управление такими лицензиями в различных сценариях и средах. Вместе со службами активации корпоративных лицензий можно установить и настроить службу управления ключами (KMS) и активацию с помощью Active Directory.

Web Server (IIS)

Роль веб-сервера (IIS) в Windows Server обеспечивает платформу для размещения веб-узлов, служб и приложений. Использование веб-сервера обеспечивает доступ к информации пользователям в Интернете, интрасети и экстрасети. Администраторы могут использовать роль веб-сервера (IIS) для настройки и управления несколькими веб-сайтами, веб-приложениями и FTP-сайтами. В число специальных возможностей входят следующие.

• Использование диспетчера служб IIS для настройки компонентов IIS и администрирования веб-сайтов.
• Использование протокола FTP для разрешения владельцам веб-сайтов отправлять и загружать файлы.
• Использование изоляции веб-сайтов для предотвращения влияния одного веб-сайта на сервере на остальные.
• Настройка веб-приложений, разработанных с использованием различных технологий, таких как Classic ASP, ASP.NET и PHP.
• Использование Windows PowerShell для автоматического управления большей частью задач администрирования веб-сервера.
• Объединение нескольких веб-серверов в ферму серверов, которой можно управлять с помощью IIS.

Windows Deployment Services

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

Windows Server Essentials Experience

Данная роль позволяет решать следующие задачи:

• защищать данные сервера и клиентов, создавая резервные копии сервера и всех клиентских компьютеров в сети;
• управлять пользователями и группами пользователей через упрощенную панель мониторинга сервера. Кроме того, интеграция с Windows Azure Active Directory *обеспечивает пользователям простой доступ к интернет-службам Microsoft Online Services (например, Office 365, Exchange Online и SharePoint Online) с помощью их учетных данных домена;
• хранить данные компании в централизованном месте;
• интегрировать сервер с интернет-службами Microsoft Online Services (например, Office 365, Exchange Online, SharePoint Online и Windows Intune):
• использовать на сервере функции повсеместного доступа (например, удаленный веб-доступ и виртуальные частные сети) для доступа к серверу, компьютерам сети и данным из удаленных расположений с высокой степенью безопасности;
• получать доступ к данным из любого места и с любого устройства с помощью собственного веб-портала организации (посредством удаленного веб-доступа);
• управлять мобильными устройствами, с которых осуществляется доступ к электронной почте организации с помощью Office 365 посредством протокола Active Sync, из панели мониторинга;
• отслеживать работоспособность сети и получать настраиваемые отчеты о работоспособности; отчеты можно создавать по требованию, настраивать и отправлять по электронной почте определенным получателям.

Windows Server Update Services

Сервер WSUS предоставляет компоненты, которые необходимы администраторам для управления обновлениями и их распространения через консоль управления. Кроме того, сервер WSUS может быть источником обновлений для других серверов WSUS в организации. При реализации служб WSUS хотя бы один сервер служб WSUS в сети должен быть подключен к Центру обновления Майкрософт для получения информации о доступных обновлениях. В зависимости от безопасности сети и ее конфигурации администратор может определить, сколько других серверов напрямую подключено к Центру обновления Майкрософт.

Если нужно создать удаленное подключение для нескольких пользователей, то сперва необходимо настроить терминальный сервер на Windows Server. Он позволит предоставлять ровно такое количество мощностей, которое требуется для решения конкретной задачи – например, для работы с 1С или CRM.

Настройка в версиях Windows Server 2012, 2016, 2019 выполняется по одному алгоритму. 

Базовая настройка терминального сервера

Сначала проверим имя рабочей группы и описание компьютера.

1. Открываем «Панель управления», переходим в раздел «Система».
2. Нажимаем «Изменить параметры».
3. На вкладке «Имя компьютера» смотрим, как он идентифицируется в сети. Если имя компьютера или рабочей группы слишком сложное, нажимаем «Изменить» и задаем другие идентификаторы. Для применения нужно перезагрузить систему.

После проверки имени смотрим и при необходимости меняем сетевые настройки. В «Панели управления» открываем раздел «Сетевые подключения».

Картинка с сайта: timeweb.com

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

Добавление ролей и компонентов

Открываем меню «Пуск» и запускаем «Диспетчер серверов». Далее:

1. Нажимаем «Добавить роли и компоненты».
2. Выбираем пункт «Установка ролей или компонентов».
   

   Картинка с сайта: timeweb.com

3. Выбираем сервер из пула серверов.
4. В разделе «Роли сервера» отмечаем DHCP-сервер, DNS-сервер, доменные службы Active Directory, службы удаленных рабочих столов.
   

   Картинка с сайта: timeweb.com

5. В разделе «Службы ролей» отмечаем лицензирование удаленных рабочих столов, узел сеансов удаленных рабочих столов и шлюз удаленных рабочих столов.
   

   Картинка с сайта: timeweb.com

6. Нажимаем «Далее» до раздела «Подтверждение». Здесь нажимаем «Установить».

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

Картинка с сайта: timeweb.com

Настройка конфигурации развертывания

Теперь нужно настроить корневой домен:

1. В мастере настройки доменных служб Active Directory выбираем операцию добавления нового леса и указываем имя корневого домена. Оно может быть любым.
2. В разделе «Параметры контроллера» придумываем и подтверждаем пароль. 
3. Проходим до раздела «Дополнительные параметры». Указываем имя NetBIOS, если его там нет.
4. Проходим до раздела «Проверка предварительных требований». Если проверка готовности пройдена, нажимаем «Установить». Если нет, устраняем недостатки.
   

   Картинка с сайта: timeweb.com

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

Настройка зоны обратного просмотра

В «Диспетчере серверов» раскрываем список средств и выбираем DNS. Далее:

1. Нажимаем «Зона обратного просмотра» – «Создать новую зону».
2. Выделяем пункт «Основная зона».
3. Выбираем режим «Для всех DNS-серверов, работающих на контроллере домена в этом домене».
4. Выбираем зону обратного просмотра IPv4.
5. Указываем идентификатор сети – часть IP адресов, которые принадлежат этой зоне.
6. Нажимаем «Готово» для применения конфигурации.

Проверить, что все установилось, можно в «Диспетчере DNS».

Настройка DHCP

Возвращаемся в «Диспетчер серверов». Здесь нужно завершить настройку DHCP.

1. Указываем данные для авторизации.
2. Проверяем сводку и нажимаем «Закрыть».
3. После завершения установки снова открываем «Диспетчер серверов» – «Средства» – DHCP.
4. В окне DHCP проходим по пути «Имя сервера» – «IPv4» – «Создать область».
5. Задаем любое имя DHCP.
6. Указываем начальный и конечный IP-адреса для интервала, который будет раздавать сервер.
   

   Картинка с сайта: timeweb.com

7. Выбираем настройку этих параметров сейчас.
8. В окне DHCP переходим по пути «Имя сервера» – «Область» – «Пул адресов». Проверяем, что в списке указан тот диапазон IP-адресов, который мы задали в настройках.

Установка служб удаленных рабочих столов

После настройки DHCP снова открываем «Диспетчер серверов». 

1. Нажимаем «Управление» – «Добавить роли и компоненты».
2. Выбираем установку служб удаленных рабочих столов.
3. В разделе «Тип развертывания» выбираем «Быстрый запуск».
4. В разделе «Сценарий развертывания» выбираем развертывание рабочих столов на основе сеансов.
   

   Картинка с сайта: timeweb.com

5. Отмечаем пункт «Автоматически перезапускать конечный сервер, если это потребуется» и нажимаем «Развернуть».

Настройка лицензирования удаленных рабочих столов Windows

Чтобы сервер работал корректно, нужно настроить службу лицензирования. 

1. Открываем «Диспетчер серверов».
2. Переходим по пути «Средства» – «Remote Desktop Services» – «Диспетчер лицензирования удаленных рабочих столов».
3. Выбираем в списке сервер, кликаем по нему правой кнопкой и нажимаем «Активировать сервер».
4. Нажимаем «Далее» несколько раз, снимаем отметку «Запустить мастер установки лицензий» и затем – «Готово».
5. Снова открываем «Диспетчер серверов». 
6. Переходим в «Службы удаленных рабочих столов».
7. В обзоре развертывания нажимаем на меню «Задачи» и выбираем «Изменить свойства развертывания». 
8. Переходим в раздел «Лицензирование».
9. Выбираем тип лицензии. 
   

   Картинка с сайта: timeweb.com

10. Прописываем имя сервера лицензирования – в данном случае это локальный сервер localhost. Нажимаем «Добавить».
11. Нажимаем «ОК», чтобы применить настройки.

Добавление лицензий

Осталось добавить лицензии.

1. Открываем «Диспетчер серверов».
2. Переходим по пути «Средства» – «Remote Desktop Services» – «Диспетчер лицензирования удаленных рабочих столов». 
3. Кликаем по серверу правой кнопкой и выбираем пункт «Установить лицензии».
4. В мастере установки лицензий выбираем программу, по которой были куплены лицензии.
   

   Картинка с сайта: timeweb.com

5. Указываем номер соглашения и данные лицензии.
6. Применяем изменения.

Чтобы проверить статус лицензирования, открываем «Средства» – «Remote Desktop Services» – «Средство диагностики лицензирования удаленных рабочих столов».

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

Картинка с сайта: timeweb.com

В Windows Server 2012R2/2016/2019 вы можете устанавливать и удалять различные роли и компоненты сервера через графический Server Manager. Однако в большинстве случаев эти же самые операции можно выполнить гораздо быстрее из консоли PowerShell. В этой статье мы рассмотрим особенности управления ролями и компонентами в актуальных версиях Windows Server.

Как вывести все установленные роли и компоненты Windows Server?

Чтобы вывести список всех доступных ролей и компонентов Windows Server используется командлет
Get-WindowsFeature
. Если выполнить его без параметров, появится информация обо всех компонентах.

Как вы видите, отображается название компонента (Display Name), его системное имя (Name) и состояние (Install State: Installed, Available или Removed). Список ролей и компонентов представляет собой дерево со вложенными ролями, которое напоминает то, которые вы видите при установке ролей через графический Server Manager. Для установки и удаления ролей и компонентов через PowerShell, вам нужно знать их системное имя, которое содержится в столбце Name.

Картинка с сайта: winitpro.ru

Вы можете вывести список установленных компонентов сервера:

Get-WindowsFeature | Where-Object {$_. installstate -eq "installed"} | ft Name,Installstate

Судя по скриншоту, данный сервер используется как файловый сервер (роли FileAndStorage-Services, Storage-Services). Большинство оставшихся компонентов используются для управления и мониторинга сервера.

Картинка с сайта: winitpro.ru

Если вы не знаете точно имя роли, можно использовать знаки подстановки. Например, чтобы проверить какие из web компонентов роли IIS установлены, выполните (немного сократим синтаксис):

Get-WindowsFeature -Name web-* | Where installed

Картинка с сайта: winitpro.ru

Вы можете получить список установленных компонентов на удаленном Windows Server:

Get-WindowsFeature -ComputerName msk-prnt1 | Where installed | ft Name,Installstate

Судя по установленным ролям Print-Services и Print-Server, этот сервер используется в качестве сервера печати.

Картинка с сайта: winitpro.ru

Вы можете использовать командлет Get-WindowsFeature для поиска серверов в домене, на которых установлена определенная роль. Вы можете искать на серверах в определенном OU Active Directory с помощью командлета Get-ADComputer из модуля ActiveDirectory for PowerShell, или по указанному списку серверов (
$servers = ('server1', 'server2')
). Например, нам нужно найти все файловые сервера c ролью FileAndStorage-Services в указанном контейнере AD (я использую редактор PS — Visual Studio Code)

import-module activedirectory
$Servers=get-adcomputer -properties * -Filter {Operatingsystem -notlike "*2008*" -and enabled -eq "true" -and Operatingsystem -like "*Windows Server*"} -SearchBase ‘OU=Servers,OU=MSK,DC=winitpro.ru,DC=ru’ |select name
Foreach ($server in $Servers)
{
Get-WindowsFeature -name FileAndStorage-Services -ComputerName $server.Name | Where installed | ft $server.name, Name, Installstate
}

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

Картинка с сайта: winitpro.ru

Установка ролей и компонентов Windows Server из PowerShell

Для установки ролей и компонентов в Windows Server используется командлет Install-WindowsFeature.

Чтобы установить роль DNS на текущем сервере и инструменты управления (в том числе модуль Powershell – DNSServer), выполните:

Install-WindowsFeature DNS -IncludeManagementTools

По-умолчанию командлет устаналивает все необходимые зависимые роли и компоненты при установке роли. Чтобы вывести список зависимостей до установки воспользуйтесь параметров.
Install-WindowsFeature -name UpdateServices -whatif

Например, для установки роли сервера обновлений WSUS, необходимо установить некоторые компоненты IIS.

What if: Continue with installation?
What if: Performing installation for "[Windows Server Update Services] Windows Server Update
What if: Performing installation for "[Windows Server Update Services] WID Database".
What if: Performing installation for "[Windows Server Update Services] WSUS Services".
What if: Performing installation for "[Web Server (IIS)] Windows Authentication".
What if: Performing installation for "[Web Server (IIS)] Dynamic Content Compression".
What if: Performing installation for "[Web Server (IIS)] Performance".
What if: Performing installation for "[Web Server (IIS)] Static Content".
What if: Performing installation for "[Windows Internal Database] Windows Internal Database".
What if: The target server may need to be restarted after the installation completes.

Чтобы установить роль Remote Desktop Session Host, службу лицензирования RDS и утилиты управления RDS на удаленном сервере, воспользуйтесь командой:

Install-WindowsFeature -ComputerName msk-rds21 RDS-RD-Server, RDS-Licensing –IncludeAllSubFeature –IncludeManagementTools –Restart

Картинка с сайта: winitpro.ru

C параметром
–Restart
сервер будет автоматически перезагружен, если установленный компонент это потребует.

Также можно установить компонент такой командой (например роль SMTP сервера):

Get-WindowsFeature -Name SMTP-Server | Install-WindowsFeature

Деплой ролей на множество серверов Windows Server

Еще одна интересная возможность при развертывании однотипных серверов. Вы можете установить необходимые компоненты на эталонном Windows Server и экспортируете список установленных ролей в CSV файл:

Get-WindowsFeature | where{$_.Installed -eq $True} | select name | Export-Csv C:\ps\Roles.csv -NoTypeInformation –Verbose

Картинка с сайта: winitpro.ru

Потом вы можете использовать этот CSV файл для установки такого же набора ролей на других типовых серверах:

Import-Csv C:\PS\Roles.csv | foreach{ Install-WindowsFeature $_.name }

Картинка с сайта: winitpro.ru

Если роль или компонент уже установлен, команда вернет
NoChangeNeeded
и продолжит установку следующей роли.

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

$servers = ('srv1', 'srv2',’srv3’)
foreach ($server in $servers) {Install-WindowsFeature RDS-RD-Server -ComputerName $server}

Как удалить роль или компонент в Windows Server с помощью PowerShell?

Для удаления ролей и компонентов Windows Server используется командлет
Remove-WindowsFeature
.

Например, чтобы удалить роль принт-сервера, выполните команду:

Remove-WindowsFeature Print-Server -Restart

Картинка с сайта: habr.com

В этой статье я бы хотел предложить вам пошаговый туториал по развёртыванию контроллера домена Active Directory на Windows Server 2016 (с графической оболочкой), а также по вводу рабочей станции в получившийся домен. Чем этот туториал может выделиться на фоне других:

1. Вместо простого «Далее, Далее, кликаем сюда, вбиваем это» я постарался дать внятное объяснение каждому шагу, каждой настройке, которую предстоит выполнить. Помимо основных понятий Active Directory, DNS и DHCP вы также сможете найти много интересной информации по всем галочкам, которые вы часто видели, но не задумывались об их назначении.
2. В конце статьи я предложу способ автоматизировать развёртывание получившегося стенда полностью с нуля, имея на компьютере только iso-образы ОС Windows 7 и Windows Server 2016. И никакого PowerShell. Всего одной командой.

Статья предполагает наличие у читателя лишь самых начальных знаний об устройстве сетей (на уровне «Что такое IP-адрес и DNS-адрес»).

Заинтересовало что-то из вышеперечисленного? Тогда погнали.

Туториал будет происходить не в вакууме, а на конкретном виртуальном стенде, состоящим из двух виртуальных машин:

Картинка с сайта: habr.com

Начальное состояние стенда:

1. На машине windows_server уже установлена ОС Windows Server 2016 Standard Evaluation (с GUI). Машина находится в состоянии «сразу после установки ОС». В процессе туториала на ней будут развернуты службы Active Directory (с доменом mydomain.com), DNS и DHCP.

2. Машина workstation выполняет роль рабочей станции. На ней установлена ОС Windows 7. Машина находится в состоянии «сразу после установки ОС». В процессе туториала она будет подключена к домену mydomain.com.

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

1. Объясню, почему я выбрал именно такой стенд для туториала;
2. Супер-краткое описание технологии Active Directory;
3. Выполняется небольшая предварительная настройка windows_server;
4. На windows_server производится включение необходимых компонентов;
5. На windows_server происходит настройка контроллера домена AD (совместно с DNS);
6. На windows_server происходит настройка сервера DHCP;
7. На windows_server регистрируется новая учетная запись в AD;
8. На workstation происходит подключение к домену.

В конце туториала вас ждет приятный бонус — я покажу вам как можно развернуть у себя на компьютере весь этот работающий стенд одной единственной командой. Вам понадобится только наличие двух установочных iso-образов (windows 7 и windows server 2016), да небольшой скрипт, ссылку на который я вам дам в конце статьи.

Почему такой стенд?

Такой стенд, с моей точки зрения, отлично подходит для первого самостоятельного «прощупывания» технологии Active Directory. Он минималистичен (всего 2 виртуальные машины), занимает минимум ресурсов, но при этом изолирован и самодостаточен. Его можно развернуть даже на довольно средненьком компьютере и ноутбуке. При этом на стенде уже присутствуют основные сетевые службы (AD + DNS). DHCP хоть и необязателен для функционирования AD, всё равно был добавлен в стенд в ознакомительных целях.

Туториал предполагает подробный разбор всех шагов по настройке, с пояснениями «что, зачем и почему». Туториал ориентирован на людей, не слишком знакомых с технологиями Active Directory, DNS и DHCP, которые хотели бы немного узнать о внутренней кухне администрирования сетей с Active Directory.

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

Что такое Active Directory

Active Directory — это службы каталогов от компании Microsoft, как подсказывает нам Википедия. За этим сухим и невзрачным определением скрывается одна из важнейших технологий в администрировании сетей. Благодаря Active Directory администратор сети получает очень удобное централизованное средство управления учетными записями пользователей, групповыми политиками (в т.ч. политиками безопасности) и объектами в сети (причём Active Directory без особых проблем справляется даже с гигантскими сетями). А благодаря встроенному механизму репликации, «положить» правильно настроенные сервисы AD не так-то просто. Ну и напоследок, благодаря Windows настроить Active Directory можно буквально мышкой, так что даже совсем начинающие IT-шники смогут с этим справиться.

Несмотря на то, что технологией заведует Microsoft, она вовсе не ограничивается управлением Windows-машин — все известные Linux-дистрибутивы уже давным давно научились работать с этой технологией. Повстречаться с Active Directory не просто, а очень просто — практически каждый офис предполагает наличие этой технологии, поэтому даже самым заядлым линуксоидам было бы неплохо разбираться в азах работы Active Directory.

Начинаем

Вы установили Windows Server 2016 и (надеюсь) видите следующий экран:

Картинка с сайта: habr.com

Эта панель — основное (графическое) средство администрирования Windows Server 2016. Здесь вы можете управлять компонентами и сервисами на вашем сервере (проще говоря, настраивать то, что умеет делать сервер). Эту же панель можно использовать и для базовых сетевых настроек Windows Server, для чего есть вкладка «Локальный сервер».

Базовые настройки Windows Server

Картинка с сайта: habr.com

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

Сетевое имя (hostname) — это удобный способ идентификации узла в сети. Сетевое имя используется как альтернатива IP-адресу и позволяет не запоминать IP-адрес компьютера (при том, что этот адрес может меняться время от времени), а связываться с этим компьютером по его логическому названию.

Проблема в том, что по-умолчанию для Windows Server генерируется совершенно нечитаемое и неинформативное сетевое имя (я выделил его красным цветом на скриншоте).

Рабочие станции ещё могут позволить себе иметь нечитаемый Hostname, но никак не сервер. Поэтому я предлагаю поменять эту абракадабру его на что-то более разумное (например, на ADController), благо делается это быстро.

Смена сетевого имени

Нужно кликнуть на текущее имя сервера (отмечено красным цветом), затем во вкладке «Имя компьютера» нажать на кнопку «Изменить…», после чего ввести что-то более благоразумное:

Картинка с сайта: habr.com

После смены имени машину нужно будет перезагрузить.

Теперь зададим статический IP-адрес для сервера. В принципе это делать не обязательно, раз мы всё равно собрались поднимать DHCP службу, но на самом деле это хорошая практика, когда все ключевые элементы корпоративной сети имеют фиксированные адреса. Открыть меню по настройке сетевого адаптера можно из вкладки «Локальный сервер», кликнув на текущие настройки Ethernet-адаптера (тоже выделены красным цветом).

Настройки IP для интерфейса windows_server

Картинка с сайта: habr.com

Включаем нужные компоненты

Для нашего стенда нам понадобится включить следующие сервисы (или, как они тут называются, роли) на Windows Server:

• Доменные службы Active Directory;
• DNS-сервер;
• DHCP-сервер.

Пройдемся вкратце по каждому из них.

Доменные службы Active Directory

Эта роль фактически «включает» технологию Active Directory на сервере и делает его контроллером домена (под доменом в технологии AD понимается группа логически связанных объектов в сети). Благодаря этой роли администратор получает возможность управлять объектами в сети, а также хранить информацию о них в специальной распределенной базе данных.

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

Однако, что же делать, если контроллер домена выйдет из строя (или просто будет недоступен для рабочих станций)? Если вы настроили только один контроллер домена, то дела ваши довольно плохи — без связи с рабочим контроллером домена пользователи не смогут выполнить вход на свои рабочие места. Поэтому в реальных сетях всегда рекомендуется устанавливать как минимум два контроллера на каждый домен. Каждый контроллер домена участвует в так называемом механизме репликации, благодаря чему все контроллеры домена имеют полную копию базы данных со всеми объектами в домене. Если по какой-то причине один из контроллеров выйдет из строя, его место всегда может занять резервный контроллер — и пользователи даже ничего не заметят.

Однако этот туториал рассчитан на простое ознакомление с технологией AD «на виртуалках», поэтому здесь не будет рассматриваться вопрос создания нескольких контроллеров AD в одном домене.

С этим пунктом все более менее понятно, а зачем же нам включать дополнительно ещё DNS-сервер?

DNS-сервер

Обычно протокол DNS (Domain Name System) используется для обращения к узлам в сети не по их IP-адресу, а по доменному имени (строковый идентификатор), что, конечно, гораздо удобнее. Другими словами, DNS чаще всего используется для разрешения доменных имен.

Но область применения протокола DNS не ограничивается только сопоставлением хостового имени и IP-адреса, что как раз подтверждает технология Active Directory. Дело в том, что Microsoft решила построить технологию Active Directory не с нуля, а на основе протокола DNS. В частности, протокол DNS используется при определении местонахождения всех ключевых сервисов Active Directory в сети. Другими словами, рабочая станция при подключении к контроллеру домена понимает, «куда» ей надо обращаться, именно с помощью протокола DNS.

Все DNS-записи (в том числе с информацией о сервисах Active Directory) хранятся на DNS-сервере, а это значит, что нам нужно заиметь свой собственный DNS-сервер! Вот только вопрос, откуда его взять? Есть два варианта:

1. Использовать отдельную машину в роли DNS-сервера;
2. Использовать саму машину windows_server в роли DNS-сервера.

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

Именно поэтому эту роль (DNS-сервера) тоже нужно добавить к ролям машины windows_server.

Кстати, если не добавить роль «DNS-сервер» сейчас, то в будущем у вас ещё будет такая возможность при конфигурировании контроллера домена AD.

DHCP-сервер

Протокол DHCP (Dynamic Host Configuration Protocol) нужен для автоматической выдачи сетевых настроек узлам в сети. Под сетевыми настройками понимается IP-адрес, адрес шлюза по-умолчанию, адрес DNS-сервера, и ещё ряд других настроек. Этот протокол чрезвычайно удобен при администрировании сетей, особенно больших.

В этом туториале я использую протокол DHCP чтобы рабочая станция workstation могла получить сетевые настройки (в частности, адрес DNS-сервера) без каких-либо действий с моей стороны.

Протокол DHCP не имеет никакого отношения к технологии Active Directory, и можно было бы обойтись вовсе без него (достаточно прописать все сетевые настройки на рабочей станции самостоятельно), но я решил включить этот протокол в данный туториал просто для общего ознакомления. К тому же, такая связка «Контроллер AD — DNS-сервер — DHCP-сервер» довольно часто встречается в реальной жизни, потому что это очень удобный набор сервисов.

При этом вопрос о том, стоит ли выделять отдельную машину под DHCP-сервер, остаётся открытым. Для небольших сетей однозначно не стоит разносить DNS и DHCP-серверы по разным машинам, но для больших сетей, возможно, имеет все-таки смысл задуматься об этом. В нашей же крошечной сети мы абсолютно ничего не потеряем, если включим DHCP-сервер на той же машине, что и DNS-сервер.

Что ж, довольно теории, давайте лучше перейдём к включению этих самых ролей.

Мастер добавления ролей и компонентов

Возвращаемся на панель мониторинга (самый первый скриншот) и щелкаем на пункт «Добавить роли и компоненты». Вас поприветствует мастер добавления ролей и компонентов. Первый экран («Перед началом работы») пропускаем, он совсем неинтересный, а вот дальше идёт экран «Выбор типа установки»

Выбор типа установки

Картинка с сайта: habr.com

Нас устраивает значение по-умолчанию (Установка ролей или компонентов»), но интересен и второй пункт — он позволяет задействовать ещё одну возможность Windows Server — инфраструктуру виртуальных рабочих мест (Virtual Desktop Environment — VDI). Эта интереснейшая технология позволяет, буквально, виртуализировать рабочее место. То есть для пользователя создаётся виртуальное рабочее место, к которому он может подключаться через тонкий клиент. Пользователь лишь видит картинку, тогда как само рабочее место может совершенно прозрачно работать где угодно.

Впрочем, технология VDI это отдельная большая тема, а в этом туториале надо сосредоточиться на контроллере AD, так что кликаем «Далее» и видим экран выбора целевого сервера.

Выбор целевого сервера

Картинка с сайта: habr.com

Мастер добавления ролей позволяет устанавливать роль не только на текущую машину, но вообще на любой добавленный сервер, и даже на виртуальный жёсткий диск. Да, если ваша Windows Server развернута на виртуальной машине (а это довольно частое явление), то вы можете администрировать эту виртуальную машину даже не запуская её! Понаблюдать за этим процессом можно, например, здесь

Нам же такая экзотика ни к чему, так что просто выбираем единственный возможный сервер (обратите внимание, что он теперь называется ADController место непонятной абракадабры), жмём «Далее» и, наконец, попадаем на экран выбора ролей, которые нужно добавить.

Выбор добавляемых ролей

Картинка с сайта: habr.com

Выбираем три роли, о которых уже говорили ранее, и продолжаем.

Выбор компонентов

Картинка с сайта: habr.com

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

Согласно идеологии Microsoft, роль — это набор программ, которые позволяют компьютеру предоставлять некоторые функции для пользователей в сети. Например, DNS, DHCP, контроллер домена AD — это всё роли. А вот компоненты — это набор программ, которые улучшают либо возможности ролей сервера, либо самого сервера.

При этом глядя на список «Компонентов» так сходу и не скажешь, что какие-то вещи в списке лишь «вспомогательные». Вот например, DHCP-сервер расценивается как роль, а WINS-сервер — уже как компонент. А чем SMTP-сервер хуже DNS?

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

В любом случае, дополнительные компоненты нам не нужны, так что кликаем «Далее».

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

Подтверждение устанавливаемых ролей и компонентов

Картинка с сайта: habr.com

На экране подтверждения ещё раз видим все устанавливаемые роли и компоненты, после чего жмём «Установить».

Остаётся лишь дождаться, когда заполнится progress-bar, и перейти к следующему пункту туториала — настройке контроллера домена AD.

Настраиваем контроллер домена Active Directory

Все роли и компоненты успешно добавлены, о чём свидетельствует следующий экран:

Картинка с сайта: habr.com

Вот только AD на сервере всё еще не работает — для этого его необходимо донастроить. Для этого нам настойчиво предлагают «Повысить роль этого сервера до уровня контроллера домена».

Погодите-ка, ЧТО?!

А чем же я занимался последние 15 минут? Я же добавлял роли, и судя по сообщению, они успешно добавились! И тут меня снова хотят заставить добавлять какие-то новые роли? В чем-то тут подвох.

Подвох тут действительно имеется, но вообще в не самом очевидном месте. Вот так выглядит предыдущий скриншот в английской версии Windows Server (картинка из интернета).

Английская версия скриншота

Картинка с сайта: habr.com

Видите разницу? В английской версии ни слова ни про какие роли! Про повышение есть, про роли — нет. Один из тех случаев, когда перевод вносит сумятицу на пустом месте. Согласно английской версии, никакими ролями мы дальше не занимаемся, что и логично, ведь мы их как раз только что добавили.

Что ж, тыкаем на предложение «Повысить роль этого сервера до уровня контроллера домена», и теперь нас привествует мастер настройки доменных служб Active Directory с предложением выбрать конфигурацию развёртывания.

Конфигурация развёртывания

Картинка с сайта: habr.com

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

Картинка с сайта: habr.com

Технология Active Directory (как и DNS) подразумевает иерархическое построение имён на основе доменов. Домены могут выстраиваться в доменные деревья по принципу «родительско-дочерних» отношений. В основе дерева лежит так называемый корневой домен (на картинке выше это sources.com, xyz.com и abc.com). При этом домен может иметь сколько угодно потомков. Домен-потомок располагается в пространстве имён родителя и является его «поддоменом» (subdomain). У доменного имени домена-потомка есть дополнительный префикс относительно доменного имени родителя (rus.abc.com, eng.abc.com). Один корневой домен основывает только одно доменное дерево со своим независимым пространством имён.

Теперь представьте, что таких независимых деревьев может быть много — в этом случае эти деревья образуют структуру, которая называется «лес». При этом в Active Directory доменные деревья не могут быть «сами по себе» — они обязательно должны находиться в лесу (даже если лес будет состоять всего из одного-единственного домена). Первый домен, который добавляется в лес, называется корневым доменом леса (на рисунке выше это sources.com). Корневой домен леса используется для идентификации всего леса (то есть если корневой домен называется sources.com, то и весь лес называется sources.com).

Теперь возвращаемся к мастеру настройки доменных имен. На этом этапе мастер предлагает следующие варианты:

1. Добавить контроллер домена в существующий домен (помните про резервирование контроллеров в домене, так ведь?). Этот вариант не для нас, ведь домена ещё никакого нет;
2. Добавить новый домен в лес. Этого мы тоже сделать не можем, т.к. и леса у нас тоже никакого нет;
3. Добавить новый лес. Это вариант как раз для нас. При этом нам тут же предлагают выбрать корневой домен для этого леса (первый домен, который будет создан в лесу).

Назовём корневой домен mydomain.com и кликнем «Далее»

Параметры контроллера домена

Картинка с сайта: habr.com

Рассмотрим возможные параметры:

1. Режим работы леса и домена. Домены в одном лесу могут работать в разных режимах в зависимости от версии Windows Server на борту. Лес должен иметь режим не выше, чем самый «старый» домен в его составе. Т.к. мы планируем использовать только Windows Server 2016, то оставим этот режим и для леса и для домена;
2. DNS-сервер. Если ранее Вы не активировали роль DNS-сервера в мастере добавления ролей, то можете сделать это сейчас (вам даже предложат такой вариант по-умолчанию);
3. Должен ли контроллер домена выступать в роли Global Catalog-сервера;
4. Включить ли режим базы данных Active Directory «только на чтение». Основная задача, которую преследует технология RODC — возможность безопасной установки собственного контролера домена в удаленных филиалах и офисах, в которых сложно обеспечить физическую защиту сервера с ролью DC. Контроллер домена RODC содержит копию базы Active Directory, доступную только на чтение. Это означает, что никто, даже при получении физического доступа к такому контроллеру домена, не сможет изменить данные в AD (в том числе сбросить пароль администратора домена) (информация взята отсюда)

А вот пункт 3 рассмотрим поподробнее, он довольно интересный.

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

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

Что такое вообще «Глобальный каталог»? Согласно Miscrosoft — это распределенное хранилище данных, которое хранит частичное представление обо всех AD-объектах в лесу. Это хранилище располагается на котроллерах домена, которые имеют дополнительную роль «Global Catalog Server» (Сервер глобального каталога). От обычного контроллера домена GC-сервер отличается в первую очередь тем, что помимо полной копии всех объектов в своем домене, хранит также частичную информацию обо всех объектах в других доменах леса.

Чего это позволяет достичь? Давайте представим, что рабочая станция запросила информацию об объекте из другого домена. Она обращается на ближайший GC-сервер с просьбой предоставить ей информацию об этом объекте. GC-сервер, в свою очередь, может:

1. Либо отдать рабочей станции нужную информацию сразу (если эта информация у GC-сервера имеется);
2. Либо перенаправить запрос к нужному контроллеру домена, где эта информация точно будет находиться. Чтобы понять, какому контроллеру домена нужно перенаправить запрос, как раз и происходит поиск по GC.

Информация о том, какие атрибуты попадают в глобальный каталог, определена в Partial Attribute Set (PAS), который может настраивать администратор AD. Например, если администратор понимает, что рабочие станции часто будут обращаться к атрибуту, который не содержится в глобальном каталоге, он может добавить туда этот атрибут. Тогда запросы рабочих станций при чтении этого атрибута будут выполняться значительно быстрее, т.к. уже ближайший GC-сервер сможет предоставить им всю нужную информацию.

Однако, если в лесе всего один домен (как у нас), то Глобальный каталог содержит полную копию объектов в домене и всё.

Что ж, возвращаемся к галочке GC, которую за нас уже проставил мастер настройки доменных служб. Если вы попробуете её отключить, то убедитесь, что отключить её нельзя. Это связано с тем, что каждый домен в AD должен иметь хотя бы один GC-сервер, и при добавлении первого контроллера в домен этот контроллер сразу помечается как GC-сервер.

Что ж, давайте согласимся с этим «выбором» мастера и перейдём к последнему параметру на этом скриншоте — к паролю для режима восстановления служб каталогов. Это особый режим безопасной загрузки Windows Server, который позволяет администратору работать с базой данных AD. Этот режим применяется, например, в следующих случаях:

• база Active Directory повреждена и нуждается в исправлении;
• требуется выполнить обслуживание базы данных AD (сжатие, анализ на наличие ошибок);
• требуется восстановить резервную копию базы данных AD;
• требуется сменить пароль администратора.

Да да, вы не ослышались. Чтобы просто восстановить резервную копию базы данных, нужно перезагрузить машину и загрузиться в особом «безопасном» режиме. Это вам не Linux какой-нибудь.

Фух, вроде разобрались. Давайте перейдем дальше на шаг, где нам предложат настроить делегирование DNS.

Делегирование DNS

Картинка с сайта: habr.com

Что такое делегирование DNS? По большей части, это передача ответственности за некоторую DNS-зону отдельному DNS-серверу. Это распространенная практика в больших сетях, в которых требуется разграничить зоны ответственности за доменные зоны между различными серверами. При делегировании DNS в «главный» DNS-сервер вносится запись о том, что «вот за эту DNS-зону несёт ответственность вон тот DNS-сервер, обращайся туда».

Т.к. у нас всего одна зона DNS и DNS-сервер тоже один, то этот шаг нам необходимо пропустить и перейти к выбору NetBIOS-имени.

NetBIOS-имя

Картинка с сайта: habr.com

Мы видим, что мастер предложил нам на выбор сразу же имя для нашего домена — MYDOMAIN. Но вы можете (и должны) задать себе вопрос: а что такое вообще NetBIOS-имя и зачем оно нужно? И разве мы уже не настраивали сетевое имя узла (Hostname) в самом начале? Чего же от вас хотят?

NetBIOS (Network Basic Input/Output) — это ещё один способ разрешения имён узлов в сети (более древний и более примитивный, чем DNS). NetBIOS-имена не предполагают никакой иерархии, их длина ограничивается всего лишь 16 символами, и они применяются только для разрешения имён компьютеров в локальной сети. Когда мы в самом начале туториала выбрали сетевое имя ADController — мы, на самом деле, задали именно NetBIOS-имя для сервера. Но теперь от нас снова требуют выбрать NetBIOS-имя (да ещё и другое, отличное от ADContoller). Не много ли NetBIOS-имён для одного компьютера?

Дело в том, что Microsoft пошла ещё дальше — и ограничила длину NetBIOS-имен не 16 символами, а 15 символами. 16-ый символ при этом считается зарезервированным суффиксом, который может принимать фиксированные значения. В зависимости от значения 16-го байта получаются разные классы NetBIOS-имён. Например, если суффикс равен 00, то NetBIOS-имя относится к рабочей станции. Если суффикс равен 1С, то это имя относится к имени домена.

То есть, как вы понимаете, на первом шаге мы задавали NetBIOS-имя для компьютера Windows Server (с суффиком 00). А теперь задаём NetBIOS-имя домена mydomain.com (с суффиксом 1С).

Кстати, можете, ради интереса, отмотать туториал в самое начало и посчитать количество символов в «нечитаемом» автоматически сгенерированном сетевом имени windows_server. Будет как раз 15 символов (максимальная длина NetBIOS-имени).

И напоследок скажу, что вы не можете пропустить этот шаг. NetBIOS хоть и устаревшая технология, но до сих пор используется ради совместимости с некоторыми старыми службами. Настроить контроллер домена Active Directory без NetBIOS-имени нельзя.

Что ж, и с этим тоже разобрались. Оставляем NetBIOS-имя по-умолчанию и двигаемся дальше, к выбору места расположения базы данных AD. Можно оставить значение по-умолчанию, комментировать особо нечего.

Расположение базы данных

Картинка с сайта: habr.com

Все ваши настройки должны пройти предварительную проверку:

Проверка предварительных требований

Картинка с сайта: habr.com

Как только всё готово, жмите «Установить» и можете спокойно идти пить чай, потому что после установки автоматически начнётся очень-очень долгая перезагрузка. Зато настройка контроллера домена AD на этом закончена, поздравляю!

Настройка DHCP-сервера

Пришло время заняться настройкой DHCP-сервера. Настройка глобально состоит из двух частей:

1. Авторизация DHCP-сервера в домене AD. Не каждый DHCP-сервер может раздавать сетевые настройки в домене AD — только авторизованные. Это сделано с целях безопасности, чтобы другие DHCP-серверы не могли «подсунуть» неправильные настройки компьютерам в домене;
2. Настройка новой DHCP-области. Это уже непосредственно настройка самого DHCP-сервера, в ходе которой определяются какие сетевые настройки будут выдаваться компьютерам в сегменте сети.

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

Запуск авторизации DHCP-сервера

Картинка с сайта: habr.com

Картинка с сайта: habr.com

В открывшемся мастере настройки DHCP после установки пропускаем первый приветственный экран и переходим к экрану авторизации

Авторизация DHCP-сервера в домене

Картинка с сайта: habr.com

На выбор предлагаются три варианта:

1. Использовать учётные данные администратора (по-умолчанию)
2. Использовать учётные данные другого пользователя;
3. Пропустить авторизацию AD.

По-умолчанию авторизовать DHCP-сервер в домене могут только члены группы EnterpriseAdmins, куда как раз и входит пользователь MYDOMAIN\Администратор. При желании можно потратить немного времени и делегировать эту возможность админам «помельче» (региональным администраторам), почерпнуть больше информации по этой теме можно отсюда.

Итак, выбираем вариант по-умолчанию и завершаем первый этап настроки DHCP-сервера.

Завершение авторизации DHCP-сервера

Картинка с сайта: habr.com

Теперь переходим непосредственно к настройкам DHCP. Для этого на панели мониторинга кликаем вкладку «Средства» и выбираем пункт «DHCP»

Картинка с сайта: habr.com

В открывшемся окне с настройками DHCP нужно кликнуть правой кнопкой мышки на IPv4 и затем на пункт меню «Создать область». После этого откроется мастер создания новой области.

Что такое DHCP-область? Под этим понимается некий диапазон IP-адресов, которые может выдавать DHCP-сервер другим компьютерам в сети. Каждая область помимо диапазона IP-адресов также содержит другие сетевые настройки, с которыми мы сейчас и познакомимся.

Назовём DHCP-область SCOPE1 и перейдём дальше.

На следующем экране вам предложат выбрать диапазон адресов, которые будут выдаваться компьютерам в сети. Ранее я настраивал сетевой интерфейс на Windows Server, выдав ему адрес 192.168.1.1/24. Это статический адрес и он зарезервирован, его выдавать другим компьютерам нельзя.

Зато никто не мешает выдавать все остальные адреса в сети 192.168.1.0/24 — так что задаём диапазон от 192.168.1.2 до 192.168.1.254 (192.168.1.255 — это зарезервированный широковещательный адрес, его выдавать тоже нельзя).

Настройка диапазона адресов

Картинка с сайта: habr.com

В целом, никто не мешает вам как администратору выдавать меньше IP-адресов, чем доступно в адресации сети. Например, можно было бы выделить в сети всего 100 адресов для автоматической выдачи: 192.168.1.101-192.168.1.200.

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

Исключения в диапазоне и задержка DHCPOFFER

Картинка с сайта: habr.com

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

Эта настройка уже относится к довольно продвинутому администрированию сетей: если в вашей сети есть несколько DHCP-серверов, то с помощью этой задержки вы можете регулировать нагрузку между ними (подробнее можно прочитать, например, тут).

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

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

Картинка с сайта: habr.com

Протокол DHCP предполагает выделение адресов только на определённое время, после чего компьютеры должны продлять аренду. Здесь можно настроить это время (по-умолчанию — 8 дней).

8 дней меня лично вполне устраивает, так что кликаем «Далее» и видим предложение настроить другие настройки, которые будут получать клиенты в сети (помимо IP-адреса). Соглашаемся.

Настроить дополнительные параметры

Картинка с сайта: habr.com

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

Шлюз по-умолчанию

Картинка с сайта: habr.com

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

А вот для понимания имени родительского домена, рассмотрим следующую ситуацию.

Допустим, есть домен mydomain.com и есть два компьютера в этом домене с именами comp1.mydomain.com и comp2.mydomain.com. Если comp1 хочет связаться с comp2, то он должен, по-хорошему, использовать следующую команду (обращение по Fully Qualified Domain Name — FQDN):

ping comp2.mydomain.com

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

ping comp2

На самом деле, в этом случае начинается целая магия — очень хитрый процесс разрешения имён (картинка из интернетов).

Процесс разрешения сетевых имён

Картинка с сайта: habr.com

1. Поиск информации в hosts.txt или в кеше;
2. Попытка найти имя через DNS;
3. Попытка найти NetBIOS-имя в кеше;
4. Попытка найти NetBIOS-имя через WINS-сервер;
5. Попытка найти NetBIOS-имя путём отправки широковещательных пакетов в локальную сеть;
6. Попытка найти NetBIOS-имя в LMHOSTS-файле.

Согласно алгоритму разрешения сетевых имен, сначала comp1 попробует найти информацию о comp2 в hosts.txt — файле. Если этой информации там не окажется, то начинается процесс поиска узла через DNS. Вот только вопрос — DNS-имена же находятся в каком-то домене, верно? Какое доменное имя нужно «пристыковать» к comp2 при выполнении пинга?

Вот тут в дело и вступает настройка DHCP, которая называется «имя родительсокго домена». Это как раз тот суффикс, который будет автоматически «пристыкован» к имени comp2 при выполнении DNS-разрешения имени. Так что если имя родительского домена равно «mydomain.com», то команда ping comp2 неявно преобразуется в ping comp2.mydomain.com.

Если же DNS-разрешение окажется неудачным, дальше начнутся попытки найти comp2 уже по NetBIOS-имени. Что такое WINS, и чем он отличается от Broadcast — информация будет чуть дальше по тексту.

Что ж, в нашем случае имя родительсокго домена должно быть mydomain.com (значение по-умолчанию), а нужный DNS-сервер уже находится в списке, так что в итоге просто кликаем «Далее».

Настройки DNS

Картинка с сайта: habr.com

Теперь нас попросят указать настройки WINS-сервера. WINS (Windows Internet Name Service) сервер участвует в разрешении NetBIOS-имён в сети (прямо как DNS-сервер для DNS-имён). Вот только, в отличие от DNS, WINS-сервер не обязательно должен присутствовать в сети, чтобы разрешение NetBIOS-имён работало. Так зачем же он нужен тогда?

Дело в том, что по-умолчанию разрешение NetBIOS-имен происходит через широковещательные запросы. С одной стороны, это очень простой механизм (проще не придумаешь), но, с другой стороны, обладает парой недостатков:

1. При наличии большого количества NetBIOS-имён в сети широковещательный тафик может начать «зашумлять» канал;
2. Широковещательные запросы не могут «выйти» за пределы текущей сети, поэтому узнать NetBIOS-имя из другой сети таким способом не выйдет.

Так вот, WINS-сервер позволяет решить обе этих проблемы. Этот сервер централизованно хранит NetBIOS-имена компьютеров, и обычные узлы в сети могут обращаться к нему для поиска IP-адреса интересующего их имени (как и для DNS). Такой подход, во-первых, резко уменьшает количество широковещательного трафика в сети, а, во-вторых, позволяет посылать NetBIOS-запросы в другие сети, а не только в текущую.

В нашей небольшой сети WINS-сервер нам ни к чему, поэтому просто пропускаем эту настройку и едем дальше.

WINS-серверы

Картинка с сайта: habr.com

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

Активация области

Картинка с сайта: habr.com

Создаём нового пользователя в домене AD

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

Для этого возвращаемся на панель мониторинга, кликаем на «Средства» и затем на «Пользователи и Компьютеры Active Directory»

Картинка с сайта: habr.com

В открывшемся меню можно заметить созданный домен mydomain.com и его состав. Видно, что помимо пользователей в домене созданы папочки для Computers, Domain Controllers и других сущностей. Но нас сейчас интересуют пользователи, поэтому кликаем правой кнопкой мышки на папке Users и выбираем «Создать» -> «Пользователь»

Картинка с сайта: habr.com

После этого появляется диалоговое окно с преложением ввести данные нового пользователя. По старой доброй традиции назовём пользователя Foo Bar. Обратите внимание, что пользователь отображается лишь как «Объект» в Active Directory наравне с другими объектами.

Новый объект — Пользователь

Картинка с сайта: habr.com

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

Обычно администратор создаёт простой пароль для пользователя, а затем требует от пользователя сменить его при первом входе в систему (первая галочка в списке доступных опций). Это очень хорошая практика с точки зрения безопасности, ведь таким образом даже администратор AD не сможет узнать пароль пользователя. Также хорошей практикой считается ограничивать срок действия пароля. В этом туториале для простоты мы уберём требование о смене пароля пользователем при врходе в систему.

Параметры нового пользователя

Картинка с сайта: habr.com

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

Подтверждение создания нового пользователя

Картинка с сайта: habr.com

Ну что ж, вот, кажется, и всё! Осталось лишь проверить ввод рабочей станции в домен.

Ввод рабочей станции в домен

Переключаемся на вторую машину workstation под управлением Windows 7 и заходим в свойства системы. Сейчас видно, что рабочая станция находится в рабочей группе (не в домене). Кстати говоря, WORKGROUP — это тоже NetBIOS-имя. Только в отличии от имени домена оно имеет суффикс 1E.

Картинка с сайта: habr.com

Щелкаем на кнопку «Изменить параметры», затем в появившемся окне ещё раз «Изменить…».

В окне изменения имени компьютера пишем, что он должен принадлежать домену mydomain.com.

Подключение к домену

Картинка с сайта: habr.com

Видим предупреждение о нестандартном имени компьютера (testo-ПК содержит кириллицу). Это связано с тем, что NetBIOS-имена не могут содеражать кириллицу. Но мы с вами настроили DNS-сервер (DNS настройки прилетели на рабочую станцию по DHCP), а DNS-механизм разрешения имён, как мы знаем, имеет приоритет перед NetBOIS. Так что в данном случае на работоспособность AD кириллица не влияет. Но на практике так делать не надо!

Нестандартное имя компьютера

Картинка с сайта: habr.com

Вводим логин-пароль от новой учетной записи FooBar и, наконец, видим заветное сообщение «Добро пожаловать в домен»

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

Логин в AD

Картинка с сайта: habr.com

И после успешного входа на рабочий стол перепроверяем свойства системы.

Новые свойства системы

Картинка с сайта: habr.com

Полное имя компьютера поменялось на testo-ПК.mydomain.com, а это значит, что мы успешно ввели рабочую станцию в домен mydomain.com.

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

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

Так почему бы не автоматизировать все действия с клавиатурой и мышкой, которые мы предпринимали? И нет, я говорю не об AutoIT, я говорю о платформе Testo, создателем которой я являюсь. Эта платформа позволяет фиксировать все действия, проводимые с виртуальными машинами, в виде скриптов на специальном языке Testo-lang. Ну а Testo затем превратит эти скрипты обратно в действия.

Я приведу лишь один скриншот с кусочком скрипта, чтобы у вас сложилось представление о том, о чём я говорю (да, именно скриншот, ведь хабр не умеет подсвечивать скриповый язык Testo-lang). Я даже не буду комментировать этот скрипт, т.к. верю, что код говорит сам за себя.

Секция скрипта на языке Testo-lang

Картинка с сайта: habr.com

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

Всё, что Вам потребуется для создания собственного стенда с настроенной Active Directory — это:

1. Установочный iso-образ Windows Server 2016 русской версии;
2. Установочный iso-образ Windows 7 (придётся поискать самим);
3. Скрипты на языке Testo-lang;
4. Установленная платформа Testo (бесплатно);
5. Выполнить команду.

sudo testo run ./tests.testo --param ISO_DIR /path/to/your/iso/dir

И всё. Как и я обещал — всего одна команда. Через пол часа — час (зависит от шустрости вашего компьютера) вы сможете наслаждаться своим готовым стендом.

Итоги

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

• сайт платформы Тесто.
• youtube-канал, где можно найти много примеров.
• основная статья на хабре
• статья, где я автоматизировал несколько системных тестов для Dr. Web
• скрипты на языке Testo-lang для этого туториала