Установка DirectAccess: шаг за шагом

Я сижу у кофейне со своим мобильным компьютером, который является членом корпоративного домена. По щелчку буквы диска H: я могу увидеть файлы и папки на внутреннем файлом сервере. При выполнении команды gpupdate /force или wuauclt /detectnow применяются групповые политики и проверяется наличие обновлений, поступающих с внутренних контроллеров домена и WSUS-серверов. Короче говоря, я использую DirectAccess и мне это нравится.

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

DirectAccess? Для компании среднего или малого размера? Да и еще раз да, и настройка не так сложна, как считается. Это было нетривиально, но не невозможно.

Готовы ли к безопасному расширению своей сети в Интернет? Возьмите сервер с Windows Server 2008 R2 и двумя сетевыми картами с последовательными адресам, и это пошаговое руководство позволит уже сегодня получить собственную постоянно доступную виртуальную частную сеть DirectAccess.

Шаг 1. Создайте и подготовьте сервер DirectAccess

Начните с подготовки машины под управлением Windows Server 2008 R2 с двумя сетевыми картами. Эта машина должна быть членом внутреннего домена Active Directory.  Одну сетевую карту подключите к внешней подсети, а другую — к внутренней сети. Далее нужно установить сертификаты и компоненты DirectAccess. Так как этот сервер будет служить мостом между внешней и внутренней сетью надо обеспечить, чтобы на нем присутствовали все необходимые обновления.

Также потребуются два последовательных IP-адреса, например 98.34.120.34 и 98.34.120.35. Очень важно, чтобы они были последовательными. Получение таких адресов может оказаться сложной задачей для ИТ-отдела небольшой компании. Нужно очень аккуратно подходить к выбору Интернет-провайдера.

К выбору адресов надо отнестись очень внимательно. Есть ряд тонких моментов, о которых сообщалось в TechNet

все дело в том, какие адреса считаются «последовательными». В консоли DirectAccess Management в алфавитном порядке перечисляются все открытые IPv4-адреса, назначенные Интернет-адаптеру. Поэтому в DirectAccess следующие пары адресов не считаются последовательными: w.x.y.9 и w.x.y.10 (потому что они упорядочиваются, как w.x.y.10, w.x.y.9), w.x.y.99 и w.x.y.100 (они упорядочиваются, как w.x.y.100, w.x.y.99), w.x.y.1, w.x.y.2 и w.x.y.10 (они сортируются, как w.x.y.1, w.x.y.10, w.x.y.2). В этих случаях вам потребуются другие наборы последовательных адресов.

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

Шаг 2. Создание внешних записей DNS

Для DirectAccess требуется, чтобы разрешение пары внешних адресов выполнялось с использованием внешних DNS-записей типа A. Обе записи должны указывать на первый из пары последовательных IP-адресов (не на второй и не на оба). Хотя они обе и указывают на один адрес, использоваться для DirectAccess будет только одна. Вторая понадобится для поиска отзыва сертификатов (CRL), который мы вскоре настроим.

Допустим, в среде есть две записи A — directaccess.company.com и crl.company.com. Для создания этих записей может потребоваться помощь вашего Интернет-провайдера.

Шаг 3. Создание инфраструктуры PKI с помощью служб Active Directory Certificate Services

Одна из компонентов безопасности DirectAccess — взаимная проверка подлинности средствами служб Certificate Services инфраструктуры открытых ключей (PKI). Добавьте роль Active Directory Certificate Services (ADCS) и службу роли Certification Authority (CA) на имеющийся сервер, например на контроллер домена. Настройте его как корневой CA и создайте новый закрытый ключ, оставив все остальные параметры со значениями по умолчанию.

Далее надо создать шаблон сертификата веб-сервера. В консоли Server Manager перейдите к роли ADCS и щелкните Certificate Templates. Щелкните правой кнопкой Web server template и выберите Duplicate Template.

