Развертывание Directaccess (упрощенная установка)
Продолжая свое повествование о Directaccess, в этой статье я продемонстрирую способ упрощенной установки данного сервиса. Статья является продолжением предыдущей публикации, где были описаны задачи и цели как таковые, а также заложен фундамент для дальнейших действий описанных в данной публикации.
И так, в названии присутствует словосочетание «упрощенная установка», это отнюдь не означает что она таковой является (хотя по сравнению с установкой в WindowsServer 2008 R2 так и есть). Смысл в том, что множество возможных настроек при развертывании устанавливается в значение по умолчанию. При таком способе сервис работает, как говорят, «из коробки». Конечно в будущем пытливому уму будет предоставлена возможность что-то да как-то изменит или, другими словами, внести коррективы в конфигурацию. Но это уже будет совсем другая история, повествование о которой обязательно можно будет найти в дальнейшем, а если точнее в следующей статье цикла о Directaccess.
Установка Directaccess
Для начала установки на уже подготовленном сервере необходимо развернуть фичу роли Directaccess.
В Server manager необходимо выбрать добавление новой роли или фичи, как показано на скриншоте.
Дойдя по шагам в мастере, необходимо выбрать RemoteAccess
Из интересующего нас, необходимо выбрать DirectAccess and VPN (RAS)
После этого, мастер автоматически предложит доустановить дополнительные фичи для работы служб. В них будут входить как консоли управления, так и ряд других ролей.
Далее начинаем установку Install. По старой привычке я поставил чекбокс напротив автоматической перезагрузки сервера, хотя после завершения установки система ее не потребовала. Сама же перезагрузка требовалась в Windows Server 2012 и, не изменяя традициям, все же ее произвел вручную.
Настройка Directaccess
Сервер перезагружен и готов к настройке.
В Server Manager, в области уведомлений, вызываем мастер настройки удаленного доступа.
На следующем шаге, необходимо выбрать Deploy DirectAccess only. Сей час и в ближайших статьях я буду рассматривать только установку DirectAccess без VPN хотя существуют сценарии когда их можно развернуть одновременно. Собственно, это является одной из особенностей DirectAccess на Windows Server 2012 / 2012 R2, так как в Windows Server 2008 R2 это сделать не представлялось возможным.
Далее, выбираем необходимую сетевую топологию, напоминаю в этой и в последующих публикациях я буду использовать только пограничную топологию, а также публичное DNS имя по которому клиенты будут подключатся к серверу или серверам DA. Кроме наличия самого имени необходимо иметь также SSL сертификат безопасности выписанный на него. В качестве сертификатов допускается использование как корпоративные центры CA, так и публичные от третьих сторон. В отношении корпоративных, необходимо взять на заметку, что ваша PKI инфраструктура должны быть правильно опубликована во внешнею сеть. Допускается использование SAN, а также Windcard типов сертификатов, собственно в этой лабе как раз будет использован Windcard сертификат от третей стороны.
Хотя все настройки можно оставить по умолчанию, все же я внесу определенные правки для дальнейшей работоспособности лабы.
В секции Remote Clients выбираем Change.
По умолчанию, группа которой разрешено получать настройки DirectAccess это Domain Computers, то есть все компьютеры домена. На мой взгляд под клиентские компьютеры, под которые планируется DA, необходимо создать отдельную группу безопасности и указать ее в мастере. Далее, также желательно снять чекбокс с Enable DirectAccess for mobile computers only. После выполнения данного шага созданная в последствии групповая политика не будет обладать специфическим WMI фильтром. Задача этого фильтра, это отсеивание компьютеров которые обладают физической архитектурой отличной от архитектуры ноутбуков.
Следующий весьма не примечательный шаг, это указание почтового ящика хелпдеска. Не примечательный потому, что если он не будет указан, клиентская машина, которая по тем или иным причинам не может подключится к серверам DA, не сможет собрать лог-файлы для последующего анализа. По этому, на мой взгляд, стоит его указывать.
После внесения изменений, необходимо лишь запустить мастер и дальше процесс развертывания происходит полностью автоматически.
Не сразу, а примерно через 2-3 минуты при просмотре всех служб DA их статус будет свидетельствовать что все хорошо. Теперь стоит перейти к тестированию и получению первых результатов.
Тестирование конфигурации
Для тестирования была взята виртуальная машина обладающая двумя сетевыми интерфейсами. Первый смотрит в локальную сеть предприятия, второй – во внешнюю. Цель тестирования показать получение настроек DA, а также подключение к корпоративным ресурсам предприятия.
Как видно на скриншоте, подключение DA отсутствует. Для появления подключения необходимо выполнить процесс скачивания и применения групповых политик.
Применив групповые политики просмотрим результат. Со скриншота видно, что групповые политик DA успешно применились.
Далее я произведу отключение от корпоративной сети и подключение к внешней.
Открыв подключения, видно что DirectAccess активен.
Далее я произвел ряд тестов на подключения как со стороны клиентской машины так и со стороны корпоративной инфраструктуры.
Доступ к файлам которые находятся на файловом сервере который работает под управлением Windows Server 2012 R2
Доступ к файлам которые находятся на файловом сервере который работает под управлением Windows Server 2003 R2
Открытие RDP сессии к файловому серверу.
Открытие корпоративного веб сайта.
Возможность RDP доступа с сервера внутри организации.
Выполнение эхо запросов к клиенту DA
Выполнение эхо запросов к контроллеру домена.
Применение групповых политик.
Выводы
В статье “Развертывание Directaccess (упрощенная установка)” я продемонстрировал процесс базовой настройки DirectAccess и тестирование на клиентской машине под управление Windows 8.1 Enterprise. В следующей статье я рассмотрю уже комплексное развертывание, в котором будут описаны дополнительные настройки и возможности технологии. Слетите за обновлениями!
Спасибо, очень интересный цикл статей.