Главная Networks, Security, Windows, Новое Microsoft DirectAccess 2012: Введение
  • Microsoft DirectAccess 2012: Введение

    ed31_earth_in_my_room

    Время не стоит на месте, и мы, что бы не отставать от современного ритма, должны быть активными и мобильными. Для организаций любого уровня становится все  более важным иметь простой и  безопасный способ подключения удаленных и мобильных клиентов к внутренней сети предприятия. Одной из распространенных технологий удаленного доступа  является  VPN, хотя можно было обойтись и без него, используя  прямые подключения средствами RDP, Radmin, Ammyy и тому подобных вещей. Теперь в списке появляется значимая альтернатива — Microsoft DirectAccess 2012. Число 2012 говорит нам о том, что это сервис включенный в новую редакция сервера Windows Server 2012. Это важно, потому что DirectAccess уже был реализован в 2008 R2, но с кучей нюансов и серьезных требований к инфраструктуре предприятия, где внедряли DirectAccess 2008 R2. Именно поэтому  я специально сказал, что только теперь появилась альтернатива для удаленного подключения клиентов, и сейчас объясню почему.

     

    DirectAccess 2008 R2 требовал для работы выполнение условий, сложность которых, я думаю, оценить сможет каждый сам:

     

    1. Сервер DirectAccess обязательно должен был иметь 2 сетевых адаптера: один смотрящий в интернет, другой во внутреннюю сеть. То есть сервер обязательно должен был быть пограничным и не мог располагаться за NAT.
    2. Обязательно наличие двух «белых» IP адресов на сетевом интерфейсе, смотрящими наружу.
    3. Требование к наличию инфраструктуре открытых ключей (PKI — Public Key Infrastructure) в организации. Сертификаты требовались для работы IPsec.
    4. Требование к развернутой инфраструктуре IPv6 в организации. Или требовалось использовать NAT64/DNS64 сервис преобразования IPv6 в IPv4 (например, UAG — Unified Access Gateway).
    5. Не было возможности легко настроить несколько серверов DirectAccess для сайтов Active Directory (распределение по географическому положения) или распределить нагрузку между серверами DirectAccess средствами сетевой балансировки.
    6. Не было возможности настроить DirectAccess для работы несколькими доменами.

     

    Как видно из требований, позволить полное выполнение требований могла далеко не каждая организация.  Ограничения могли быть непреодолимой проблемой для внедрения даже в крупных  организация. Но с выходом сервера 2012 с новым DirectAccess ситуация значительно улучшилась:

     

    1. Теперь серверу DirectAccess не обязательно быть пограничным и он может быть за NAT. Может иметь только один сетевой адаптер с одним IP адресом локальной сети. Теперь мы можем выбрать из трех положений сервера в схеме сети: Пограничный с двумя сетевыми картами, Сервер в DMZ с двумя сетевыми картами, Сервер во внутренней сети с одной сетевой картой. Но даже для пограничного сервера требования к двум «белым» IP адресам отпало.
    2. Наличие PKI в организации теперь не обязательное требование. Если будут использоваться удаленные клиенты с Windows 8 Enterprise, то можно обойтись без PKI, для аутентификации компьютеров будет использоваться Kerberos-прокси (запрос проверки подлинности от клиента передается прокси-службе Kerberos, которая выполняется на сервере DirectAccess. Затем прокси-служба Kerberos от имени клиента отправляет запросы Kerberos контроллерам домена). PKI требуется, если будут использоваться клиенты с Windows 7 Enterprise или Ultimate или требуются расширенные опции.
    3. Теперь наличие сети IPv6 в организации не требуется, то, что до этого делал UAG, делает сам сервер DirectAccess (NAT64/DNS64).
    4. Теперь значительно проще развернуть распределение серверов по сайтам Active Directory и использовать сетевую балансировку (Network Load Balancing).
    5. Появилась поддержка нескольких доменов Active Directory.
    6. Поддержка NAP (Network Access Protection) и OTP (One Time Password) из коробки, опять же можем обойтись без UAG.
    7. Так же из коробки получаем поддержку «Force Tunneling», когда клиенты используют удаленный шлюз при подключении к внутренним ресурсам сети и к интернет.
    8. Теперь управление Direct Access осуществляется из единой консоли управления удаленным доступом, так же используется для управление VPN доступом. То есть до этого было две отдельные службы DirectAccess и RRAS, и вместе они конфликтовали на одном сервере, теперь они изначально родственны и работают вместе.
    9. DirectAccess 2012 теперь можно настроить только для удаленно управления, без возможности доступа удаленных клиентов во внутреннюю сеть. Для многих это единственное требование для DirectAccess, теперь такое ограничение возможно задать на этапе настройки конфигурации.

     

    Список улучшений значителен и все значительно упрощает. Следовательно, инсталляций данного решение будет гораздо больше, чем у DirectAccess 2008 R2.

    По сути своей DirectAccess похож на привычный VPN доступ (Virtual Private Network), так как результат работы двух технологий один – дать возможность удаленным клиентам быть частью внутренней корпоративной сети. Но разница есть, и довольно существенна, что позволяют заявить, что DirectAccess на базе Windows Server 2012 размывает отличия между компьютерами внутренней корпоративной сети и удаленных клиентов, делает их менее заметными. Ниже приведу сравнение нового DirectAccess с технологией VPN.

     

    • Пользователю не надо запускать никаких программ, ярлыков, VPN-клиентов, VPN-соединений. Компьютер подключается к корпоративной сети еще в момент загрузки операционной системы.
    • Так как компьютер уже находится в корпоративной сети еще на стадии загрузки, то он получает обновления доменных групповых политик и других изменений, которые возможны только на этапе загрузки компьютера.
    • Компьютеру достаточно просто загрузится, что бы появлялась возможность подключения к нему, например по RDP. Загрузка учетной записи на этом компьютере не требуется.
    • Канал связи между компьютером и корпоративной сетью шифруется стойкими алгоритмами с использованием IPsec. Что бы использовать IPsec при VPN, надо постараться, обычно все заканчивается PPP.
    • Есть возможность добавить нативную поддержку двух-факторной аутентификации с использованием одноразовых паролей (OTP).  Для VPN такой нативной поддержки нет, требуется использовать дополнительное ПО.
    • Для соединения удаленного клиента и сервера DirectAccess используется только один порт – 443 (HTTPS), так как этот порт открыт почти на каждом фаерволе, то у клиента не будет проблемы с подключением, где бы он ни был. В VPN это можно достичь, используя только протокол SSTP.
    • Есть возможность добавить удаленную машину в домен, используя технологию Offline Domain Join, и при следующей загрузке она будет частью корпоративной сети, используя подключения DirectAccess.
    • К плюсам VPN можно отнести то, что удаленным клиентам не обязательно быть членами домена, для DirectAccess это требование. Из-за этого стоит признать, что Direct Access не замещает VPN.

     

    Отличие очень значимые, на выходе мы получаем решение, которые позволит удаленным клиентам чувствовать себя «как на работе», а ИТ-подразделениям не терять связь с удаленными машинами и держать их в актуальном состоянии в плане безопасности, так же как и «местные» машины. Но что бы сравнивать две технологии, требуется не только сопоставить различия, но и понимать, как они работают. Рассказывать про то, как функционирует VPN не стоит, поэтому давайте посмотрим на  DirectAccess.

    image

    Рисунок 1. Сеть предприятия с DirectAccess

    На рисунке 1 показана реализация, примерно так будет схематически выглядеть сеть предприятия, где используется DirectAccess вместе с PKI. Но как же работает DirectAccess? Рассмотрим две основных ситуации: когда клиент физически находится внутри сети или когда он расположен снаружи.

    image

    Рисунок 2. Клиент внутри корпоративной сети

    На рисунке 2 показана ситуация, когда клиенты DirectAccess находятся внутри сети. Тут стоит пояснить, кто такие эти клиенты DirectAccess. Клиент DirectAccess – компьютер, на котором были применены групповые политики, передающие ему настройки для подключения через DirectAccess. Групповые политик создаются на этапе конкурирования сервера DirectAccess и распространяются на группу (ы) безопасности в Active Directory. После этого компьютер становится клиентом DirectAccess в не зависимости от местоположения. Важным шагом для определения клиентом своего местоположения служит проверка доступности сервера NLS. Если он доступен, то клиент считает себя внутри сети, если не доступен, то будет подключаться через сервер DirectAccess. Тут важную роль играет политики преобразования имен (NRPT – Name Resolution Policy Table), она указывает, если идет обращение к имени, суффикс которого совпадает с суффиксом домена локальной сети, то использовать DNS сервера локальной сети, если не совпадает, то использовать DNS сервера указанные в настройках TCP/IP клиента. Но для правильной проверки NLS его DNS-имя (например, nls.domain.name) заносится в исключения NRPT, что бы разрешение имени происходило через DNS сервера указанные на сетевом адаптере. Если клиент находится внутри корпоративной сети, то DNS сервера используются локальные, а они знают где NLS сервер. Находясь во внешней сети, клиент использует внешние DNS  (например, провайдера домашней сети), которые уже не знают, как преобразовать имя NLS сервера. Если клиент нашел NLS сервер, то политики безопасного подключения (IPsec) не применяется  и клиент работает в сети как обычно.

    image

    Рисунок 3. Клиент снаружи корпоративной сети

    На рисунке 3 демонстрируется ситуация, когда клиент оказался во внешней сети (не корпоративная сеть, но есть доступ в интернет). Клиент делает попытку соединяться с сервером NLS по DNS-имени, так как это имя находится в исключениях NRPT, то идет обращение к DNS-серверам, которые клиент получил через настройки TCP/IP. Так как эти DNS не корпоративные, то у них нет записи о NLS. Получив отказ в разрешении имени, клиент (компьютер) применяет политики IPsec, которые срабатывают именно в такой момент, и обращается к серверу DirectAccess по его DNS-имени, вот это имя уже должно быть прописано во внешней зоне корпоративного домена. Если имя разрешается, то устанавливается HTTPS туннель с сервером Direct Access, используется веб-сертификат сервера DirectAccess. После этого компьютер соединяется с серверами по туннелю инфраструктуры (Infrastructure tunnel), для аутентификации клиента используя сертификат компьютера. По этому туннелю можно соединяться только к указанным в групповой политике серверам (контролер домена, DNS-сервер), которые обеспечивают возможность аутентификации пользователя и получения им маркера доступа (Kerberos Access Token). Если аутентификация прошла успешно (маркер получен), то клиент сможет подключаться к любому точке, будто он внутренней клиент, используя туннель интрасети (Intranet tunnel). В Direct Access 2012 есть возможность настройки подключения в упрощённом режиме, тогда используется только один туннель IPsec, и не требуется сертификат для компьютера, будет использоваться Kerberos-прокси. Из ограничений: только Windows 8 Enterprise и нет возможности задействовать такие функции как принудительное туннелирование, проверка доступа к сети (NAP) и двух-факторную аутентификацию (OTP).

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

     

    • Доступ только для Windows 8 клиентов с одной входной точкой
    • Доступ только для Windows 8 клиентов с несколькими точками входа
    • Доступ для клиентов Windows 7 и Windows 8 с одной входной точкой
    • Доступ для клиентов Windows 7 и Windows 8 с несколькими точками входа
    • Дополнительно есть возможность внедрить двухфакторную аутентификацию для подключений Direct Access с помощью OTP и/или защиту сети с помощью NAP

     

    Каждый вариант вносит поправки к требованию к ИТ-инфраструктуре, например, как уже указывалось выше, если будут использоваться клиенты с Windows 8, то PKI не нужен. И для дополнительных опций требуется дополнительные сервера.

    Обязательно надо учитывать минимальные требования перед тем, как начать внедрять DirectAccess:

     

    • Один сервер с серверной операционной системой Windows Server 2012 Standard. Требование по железу минимальны по современным меркам, конечно, все зависит от нагрузки, но одного виртуального процессора и 2 ГБ памяти будет достаточно для небольшого количества одновременных подключений.
    • Клиентские операционные системы Windows 7 Enterprise (Корпоративная) или Ultimate (Максимальная) и Windows 8 Enterprise (Корпоративная). На других операционных системах Direct Access не заведётся.
    • Сервер и клиенты должны быть в одном домене.

     

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

     

     

    Дмитрий Фомичев

