Развертывание Directaccess в Windows Server 2012 R2 Essentials

С выходом WSE 2012 в копилку технологий для сегмента SBS добавилась технология Directaccess. О ее теоретической основе я предлагаю ознакомится из предыдущей публикации, ну а сей час сосредоточим свое внимание на практическом вопросе ее реализации уже в WSE 2012 R2. Описанный далее пример развертывания справедлив только для операционных систем Windows 8, 8.1, так как этим системам не требуется наличие PKI инфраструктуры для работы по Directaccess. Статья же будет состоять из следующих разделов:

  • Подготовка среды к развертыванию
  • Развертывание
  • Конфигурирование
  • Тестирование
  • Выводы

Подготовка среды к развертыванию

В качестве подготовительных шагов необходимо будет сделать следующее:

  • Создать в DNS запись для NLS сервера
  • Сконфигурировать шаблон сертификата Web Server в Certificate Authority
  • Создать SSL сертификат для NLS сервера
  • Создать группу для компьютеров на которых будет конфигурироваться DA

Для вышеописанных действий вызовем консоль mmc и добавим в нее расширения консоли Active directory Users and Computers, DNS, Certificate Authority как было сделано на скриншоте:

1-31-2014 9-41-20 PM

В консоли DNS создадим запись типа A для NLS сервера. Она должна указывать на IPv4 адрес WSE. Для примера я использовал directaccess, но это не принципиально, имя может быть любым.

1-31-2014 9-46-11 PM

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

1-31-2014 9-56-19 PM

Чтобы создать SSL сертификат на Certificate Authority необходимо подправить шаблон Web Server так, чтобы учетная запись WSE обладаля правами “чтение” и “выпуск”. Для этого выберем Manage как показано на скриншоте:

1-31-2014 10-04-59 PM

Найдя нужный шаблон перейдем в его свойства и выберем вкладку Security. Добавим учетную запись сервера WSE и наделим ее правами Read  и Enroll.

1-31-2014 10-11-34 PM

Выполнив предыдущие шаги, теперь можно приступить к созданию сертификата для будущего NLS сервера. Для этого, в существующею консоль mmc добавим еще одну оснастку Certificates.

1-31-2014 10-13-36 PM

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

1-31-2014 10-15-03 PM

В разделе Personal, создадим запрос о новом сертификате.

1-31-2014 10-16-11 PM

Сертификат будет создан на основании ранее редактируемого шаблона Web Server. При выпуске, в сертификате с полем Common Name, вписываем FQDN сервера NLS.

1-31-2014 10-20-16 PM

На этом шаге подготовка всех условий выполнена и теперь можно приступать к установке и конфигурированию самих служб DA.

Развертывание

Начиная с выхода Windows Server 2012, службы RRAS и Directaccess могут существовать друг с другом на одном сервере. Так же еще одним изменением стало управление службами через единую консоль Remote Access Management Console. Хотя служба RRAS была установлена во время конфигурирования VPN, сама консоль на WSE отсутствует. Чтобы ее доставить используем следующий Powershell коммандлет:

Add-WindowsFeature –Name RSAT-RemoteAccess-MGMT

После установки, из Server Manager запускаем консоль Remote Access Management Console и  начинаем конфигурирование Directaccess, как показано на скриншоте:

1-31-2014 10-30-57 PM

Указываем ранее созданную группу безопасности на которую будут применятся настройки DA.

1-31-2014 10-32-53 PM

На следующем шаге мастером автоматически был выбран 3-й сценарий развертывания DA. Это обусловлено тем, что сервер WSE находится за NAT маршрутизатором и он является единственно-поддерживаемым.

1-31-2014 10-34-01 PM

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

1-31-2014 10-38-53 PM

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

Restart-Service RaMgmtSvc

1-31-2014 10-53-00 PM

Для функционирования NLS сервера необходимо скопировать несколько файлов, они находятся в каталогах “C:inetpubwwwroot ” и “C:Program FilesWindows ServerBinWebAppsSiteDefault.aspx”. Используем следующие команды:

XCOPY ‘C:inetpubwwwroot’ ‘C:Program FilesWindows ServerBinWebAppsSiteinsideoutside’ /E

XCOPY ‘C:Program FilesWindows ServerBinWebAppsSiteDefault.aspx’ ‘C:Program FilesWindows ServerBinWebAppsSiteinsideoutside’

После того, как файлы скопированы закончим конфигурацию выбрав 3-й шаг в консоли.

1-31-2014 11-23-21 PM

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

1-31-2014 11-24-53 PM

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

Выполним PS коммандлет:

Get-NetIPAddress –InterfaceAlias IPHTTPSInterface –PrefixLength 128 | ForEach { $_.IPAddress }

2-1-2014 12-54-52 AM

Результатом отработки коммандлета будет 2 IPv6 адреса. Эти адреса необходимы для редактирования групповых политик, которые были созданы мастером DA.

Открываем редактор групповых политик, и ищем 2 групповые политики:

  • DirectAccess Client Settings
  • DirectAccess Server Settings

2-1-2014 6-17-55 PM

Откроем для редактирования политику DirectAccess Client Settings и переходим в настройки Name Resolution Policy. В настройках Name Resolution Policy Table нажимаем Edit Rule. Перезаписываем старое значение теми, которые получили после отработки предыдущего коммандлета2-1-2014 6-28-21 PM

В DirectAccess Server Settings открываем настройки фаервола. Во входящих правилах ищем два правила:

  • Domain Name Server (TCP-In)
  • Domain Name Server (UDP-In)

Открываем оба их на редактирование и во вкладке Scope меняем значения как при редактировании предыдущей политики.

2-1-2014 6-31-44 PM

Далее, следует выполнить коммандлеты

Set-NetDnsTransitionConfiguration –AcceptInterface IPHTTPSInterface

Set-NetNatTransitionConfiguration –IPv4AddressPortPool @(“172.16.20.5, 6001-6601”, “172.16.20.5, 6603-47000”)

<

p>Вместо 172.16.20.5 подставляем адрес сервера WSE.

Restart-Service WinNat

Тестирование

Тестирование проводилось на клиентской ОС Windows 8.1 которая развернута на другом хосте виртуализации с доступом в сеть интернет. Используя Offline Domain Join вместе с Directaccess машина успешно вошла в домен. На скриншоте видно, что подключение по Directaccess активно. 2-1-2014 7-27-01 PM

2-1-2014 7-27-39 PM

Выводы

<

p>Наличие поддержки технологии Directaccess в линейке WSE 2012 и 2012 R2 дает дополнительную гибкость и преимущества в работе удаленных клиентов. Хотя в WSE 2012 R2 существует возможность автоматического подключения по VPN (настраивается через Launchpad), Directaccess предоставит гораздо больше возможностей. Так как DA позиционируется как возможность корпоративного уровня, для своей работы, со стороны клиентов, требуется наличие ОС Windows 8, 8.1 редакции Enterprise либо Ultimate. Это единственная преграда, по которой DA не сможет быть развернут. Если же ее нет, на мой взгляд, наличие DA обязательно.

One thought on “Развертывание Directaccess в Windows Server 2012 R2 Essentials

  1. Добрый день,
    Сделал всё как вы описали, на этапе “выбрать заранее созданный сертификат для NLS сервера” получаю сообщение о ошибке: “Не удается разрешить имя субъекта в допустимый ip-адрес”. Подскажите пожалуйста в как исправить? DNS запись проверил, совпадает с CN именем сертификата, и имеет доступный IP. Заранее спасибо.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.