Создайте шаблон Windows Server 2008 Enterprise и откройте консоль свойств. На вкладке Request Handling выберите Allow private key to be exported. На вкладке Security предоставьте группам Domain Computers и Authenticated Users разрешения Read и Enroll. Выйдите из консоли Properties и щелкните правой кнопкой только что созданный шаблон. Выберите Change Names и задайте шаблону понятное имя.

Добавьте шаблон в папку CA Certificate Templates, для чего щелкните правой кнопкой папку и выберите New/Certificate Template to Issue. Выберите и выпустите только что созданный шаблон.

Шаг 4. Установите список CRL на сервере DirectAccess

Используемому инфраструктурой PKI сертификату нужен доступ к списку CRL. Список содержит перечень отозванных сертификатов, которые стали недействительными. Вы должны иметь доступ к списку CRL как из Интернета, так и из интрасети, поэтому ваш сервер DirectAccess как нельзя лучше подходит для их размещения.

Начните с установки роли IIS с составом служб ролей по умолчанию. В диспетчере IIS Manager создайте новую виртуальную папку по имени CRLD, которая «смотрит» на папку C:\inetpub\wwwroot\crld. Включите функцию Directory Browsing на странице свойств виртуальной папки.

Далее создайте общую папку C:\inetpub\wwwroot\crld под именем CRLD$. Предоставьте учетной записи компьютера CA разрешение Full Control для доступа к этой общей папке.

Вернитесь на страницу свойств виртуального каталога, выберите Configuration Editor и перейдите к system.webserver/security/request Filtering. Присвойте параметру Double Escaping значение True.

Далее создайте путь для клиентов, которые будут выполнять разрешение для обнаружения CRL как из внутренних, так и внешних сетей. Вернитесь на контроллер домена, откройте консоль Certification Authority и щелкните правой кнопкой корневой узел консоли и откройте окно свойств сервера CA. На вкладке Extensions выберите расширение CRL Distribution Point (CDP). Щелкните Add и введите внешний адрес, которые внешние клиенты будут использовать для получения списка CRL.

Я использую такой адрес: http://crl.company.com/crld/<сервер_CA><CRLNameSuffix><DeltaCRLAllowed>.crl. Ваш адрес будет похожим за исключением полного имени сервера. Установите все флажки в нижней части страницы. Снова щелкните Add, чтобы создать подключение для внутренних клиентов. Введите путь UNC, которые внутренние клиенты могут использовать для доступа к CRL.

Мой путь таков: \\crl.company.internal\crld$\<сервер_CA><CRLNameSuffix><DeltaCRLAllowed>.crl. Так как это внутреннее подключение к сети, где опубликован список CRL, нужно установить флажки Publish CRLs и Publish Delta CRLs.

Вернитесь в консоль CA, щелкните правой кнопкой Revoked Certificates и последовательно выберите All Tasks/ Publish. Если вы все сделали правильно, вы должны увидеть в общей папке два файла списков CRL.

Шаг 5. Установка сертификатов на серверах DirectAccess и сетевых расположений

Ранее вы уже создали шаблоны сертификатов. Теперь время создать сами сертификаты. Серверу DirectAccess и соответствующему серверу сетевых расположений для взаимной проверки подлинности требуются сертификаты веб-сервара.

Откройте MMC-консоль Certificates на сервере DirectAccess и перейдите к хранилищу Certificates/Personal. Щелкните правой кнопкой Certificates и последовательно выберите All Tasks/Request New Certificate. В консоли Certificate Enrollment выберите сертификат, созданный на шаге 3.

Откроется ссылка с предложением ввести дополнительную информацию для запроса сертификата. Щелкните ссылку и в открывшемся окне выберите вкладку Subject. Задайте общее имя и альтернативное имя DNS. Последнее представляет собой внешнее полное внешнее имя вашего сервера DirectAccess (например, у меня это имя directaccess.company.com). Последовательно щелкните OK и Enroll, чтобы отправить заявку на сертификат.

Сервер сетевых расположений (NLS) является внутренним сервером, на котором установлена роль IIS. NLS не нужно много ресурсов, поэтому его без опаски можно установить на существующем сервере. В таком же порядке установите созданный на шаге 3 сертификат на сервере NLS. Однако на этот раз есть небольшая разница. Вместо внутреннего полного имени сервера DirectAccess надо указать полное имя, разрешаемое в локальной сети.