Комментарии

  1. Эх, если б еще с Enterprise не надо было связываться...

  2. Direct Access стал уже лучше, но меня огорчает требование быть в домене для удаленных машин, многие пользователи работают с личных ПК...

  3. Т.е. Windows 7 Prof — побоку?

  4. К сожалению да. Только те ОС, которые указаны в статье.

  5. А поддержка на уровне рутеров ipv6 нужна?

    Потому что у меня после кофигурирования пишет на клиенте после запуска netsh int httpstunnel show interfaces:

    ...

    Last Error Code: 0×32

    Interface Status: IPHTTPS interface administratively disabled

    Что значит административно?

  6. Поддержка у роутера IPv6 конечно нужна, но отсутвие такого уже наверно и не встретить.

    HKLM\SOFTWARE\Policies\Microsoft\Windows\TCPIP\v6Transition\IPHTTPS\IPHTTPSInterface\IPHTTPS_ClientState

    Какое значение у данного ключа? Если 3 — значит выключен интерфейс HTTPS.

  7. Дмитрий спасибо.

    В ветке значение 0.

    Но рутер точно не поддерживает ipv6.

    А зачем он вообще нужен если используются v6transition технологии?

  8. Хм, если значение 0, то IPHTTPS должен быть включен и такой ошибки появляется не должно.

    Если Direct Access сервер пограничный, то нам все равно на роутер. А вот если за NAT, то тут облом.

  9. Дмитрий, такой вопрос: как Direct Access будет работать, если он находится за НАТ и имеет внутренний IP-адрес? Запись в ДНС-сервере?

  10. Сергей, будет, это один из новых и для многих решающий фактор в версии 2012.

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

  11. Дмитрий: подскажите пожалуйста в чем проблема?

    Сервер DA находится за NAT, удаленный клиент выдает ошибку 0×0 Состояние: IPHTTPS интерфейс не установлен.

    Заранее спасибо

  12. […] прошлой статье я постарался в понятной форме рассказать о […]

Опубликовать

Я не робот.