В моем случае это имя nls.company.internal, которое я добавил в DNS как CNAME, в котором указал реальное имя сервера NLS. DirectAccess общается в NLS по протоколу HTTPS, поэтому надо создать привязку HTTPS к этому CNAME на веб-сайте по умолчанию.

Шаг 6. Подготовка клиентов средствами групповых политик

Для DirectAccess нужно настроить ряд параметров брандмауэра и системы автоматической подачи заявок на сертификаты, что проще всего сделать с помощью групповых политик. Первым делом надо создать входящие и исходящие правила для ICMPv6, которые обеспечат поддержку ping-запросов протокола IPv6, необходимых для нормальной работы DirectAccess.

В консоли Group Policy Management Editor перейдие к узлу Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/Windows Firewall with Advanced Security. Создайте новое правило входящих подключений. Выберите правило типа Custom для All programs, в поле Protocol выберите ICMPv6, а в поле Echo request — конкретный тип ICMP.

Примените это правило ко всем локальным или удаленным IP-адресам и активируйте подключение во всех трех профилях. Задайте имя правила и щелкните Finish. Повторив эти же операции, создайте правило исходящих подключений с такими же параметрами.

Можно создать еще одну конфигурацию клиентов в том же или новом объекте групповой политики (GPO). На этот раз в редакторе групповых политик перейдите к узлу Computer Configuration/Policies/Windows Settings/Security Settings/Public Key Policies и просмотрите свойства политики Certificate Services Client – Auto-Enrollment. В Configuration Model установите флажок Enabled, а также установите два флажка, которые станут доступными. Щелкните ОК.

Последний параметр групповой политики вы найдете в узле Public Key Policies/Automatic Certificate Request Settings. Щелкните его правой кнопкой и выберите New/Automatic Certificate Request. Откроется окно мастера настройки автоматического запроса сертификатов (Automatic Certificate Request Setup Wizard). Он позволяет задать типы сертификатов, которые компьютер будет запрашивать автоматически. Выберите шаблон Computer и пройдите мастер.

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

Шаг 7. Подготовка доменных служб

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

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

В-третьих надо изменить DNS. В некоторых случаях для работы DirectAccess требуется протокол ISATAP (Intra-Site Automatic Tunneling Address Protocol). Этот протокол обычно входит в глобальный список блокировки на DNS-сервере, поэтому ISATAP над удалить из этого списка. Для этого в редакторе реестра на каждом DNS-сервере перейдите узлу HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters и удалите запись ISATAP. После этого надо перезапустить службы.

Шаг 8. Установка DirectAccess

Теперь мы готовы устанавливать DirectAccess. Эта операция выполняется средствами диспетчера сервера (Server Manager). После установки откройте консоль DirectAccess и перейдите к узлу Setup. Настройка DirectAccess состоит из четырех шагов:

1. Задайте глобальную группу, содержащую учетные записи компьютеров, которым надо предоставить внешний доступ.
2. Укажите сетевые интерфейсы Интернета и внутренней сети, а также сервер CA и внешний сервер сертификатов. Это просто, если вы переименовали интерфейсы и сертификаты, задав им легкие для запоминания имена.
3. Укажите инфраструктурные серверы, которые могут взаимодействовать с внешними клиентами. Здесь надо указать URL-адрес сервера NLS, а также имя и параметры IPv6 сервер DNS, контроллера домена и любых других серверов, которые вы используете для управления клиентами, например серверов WSUS или System Center. На всех серверах должна быть включена поддержка IPv6.
4. Завершите конфигурирование, указав все остальные серверы, к которым надо предоставить доступ внешним клиентам. Это серверы, обслуживающие клиентские приложения.

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

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

Это нетривиальная, но не невозможная операция. Операций по конфигурирования немало, но самое сложное — получить два последовательных IP-адреса у Интернет-провайдера.

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