Знакомство со службой DirectAccess - Center

Руководство по эксплуатации DirectAccess
Семейство операционных систем Microsoft Windows
Корпорация Майкрософт
Дата опубликования: июль 2009
Краткий обзор
В этом документе представлено описание службы, определены новые термины, приведены
требования для установки, рассмотрен проект архитектуры для развертывания службы DirectAccess и
шаги установки ОС Windows Server 2008 R2 Release Candidate.
Информация об авторских правах
Этот документ выпущен в поддержку предварительной версии программного продукта, который до
выпуска окончательной коммерческой версии может быть значительно изменен. Настоящий документ
предоставляется только в информационных целях, и корпорация Майкрософт не дает в нем какихлибо гарантий как в явной форме, так и подразумевающихся. Содержащиеся в этом документе
сведения, включая адреса URL и другие ссылки на веб-сайты в Интернете, могут измениться в любой
момент без предварительного уведомления. Весь связанный с использованием или результатами
использования этого документа риск несет пользователь. Все упомянутые в примерах компании,
организации, продукты, доменные имена, адреса электронной почты, логотипы, люди, места и
события являются вымышленными, если не указано обратное. Любые возможные совпадения с
реально существующей компанией, организацией, продуктом, доменным именем, адресом
электронной почты, логотипом, человеком, местом или событием являются непреднамеренными и не
должны трактоваться иначе. Обязанности по соблюдению всех применимых законов о защите
авторских прав лежат на пользователе. Не ограничивая авторские права, никакая часть этого
документа не может быть воспроизведена, сохранена или включена в поисковую систему, равно как
передана в любой форме, любым способом (электронным, механическим, фотокопировальным,
звукозаписывающим и другими) и с любой целью без письменного разрешения корпорации
Майкрософт.
На содержание этого документа могут распространяться патенты, заявки на патенты, товарные знаки,
авторские права или другие права интеллектуальной собственности, принадлежащие корпорации
Майкрософт. За исключением случаев заключения письменного лицензионного соглашения с
корпорацией Майкрософт в явной форме этот документ не предоставляет каких-либо лицензий на
использование патентов, товарных знаков, авторских прав или иных прав интеллектуальной
собственности.
© Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.
Microsoft, Active Directory, Hyper-V, PowerShell, Windows, Windows Server, Internet Explorer и Windows
Vista являются охраняемыми товарными знаками группы компаний корпорации Майкрософт. Все
остальные товарные знаки являются собственностью соответствующих владельцев.
Оглавление
Руководство по эксплуатации DirectAccess .................................................................................................... 1
Знакомство со службой DirectAccess ............................................................................................................... 7
Общее описание службы DirectAccess ............................................................................................................ 8
Сценарий применения службы DirectAccess ............................................................................................... 8
Преимущества использования службы DirectAccess.................................................................................. 9
Возможности подключения ............................................................................................................................. 10
IPv6 ................................................................................................................................................................ 10
Технологии перехода на протокол IPv6 .................................................................................................. 10
Возможности внешних подключений .......................................................................................................... 10
6to4 ............................................................................................................................................................. 11
Teredo ........................................................................................................................................................ 11
IP-HTTPS ................................................................................................................................................... 11
Возможности подключения в интрасети .................................................................................................... 12
Протокол ISATAP ...................................................................................................................................... 12
Устройства NAT-PT ................................................................................................................................... 12
Таблица политики разрешения имен и служба DNS ................................................................................ 13
Исключения таблицы NRPT ..................................................................................................................... 14
Суффиксы DNS ......................................................................................................................................... 14
Служба WINS и разрешение имен .......................................................................................................... 15
Протокол IPsec ................................................................................................................................................. 15
Шифрование ................................................................................................................................................. 16
Целостность данных .................................................................................................................................... 16
Определение нахождения клиента в интрасети ........................................................................................... 17
Принципы определения нахождения в интрасети .................................................................................... 17
Требования и необходимые условия............................................................................................................. 18
Требования к конфигурации........................................................................................................................ 18
Сервер DirectAccess ................................................................................................................................. 18
Клиент DirectAccess .................................................................................................................................. 19
Требования к инфраструктуре и вопросы для рассмотрения .................................................................. 19
Исключения брандмауэра ........................................................................................................................... 21
Дополнительные параметры развертывания и вопросы для рассмотрения ............................................. 22
Принудительное туннелирование .............................................................................................................. 23
Удаленное управление клиентами DirectAccess ....................................................................................... 23
Публично доступные имена ........................................................................................................................ 24
Связь между клиентами DirectAccess ........................................................................................................ 25
Обработка большого объема запросов проверки подлинности .............................................................. 26
Использование смарт-карт со службой DirectAccess................................................................................ 26
Блокирование клиентов DirectAccess ......................................................................................................... 30
Обеспечение безопасности Internet Explorer ............................................................................................. 30
Проектирование решения на базе службы DirectAccess ............................................................................. 31
С чего начать? .............................................................................................................................................. 31
Факторы, учитываемые при проектировании решения ............................................................................ 31
Выбор модели доступа ................................................................................................................................ 32
Полный доступ к интрасети (от узла до периметра) ............................................................................. 32
Доступ к отдельным серверам (модифицированная модель «от узла до периметра») .................... 33
Модель «от узла до узла» ........................................................................................................................ 34
Модель с одним и несколькими серверами ............................................................................................... 34
Один сервер .............................................................................................................................................. 35
Несколько серверов для повышения бесперебойности ....................................................................... 35
Выбор способа развертывания ................................................................................................................... 36
Консоль управления DirectAccess ........................................................................................................... 37
Установка с помощью сценариев и средства Netsh.exe ....................................................................... 37
Настройка клиентов вручную с использованием групповой политики ................................................ 37
Мониторинг службы DirectAccess ................................................................................................................... 37
Состояние сервера DirectAccess ................................................................................................................ 38
Компоненты сервера DirectAccess ............................................................................................................. 39
Пакет управления......................................................................................................................................... 39
Отображение сервера DirectAccess в серверной консоли Operations Manager 2007 ........................ 39
Уведомления сервера DirectAccess ........................................................................................................ 39
Интеграция службы DirectAccess со средствами изоляции серверов и доменов ..................................... 45
Ссылки .............................................................................................................................................................. 46
Диагностика и устранение неполадок............................................................................................................ 46
Приложение A — обзор установки ................................................................................................................. 48
Начальные шаги ........................................................................................................................................... 48
Приложение B — инструкции по использованию мастера DirectAccess Setup Wizard (мастер настройки
DirectAccess) ................................................................................................................................................. 50
Шаг 1 — удаленные клиенты ...................................................................................................................... 52
Шаг 2 — сервер DirectAccess ...................................................................................................................... 52
Возможности подключения ...................................................................................................................... 53
Сертификаты ............................................................................................................................................. 53
Шаг 3 — серверы инфраструктуры ............................................................................................................. 54
Размещение .............................................................................................................................................. 54
DNS-сервер и контроллер домена .......................................................................................................... 55
Управление................................................................................................................................................ 56
Шаг 4 — серверы приложений .................................................................................................................... 57
Приложение C — инструкции по установке одиночного сервера DirectAccess с использованием
сценариев ..................................................................................................................................................... 58
Настройка компонентов доступа к Интернету ........................................................................................... 59
Настройка компонентов доступа к интрасети ............................................................................................ 60
Настройка служб безопасности .................................................................................................................. 63
Конфигурация IPSec .................................................................................................................................... 63
Конфигурация шлюза IPsec (модель «от узла до периметра») ........................................................... 63
Настройка клиента IPsec (модель "от узла до периметра") ................................................................. 64
Приложение D — инструкции по настройке клиента DirectAccess с помощью сценариев и групповой
политики ........................................................................................................................................................ 66
Компоненты подключений ........................................................................................................................... 66
Таблица Name Resolution Policy Table ....................................................................................................... 67
Приложение E — советы по использованию сценариев ............................................................................. 67
Сценарии пользовательского интерфейса DirectAccess .......................................................................... 68
Конструкция сценариев ............................................................................................................................ 68
Использование сценариев ....................................................................................................................... 69
Файл журнала ............................................................................................................................................ 69
Ограничения при использовании сценариев ......................................................................................... 70
Использование сценариев для настройки правил IPsec .......................................................................... 70
Приложение F — файл DirectAccessConfig.xsd ............................................................................................ 71
Знакомство со службой DirectAccess
В этом документе представлено описание возможностей, определены новые термины,
приведены требования для установки, рассмотрен проект архитектуры для развертывания
службы DirectAccess и шаги установки ОС Windows Server 2008 R2 Release Candidate (RC).
Основная часть документа включает следующие разделы, посвященные общему описанию
службы DirectAccess:
Общее описание службы DirectAccess
Возможности подключения
Протокол IPsec
Определение нахождения клиента в интрасети
Требования и необходимые условия
Дополнительные параметры развертывания и вопросы для рассмотрения
Проектирование решения на базе службы DirectAccess
Мониторинг службы DirectAccess
Интеграция службы DirectAccess со средствами изоляции серверов и доменов
Ссылки
Диагностика и устранение неполадок
Приложения содержат сведения, необходимые для установки и развертывания службы
DirectAccess. В документе имеются следующие приложения:
Приложение A — обзор установки
Приложение B — инструкции по использованию мастера DirectAccess
Приложение C — инструкции по установке одиночного сервера DirectAccess с
использованием сценариев
Приложение D — инструкции по настройке клиента DirectAccess с помощью сценариев и
групповой политики
Приложение E — советы по использованию сценариев
Приложение F — файл DirectAccessConfig.xsd
Примечание
Служба DirectAccess не поддерживает обновления с более старых версий
Windows® 7 и Windows Server 2008 R2 до версии RC.
Примечания

Полный список ресурсов, посвященных ОС Windows 7, статьи, демонстрационные
материалы и руководства см. в разделе Семейство ОС Windows 7 на веб-сайте
Windows Client TechCenter (на английском языке).

Загружаемую версию этого документа см. на веб-странице Знакомство со службой
DirectAccess (на английском языке) в центре загрузки Майкрософт
(http://go.microsoft.com/fwlink/?LinkId=151747).
Общее описание службы DirectAccess
В настоящее время сотрудники более мобильны и во время поездок им требуется доступ к
ресурсам корпоративной интрасети. Ранее непросто было обеспечить такие возможности
доступа в безопасной, управляемой и легко доступной среде. В операционные системы
Windows Server 2008 R2 и Windows 7 добавлена новая служба DirectAccess, позволяющая
обеспечить удобный удаленный доступ к ресурсам интрасети. В отличие от традиционных
виртуальных частных сетей (VPN), требующих вмешательства пользователя при установке
подключения к интрасети, служба DirectAccess позволяет любому приложению на
клиентском компьютере получить полный доступ к ресурсам интрасети, а ИТадминистраторам — указывать ресурсы и даже клиентские приложения, для которых
удаленный доступ запрещен.
Пользователи получают удобный доступ к ресурсам интрасети без утомительного
ожидания и постоянных переподключений к сети VPN. Организации получают возможность
управлять удаленными компьютерами так, как если бы они находились в локальной сети,
используя те же сервера управления и обновлений. Таким образом обеспечивается
постоянное обновление ПО удаленных компьютеров и их соответствие политикам
безопасности и работоспособности. Администраторы, отвечающие за безопасность, могут
определять более детальные политики управления удаленным доступом по сравнению с
существующими решениями на базе VPN, в то же время эти политики помогут обеспечить
постоянную защиту удаленных компьютеров от разнообразных угроз, возникающих при
использовании Интернета.
Служба DirectAccess позволяет удаленных пользователям подключаться непосредственно
к серверам интрасети, благодаря чему организации могут снизить расходы и упростить
сетевую инфраструктуру, снизив число развернутых серверов приложений внешнего
уровня.
Развертывание службы DirectAccess означает начало перехода на упрощенную сетевую
инфраструктуру и расширение использования политик для обеспечения безопасности.
Внедряя службу DirectAccess, ваша организация закладывает основу безопасной ИТ-среды
с широкими возможностями удаленного доступа.
Сценарий применения службы DirectAccess
Компания Contoso, Ltd является крупнейшим дистрибутором товаров для офиса и
отличается высоким уровнем обслуживания клиентов. Все менеджеры по продажам
Contoso лично посещают своих клиентов раз в квартал.
Франциско Хавьер Кастерджон, старший менеджер по продажам Contoso, направляется в
отель после тяжелого дня, заполненного встречами с клиентами. После регистрации в
отеле и размещения в номере он подключает свой ноутбук к гостевой сети отеля для
подключения к интрасети компании Contoso и отправки нескольких новых заказов.
После подключения к Интернету он запускает веб-браузер и открывает музыкальный сайт,
чтобы послушать любимую музыку. Слушая музыку, передаваемую через Интернет, он
открывает внутреннее приложение по управлению продажами и отправляет новые заказы,
оформленные за сегодня. После окончания отправки Франциско замечает в области
уведомлений новое сообщение от ИТ-администратора, сообщающее о развертывании
критически важного обновления для приложения по управлению продажами на ноутбуке
менеджера.
Преимущества использования службы
DirectAccess
Использование DirectAccess обеспечивает следующие преимущества:

Постоянная возможность подключения —если компьютер подключен к интернету,
он всегда подключен к интрасети компании. Эта возможность упрощает доступ к
клиентскому компьютеру, его обновление, а также обеспечивает постоянную
доступность ресурсов интрасети.

Простота подключения — единая процедура подключения независимо от того,
подключен ли компьютер к корпоративной сети или является удаленным, позволяя
пользователю сосредоточиться на своей работе и не отвлекаться на настройку и
процесс подключения. Это позволит снизить затраты на обучение пользователей и
сократить число обращений в службу поддержки.

Двунаправленный доступ — когда клиентский компьютер со службой DirectAccess
подключен к Интернету, он видим в корпоративной сети и доступен для обновлений и
удаленного управления. Этот двунаправленный доступ помогает снизить время до
получения обновлений клиентом, повышает безопасность и число получивших
обновления клиентов, а также улучшает возможности мониторинга соответствия
корпоративным требованиям.

Улучшенная безопасность — в отличие от традиционных сетей VPN,
обеспечивающих доступ к сети по принципу «все или ничего», DirectAccess
обеспечивает различные уровни доступа, в зависимости от различных параметров. Эти
широкие возможности управления доступом позволяют администраторам точно
контролировать возможности доступа удаленных пользователей к различным ресурсам.

Интегрированное решение — возможности DirectAccess полностью интегрированы с
функциями изоляции серверов и доменов и защиты сетевого доступа (NAP). В
результате обеспечивается наличие единых политик безопасности, доступа и
работоспособности для клиентов в интрасети и удаленных компьютеров.
Возможности подключения
IPv6
Клиенты DirectAccess имеют возможность постоянного подключения к интрасети, а
интернет-протокол версии 6 (IPv6) обеспечивает сквозную маршрутизацию для этого.
Поскольку многие организации еще не выполнили развертывание протокола IPv6, служба
DirectAccess включает технологию перехода на протокол IPv6 для подключения IPv6ресурсов. Дополнительные сведения см. в разделе IPv6 на веб-сайте корпорации
Майкрософт (на английском языке).
Технологии перехода на протокол IPv6
Примерами технологий перехода на протокол IPv6 являются Teredo, 6to4 и протокол IntraSite Automatic Tunnel Addressing Protocol (ISATAP). Эти технологии позволяют использовать
протокол IPv6 даже в том случае, если клиенты DirectAccess подключены к Интернету с
использованием протокола IPv4 и ваша сеть не поддерживает маршрутизацию протокола
IPv6. Технологии перехода на протокол IPv6 помогут упростить и снизить затраты на
развертывание протокола IPv6. Дополнительные сведения см. на веб-странице Технологии
перехода на протокол IPv6 (на английском языке).
Возможности внешних подключений
В таблице ниже приведены возможные конфигурации клиента DirectAccess и
соответствующие им методы передачи трафика IPv6 на сервер DirectAccess. Эти методы
подробнее рассматриваются в следующих разделах.
Если клиент использует:
Предпочтительный метод подключения:
Глобально маршрутизируемый адрес IPv6
Глобально маршрутизируемый адрес IPv6
Внешний адрес IPv4
6to4
Частный адрес IPv4 (NAT)
Teredo
Клиент не может подключаться
перечисленными выше методами
IP-HTTPS
IP-HTTPS обычно используется в том случае, если не может подключаться к серверу
DirectAccess с помощью других методов IPv6 или если включен параметр Force Tunneling
(принудительное туннелирование).
Примечание
При удаленном подключении клиента можно также использовать ISATAP для
обеспечения подключения IPv6. ISATAP может обеспечить подключение к
Интернету с адресами IPv6 или использовать 6to4 для передачи трафика IPv6
через Интернет с адресами IPv4.
6to4
6to4 (технология, определенная в документе RFC 3056) — это технология преобразования
IPv6, обеспечивающая возможность подключения IPv6 через Интернет с адресами IPv4
для узлов и серверов, имеющих публичные адреса IPv4. Дополнительные сведения см. на
веб-странице Технологии перехода на протокол IPv6 (на английском языке).
Teredo
Teredo (технология, определенная в документе RFC 4380) — это технология
преобразования IPv6, обеспечивающая возможность подключения IPv6 через Интернет с
адресами IPv4 для узлов с частными адресами IPv4, расположенных за устройствами
преобразования сетевых адресов (NAT) . Дополнительные сведения см. на веб-странице
Обзор технологии Teredo (на английском языке).
IP-HTTPS
IP-HTTPS — это новый протокол в ОС Windows 7 и Windows Server 2008 R2, позволяющий
узлам, находящимся за прокси-сервером Интернета или брандмауэром устанавливать
соединения путем туннелирования пакетов IPv6 внутри сеансов HTTPS на базе адресов
IPv4. Вместо протокола HTTP используется HTTPS, поэтому прокси-серверы Интернета не
пытаются проверять поток данных и прерывать соединение.
Производительность подключений по протоколу IP-HTTPS может уступать другим
подключения DirectAccess. Для повышения производительности можно предпринять
несколько шагов. Например, можно добавить дополнительные серверы IP-HTTPS с
балансировкой нагрузки. Для дополнительного повышения производительности протокола
можно отключить шифрование IPsec между клиентом и сервером DirectAccess .
Корпорация Майкрософт ищет пути дальнейшего увеличения производительности этого
протокола в следующих версиях ОС Windows.
Дополнительные сведения о протоколе IP-HTTPS см. на веб-странице Спецификации
протокола туннелирования IP поверх HTTPS (IP-HTTPS) (на английском языке).
Примечание
При использовании средств диагностики IP-HTTPS для устранения неполадок
подключения IP-HTTPS необходимо в правилах брандмауэра разрешить серверу
IP-HTTPS отвечать на сообщения Echo Request.
Возможности подключения в интрасети
Клиенты DirectAccess могут подключаться только к серверам интрасети и ресурсам,
доступным по протоколу IPv6. Есть три способа обеспечить такое подключение IPv6 в
интрасети:

Настройка инфраструктуры маршрутизации интрасети для поддержки адресов IPv6.
Серверы и приложения с поддержкой IPv6 станут доступными для клиентов.
Компьютеры под управлением ОС Windows Vista®, Windows Server 2008, Windows 7 и
Windows Server 2008 R2 по умолчанию настроены на использование протокола IPv6.
Хотя не все организации уже развернули инфраструктуру IPv6, это наиболее
предпочтительный и рекомендуемый метод подключения. Организациям
рекомендуется начать планирование развертывания инфраструктуры IPv6, хотя она не
является безусловным требованием для использования DirectAccess.
 Развертывание в интрасети протокола ISATAP. Даже не обладая инфраструктурой IPv6,
можно использовать протокол ISATAP, чтобы сделать серверы и приложения
интрасети доступными путем туннелирования трафика IPv6 поверх существующей
интрасети IPv4. Компьютеры под управлением ОС Windows Vista®, Windows
Server 2008, Windows 7 и Windows Server 2008 R2 поддерживают функциональность
узла ISATAP.

Развертывание в интрасети устройств преобразования сетевых адресов-протоколов
(NAT-PT). Устройства NAT-PT обеспечивают преобразование адресов IPv6/IPv4 для
обмена данными между клиентами DirectAccess, использующими адреса IPv6, и
серверами и приложениями с адресами IPv4.
Примечание
Без использования устройств NAT-PT ресурсы, использующие только адреса IPv4,
недоступны для клиентов DirectAccess. Временным решением проблемы является
использование подключения VPN.
Протокол ISATAP
ISATAP (RFC 4214) — это технология перехода на протокол IPv6, используемая для
обеспечения возможности подключения узлов IPv6 по интрасети с протоколом IPv4.
Технологию ISATAP можно использовать для клиентов DirectAccess для связи по
протоколу IPv6 с узлами ISATAP в интрасети.
Дополнительные сведения о технологии ISATAP см. на веб-странице Технологии перехода
на протокол IPv6 (на английском языке).
Устройства NAT-PT
Чтобы сделать ресурсы, поддерживающие только адреса IPv4, доступными клиентам
DirectAccess, в сети можно установить устройство NAT-PT (RFC 2766). Обычно устройство
NAT-PT настраивается для обслуживания определенных пространств имен DNS. После
установки устройство NAT-PT выполняет необходимые преобразования протоколов IPv6IPv4, позволяя клиентам DirectAccess обращаться к ресурсам с адресами IPv4,
размещенными в этих пространствах имен.
Хотя ОС Windows Server 2003 включает поддержку протокола IPv6, многие встроенные
приложения и системные службы не поддерживают протокол IPv6. Поэтому для доступа к
серверам под управлением ОС Windows Server 2003 как правило требуется установка
устройства NAT-PT. Кроме того, оно необходимо для доступа к ресурсам на серверах,
работающих под управлением ОС, отличных от Windows, за исключением случая, когда
сервер и установленные на нем приложения поддерживают подключения по протоколу
IPv6.
Поскольку в ОС Windows Server 2008 R2 не включены функции преобразования NAT-PT,
настройка устройств NAT-PT не рассматривается. Устройства NAT-PT обычно выпускаются
производителями концентраторов и маршрутизаторов 2-го и 3-го уровня.
Таблица политики разрешения имен и служба
DNS
Для разделения трафика Интернета и интрасети в ОС Windows 7 включена таблица
политики разрешения имен (Name Resolution Policy Table, NRPT), — новая функция,
позволяющая решать следующие задачи:

Определение серверов DNS по пространствам имен DNS, а не по интерфейсам.

Безопасность службы DNS, необходимой для заданного пространства имен, может
быть дополнительно увеличена благодаря использованию протокола IPsec (и других
действий).
Таблица NRPT содержит список пространств имен DNS и соответствующих им настроек
конфигурации, задающих поведение клиента DNS для данного пространства имен. Если
клиент DirectAccess подключен удаленно, каждый запрос имени сопоставляется с
пространствами имен, хранимыми в таблице NRPT. Если обнаружено соответствие, запрос
обрабатывается в соответствии с настройками в таблице NRPT. Эти настройки
определяют, должен ли запрос шифроваться (для защиты от перехвата пакетов и других
атак с подменой данных), а также серверы DNS, на которые будет отправлен запрос.
Если запрос имени не соответствует пространству имен в таблице NRPT, он отправляется
на серверы DNS, указанные в настройках TCP/IP для указанного сетевого интерфейса. Для
удаленного клиента такими серверами, как правило, являются DNS-серверы Интернета,
предоставляемые поставщиком услуг Интернета. Для клиента DirectAccess в интрасети
такими серверами обычно являются DNS-серверы интрасети в соответствии с
конфигурацией DHCP.
Для однословных имен, таких как http://internal, обычно указываются суффиксы DNS,
добавляемые к имени перед проверкой по таблице NRPT. Если эти добавляемые
суффиксы DNS не настроены и однословное имя не соответствует ни одной записи
однословных имен в таблице NRPT, запрос будет отправлен на серверы DNS, указанные в
настройках протокола TCP/IP клиента.
Пространства имен, такие как .internal.contoso.com, вводятся в таблицу NRPT вместе с
серверами DNS, на которые следует направлять такие запросы. Если для DNS-сервера
указан IP-адрес, все запросы DNS будут направляться непосредственно на DNS-сервер по
подключению DirectAccess. При этом нет необходимости настраивать дополнительные
параметры безопасности.
Однако, если в таблице NRPT для DNS-сервера указано имя (например dns.contoso.com),
это имя должно быть общедоступным, так как клиент запрашивает DNS-серверы,
указанные в настройках TCP/IP. Чтобы предотвратить взлом таких запросов к серверу с
общедоступным именем, в таких конфигурациях настоятельно рекомендуется
использовать протокол IPsec.
Таблица NRPT позволяет клиентам DirectAccess использовать внутренние DNS-серверы
для разрешения имен (использование выделенных DNS-серверов не обязательно).
Служба DirectAccess предотвращает трансляцию внутренних пространств имен в Интернет.
Исключения таблицы NRPT
Имеется несколько имен, которые необходимо обрабатывать иначе при разрешении имен;
такие имена не должны разрешаться с использованием внутренних DNS-серверов. Чтобы
эти имена разрешались DNS-серверами, указанными в настройках TCP/IP клиента,
необходим добавить эти имена в исключения таблицы NRPT.
Если для записи таблицы NRPT не указано ни одного адреса DNS-сервера, такая запись
является исключением. Если имя DNS не соответствует ни одной записи таблицы NRPT
или соответствует записи в таблице, не содержащей адресов DNS-серверов, клиент
DirectAccess отправляет запрос на разрешение имени на DNS-серверы, указанные в
настройках TCP/IP клиента.
Если любой из следующих серверов имеет суффикс имени, соответствующий записи
таблицы NRPT для пространства имен интрасети, это имя сервера должно являться
исключением NRPT:

серверы WPAD;

серверы нахождения в сети;

все серверы карантина.
Имена этих серверов должны всегда разрешаться DNS-серверами, указанными в
настройках TCP/IP клиента.
Суффиксы DNS
Поскольку клиенты DirectAccess для определения, отправлять ли полное доменное имя
сервера (FQDN) внутреннему или внешнему DNS-серверу, используют таблицу NRPT,
правильная настройка суффиксов доменов крайне важна для правильной работы службы
DirectAccess. Перед настройкой службы DirectAccess убедитесь в том, что для клиентов
DirectAccess настроены суффиксы поиска DNS для всех доменов, содержащих сервера, к
которым осуществляют доступ клиенты DirectAccess.
Служба WINS и разрешение имен
Служба WINS — это служба разрешения имен для сетей, использующих только адреса
IPv4. Если в вашей сети не установлены устройства NAT-PT, клиентам DirectAccess не
следует использовать службу WINS в качестве резервного средства разрешения имен. В
настоящее время DNS-серверы, используемые удаленными клиентами DirectAccess, не
должны использовать возможности перенаправления службы WINS. Перед выпуском ОС
Windows 7 и Windows Server 2008 R2 будет доступна дополнительная информация,
включающая рекомендации по настройке клиентов DA для использования серверов WINS
при наличии устройств NAT-PT.
Протокол IPsec
Протокол IPsec (Internet Protocol security) представляет собой систему открытых
стандартов для обеспечения конфиденциального защищенного обмена данными в IP-сетях
с использованием криптографических служб безопасности. Стандарты протокола IPsec
определяет рабочая группа Internet Engineering Task Force (IETF).
Протокол IPsec обеспечивает высокий уровень защиты от атак благодаря сквозной защите
трафика. Единственными компьютерами, осведомленными об использовании защиты
IPsec, являются отправитель и получатель данных. IPsec дает возможность защитить
обмен данными внутри рабочих групп, локальных сетей, пользователей домена, сетей
филиалов (которые могут являться удаленными), внешних сетей и с удаленными
клиентами.
Защита IPsec может использоваться в двух различных режимах: режим транспорта и
туннельный режим. Дополнительные сведения см. на веб-странице Типы протокола IPsec
(на английском языке).
Служба DirectAccess использует политики IPsec для проверки подлинности и шифрования
подключений клиентов DirectAccess. Для компьютера одновременно может применяться
несколько политик, выполняющих различные функции. Результатом совместного
применения этих политик является безопасное подключение клиента DirectAccess к
серверу и внутренним службам DirectAccess.
Шифрование
В процессе передачи данных клиентом DirectAccess в интрасеть через Интернет трафик
шифруется. Важным аспектом является также удаленное управление клиентом
DirectAccess, поэтому необходим метод проверки подлинности для клиента до входа
пользователя в систему.
Для этого используется одна из политик IPsec, настраиваемых на клиенте DirectAccess, —
политика туннельного режима (в моделях доступа «от узла до периметра» и «от узла до
периметра с проверкой подлинности доступа») или политика транспортного режима (в
модели доступа «от узла до узла»), определяющая правила передачи данных между
клиентом и интрасетью:

Первая политика требует проверки подлинности с использованием сертификата
компьютера и шифрует трафик с помощью протоколов IPsec и Encapsulating Security
Payload (ESP). Эта политика обеспечивает безопасность связи с контроллерами
домена Active Directory® и другими ресурсам интрасетии до входа пользователя в
систему.

Вторая политика требует проверки подлинности с использованием сертификата
компьютера и учетными данными пользователя Kerberos. Эта политика обеспечивает
защиту связи со всеми ресурсам интрасетии после входа пользователя в систему.
Прекращение сеансов IPsec между клиентом DirectAccess и ресурсами интрасети
выполняется компонентом IPsec Gateway. Эта роль может быть размещена на сервере
DirectAccess или передана отдельному серверу (для повышения производительности).
Более подробные сведения приведены в разделе Выбор модели доступа данного
документа.
Целостность данных
При шифровании с использованием протокола IPsec обеспечивается целостность данных.
Кроме того, можно выбрать обеспечение целостность данных без шифрования. Эта
возможность полезна для защиты от атак перехвата данных и позволяет гарантировать
подключение клиентов к подлинным серверам.
Примечание
Для важных данных протокол IPsec с обеспечением целостности без шифрования
следует использовать только в случае использования других технологий
обеспечения конфиденциальности (шифрования) данных. Можно использовать
политики транспортного режима «от узла до узла», обеспечивающие целостность
данных и политики туннельного режима «от узла до периметра», используемые
только для шифрования.
В службе DirectAccess целостность данных обеспечивается благодаря использованию
политик транспортного и туннельного режимов протокола IPsec. Эти политики могут
применяться для клиентов, серверов и приложений DirectAccess, обеспечивая целостность
данных благодаря использованию протокола ESP-NULL или Authentication Header (AH) для
соединений по протоколу IPsec. Из-за наличия во всех пакетах заголовков IPsec ESP или
AHSome некоторые сетевые устройства и оборудование для мониторинга и анализа
трафика не смогут правильно обрабатывать трафик DirectAccess.
Определение нахождения клиента в
интрасети
Сервер нахождения в сети — это сервер в интрасети, на котором размещен адрес URL,
работающий по протоколу HTTPS. Клиенты DirectAccess открывают этот адрес URL для
определения, находятся ли они в интрасети. Сервером нахождения в сети может быть
сервер DirectAccess, однако рекомендуется использовать отказоустойчивый веб-сервер.
Нет необходимости использовать этот веб-сервер исключительно для функции сервера
нахождения.
Поскольку поведение клиентов DirectAccess зависит от сервера нахождения в сети, крайне
важно обеспечить доступность этого веб-сервера из всех сетей удаленных филиалов. Для
сетей филиалов может потребоваться использовать отдельный веб-сервер, чтобы
обеспечить его доступность даже в случае потери связи. Рекомендуется использовать
отказоустойчивый сервер нахождения в сети (например, кластер серверов) и не совмещать
его с сервером DirectAccess.
Принципы определения нахождения в
интрасети
При запуске клиента DirectAccess или существенном изменении сетевого подключения
(например изменении состояния линии или смене IP-адреса) предполагается, что он не
находится в интрасети и использует записи таблицы NRPT для определения места
назначения запросов DNS. Затем клиент DirectAccess пытается разрешить полное
доменное имя (FQDN) сервера нахождения в сети в адрес URL. Поскольку таблица NRPT
активна, это имя FQDN должно либо соответствовать записи исключения или вообще
отсутствовать в таблице NRPT, чтобы клиент DirectAccess мог использовать DNS-серверы
интрасети, указанные в настройках TCP/IP клиента. Если полное доменное имя FQDN
соответствует записи в таблице NRPT для внутреннего пространства имен, клиент
DirectAccess будет пытаться разрешить имя FQDN, отправляя запросы DNS по адресам
IPv6 из соответствующей записи NRPT.
После разрешения имени FQDN клиент DirectAccess должен иметь возможность успешно
подключиться к HTTPS-адресу URL сервера нахождения в сети; процедура подключения
включает проверку подлинности SSL и проверку сертификата сервера нахождения в сети.
Для проверки подлинности клиента DirectAccess используйте анонимную проверку
подлинности или NTLM. Проверка сертификата включает проверку самого сертификата и
факта того, что он не аннулирован.
Сертификат сервера нахождения в сети должен быть снабжен следующими данными:

Внутренний IPv4-адрес сервера нахождения в сети или полное доменное имя FQDN,
соответствующее имени FQDN в адресе URL, в поле Subject сертификата.

Адрес точки распространения списка отзыва сертификатов (CRL), доступный клиентам
DirectAccess в интрасети.
Аналогично адресу URL сервера нахождения в сети, имя FQDN в адресе URL точки
распространения списка CRL должно соответствовать записи исключения или не
совпадать ни с одной записью в таблице NRPT, чтобы клиент DirectAccess мог
использовать для разрешения имени внутренние DNS-серверы, указанные в настройках
TCP/IP. Если клиент DirectAccess не может разрешить имя FQDN в адресе URL точки CRL,
процедура обнаружения нахождения в интрасети заканчивается неудачей и клиент
DirectAccess не может использовать DNS для доступа к ресурсам интрасети.
При успешном доступе клиента DirectAccess к адресу HTTPS-URL сервера нахождения в
сети и прохождении проверки его сертификата клиент определяет, что он подключен к
интрасети, записи NRPT удаляются из текущей таблицы и клиент использует DNS-серверы,
указанные в настройка TCP/IP, для разрешения всех имен.
Требования и необходимые условия
Перед развертыванием службы DirectAccess убедитесь, что ваша ИТ-среда соответствует
всем требованиям по оборудованию, инфраструктуре и конфигурации сети,
перечисленным в этом разделе.
Требования к конфигурации
Ниже приведены требования для сервера и клиента DirectAccess.
Сервер DirectAccess
Требования для сервера DirectAccess:

включение в домен Active Directory;

ОС Windows Server 2008 R2;

наличие по крайней мере двух физических сетевых адаптеров;
 наличие по крайней мере двух последовательных статических публичных IPv4-адресов,
разрешаемых снаружи посредством DNS-серверов Интернета (адреса в диапазонах
10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 являются частными адресами IPv4 и не могут
использоваться);

сервер не должен находиться за устройством NAT.
Примечания

Необходимость наличия двух последовательных публичных IPv4-адресов связана с
тем, что сервер DirectAccess может использоваться как сервер Teredo, и Windowsклиенты Teredo могут использовать DirectAccess для определения типа
транслятора сетевых адресов (NAT), за которым они находятся. Дополнительные
сведения см. на веб-странице Обзор технологии Teredo (на английском языке).

В консоли управления 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 устанавливается на сервере с помощью диспетчера
сервера. Консоль управления DirectAccess служит для настройки параметров сервера и
клиентов DirectAccess и для мониторинга состояния сервера DirectAccess.
В зависимости от требований плана развертывания и масштабируемости может
потребоваться несколько серверов DirectAccess. Дополнительные сведения см. в разделе
Выбор модели масштабирования в этом документе. Серверы DirectAccess не должны
нести других основных серверных функций, для службы DirectAccess следует использовать
выделенные серверы.
Клиент DirectAccess
Требования к клиентам DirectAccess:

включение в домен Active Directory;

ОС Windows 7 Ultimate или Enterprise либо ОС Windows Server 2008 R2;
Клиенты, не входящие в домен Active Directory, а также клиенты под управлением ОС
Windows Vista и более ранних версий, а также ОС Windows Server 2008 и более ранних
версий, не поддерживаются.
Требования к инфраструктуре и вопросы для
рассмотрения
Требуется следующая инфраструктура:
 Active Directory — должен быть развернут по крайней мере один домен Active Directory.
Рабочие группы не поддерживаются. Дополнительные сведения об установке Active
Directory см. в руководстве Пошаговые инструкции по установке и удалению доменных
служб Active Directory в Windows Server 2008 (на английском языке).

Групповая политика — рекомендуется использование групповой политики для
централизованного управления и развертывания параметров клиентов DirectAccess.
Мастер DirectAccess Setup Wizard (мастер настройки DirectAccess) создает набор
объектов групповой политики и параметров настройки для клиентов DirectAccess,
сервера DirectAccess и серверов управления. Дополнительные сведения см. в
руководстве Планирование и развертывание групповой политики (на английском языке).

DNS и контроллер домена — необходимо использовать по крайней мере один
контроллер домена и DNS-сервер под управлением ОС Windows Server 2008 SP2 или
более поздней версии либо ОС Windows Server 2008 R2.

Инфраструктура открытых ключей (PKI) — требуется для выдачи сертификатов
проверки подлинности компьютеров, также может использоваться для выдачи
сертификатов работоспособности при использовании технологии защиты доступа к
сети (NAP). Внешние сертификаты не требуются. Дополнительные сведения об
использовании инфраструктуры PKI со службой сертификации Active Directory
Certificate Services см. на веб-странице Службы сертификации Active Directory (на
английском языке).
Сертификат SSL для IP-HTTPS, установленный на сервере DirectAccess, должен иметь
данные точки распределения CRL, доступной из Интернета, а поле Subject должно
содержать публичный IPv4-адрес, назначенный серверу DirectAccess, или полное имя
FQDN, которое может быть разрешено в публичный IPv4-адрес с помощью
общедоступных DNS-серверов.
Сертификат SSL для IP-HTTPS, установленный на сервере нахождения в сети, должен
иметь данные точки распределения CRL, доступной из интрасети, а поле Subject
должно содержать внутренний IPv4-адрес, назначенный серверу нахождения в сети,
или полное имя FQDN, которое может быть разрешено во внутренний IPv4-адрес с
помощью внутренних DNS-серверов.

Политики IPsec — служба DirectAccess использует политики IPsec, настроенные и
управляемые как часть оснастки Windows Firewall with Advanced Security (брандмауэр
Windows с повышенной безопасностью). Дополнительные сведения см. в руководстве
Руководство по началу работы с брандмауэром Windows в режиме повышенной
безопасности (на английском языке).

Включение трафика эхо-запросов ICMPv6 — необходимо создать отдельные
правила, разрешающие входящие и исходящие эхо-запросы ICMPv6. Необходимо
наличие входящего правила, разрешающего эхо-запросы ICMPv6 и действующего для
всех профилей. Если блокирование исходящих запросов включено, рекомендуется
наличие исходящего правила, разрешающего эхо-запросы ICMPv6 и действующего для
всех профилей. Клиенты DirectAccess, использующие Teredo для связи с ресурсам
интрасетии по протоколу IPv6, используют сообщение ICMPv6 при установке
подключения. Дополнительные сведения см. на веб-странице Обзор технологии Teredo
(на английском языке).

IPv6 и технологии перехода — для использования на сервере DirectAccess должен
быть доступен протокол IPv6 и технологии перехода ISATAP, Teredo и 6to4. На всех
DNS-серверах под управлением ОС Windows Server 2008 или более поздней версии
следует удалить имя ISATAP из глобального списка блокировки запросов.
Дополнительные сведения см. в следующих материалах на веб-сайте Майкрософт:

Обновление глобального списка блокировки запросов (на английском языке)

IPv6 (на английском языке)
Примечание
Служба DirectAccess и служба Routing and Remote Access service (RRAS),
настроенная как сервер VPN, не могут выполняться на одном компьютере.
Исключения брандмауэра
В таблице ниже приведены исключения брандмауэра для трафика входящего и
исходящего трафика сервера DirectAccess.
Имя
Teredo
6to4
IP-HTTPS
Чистый IPv6
UDP 3544
X
Н/д
Н/д
Н/д
Протокол 41
Н/д
X
Н/д
Н/д
TCP 443
Н/д
Н/д
X
Н/д
ICMPv6 (при наличии
подключения к Интернету
по протоколу IPv6)
Н/д
Н/д
Н/д
X
UDP 500 (при наличии
подключения к Интернету
по протоколу IPv6)
Н/д
Н/д
Н/д
X
Протокол 50
Н/д
Н/д
Н/д
X
Эта таблица показывает, что если вы собираетесь использовать технологию Teredo, 6to4 и
IP-HTTPS (стандартные и рекомендуемые решения для передачи данных клиентами
DirectAccess), необходимо разрешить трафик протокола UDP по порту 3544, IPv4 протокол
41 и трафик TCP по порту 443 через брандмауэр подключения к Интернету и разрешить
прохождение этого трафика до сервера DirectAccess. Если подключения клиентов будут
поддерживаться по чистому протоколу IPv6, необходимо также разрешить трафик ICMPv6
и IPv6 протокол 50 через внешний брандмауэр.
Например, исключения в интерфейсе брандмауэра подключения к Интернету будут иметь
следующий формат:
[Any] allowed inbound to [IPv4 address of Internet-facing adapter on DirectAccess server]
for [protocol or port]
[IPv4 address of Internet-facing adapter on DirectAccess server] for [protocol or port]
allowed outbound to [Any]
В таблице ниже приведены исключения брандмауэра интрасети для трафика входящего и
исходящего трафика сервера DirectAccess.
Имя
ISATAP
Чистый IPv6
IPv4 + NAT-PT
Протокол 41
X
TCP
X
X
UDP
X
X
ICMPV6
X
Все подключения IPv6
X
UDP 500 IKE/AuthIP
X
X
Таблица показывает, что при наличии брандмауэра между сервером DirectAccess и
остальной частью интрасети порты и протоколы, которые необходимо открыть, зависят от
типа используемого клиентами DirectAccess подключения к ресурсам интрасети. Эти
исключения добавляются помимо разрешения входящего и исходящего трафика IPv4 и
IPv6 сервера DirectAccess и предназначены для связи с контроллерами домена Active
Directory, серверами управления, центрами сертификации и другими ресурсам интрасетии.
Дополнительные параметры
развертывания и вопросы для
рассмотрения
Темы, рассмотренные в этом разделе, являются введением и примером применения новых
технологических концепций. В процессе ознакомления с разделом не выполняйте
описанные здесь шаги. Фактическая реализация будет показана в процессе установки,
описанном в приложении.
Принудительное туннелирование
По умолчанию удаленные клиенты DirectAccess одновременно имеют доступ в Интернет,
интрасеть и к своей локальной подсети. Клиенты DirectAccess настроены для отправки
всех запросов внутренних имен на внутренние DNS-серверы, а запросы с
неопределенными именами или именами-исключениями перенаправляются на DNSсерверы поставщика услуг Интернета. Этот режим работы службы DirectAccess
используется по умолчанию.
Чтобы принудительно пропускать весь Интернет-трафик и трафик интрасети через
подключение DirectAccess, можно использовать функцию принудительного туннелирования.
Эта функция включается следующим параметром групповой политики в объекте групповой
политики для клиентов DirectAccess:
Computer Configuration\Administrative Templates\Network\Network Connections\Route
all traffic through the internal network
При включении принудительного туннелирования весь трафик от клиента DirectAccess
должен являться трафиком IPv6 и перенаправляться в интрасеть по туннелю IP-HTTPS.
Клиенты с принудительным туннелированием по-прежнему имеют доступ к локальной
подсети, например к сетевым принтерам, однако любой трафик за ее пределы должен
являться трафиком IPv6. Для доступа к Интернет-ресурсам IPv4 при принудительном
туннелировании используется прокси-сервер Интернета с поддержкой IPv6. В качестве
альтернативы можно использовать устройство NAT-PT и перенаправлять интернет-трафик
IPv4 на прокси-серверы Интернета с поддержкой IPv4.
Примечание
Вследствие инфраструктурных требований и снижения производительности при
доступе к интернет-ресурсам IPv4 корпорация Майкрософт не рекомендует
использовать принудительное туннелирование для службы DirectAccess.
Удаленное управление клиентами DirectAccess
Благодаря службе DirectAccess ИТ-специалисты могут удаленно администрировать
компьютеры-клиенты DirectAccess. Администрирование может включать распространение
обновлений, получение отчетов об оборудовании и установленном ПО, установку
обновлений приложений или даже помощь пользователям с использованием сеансов
удаленного рабочего стола. Поскольку клиенты DirectAccess используют для передачи
данных только IPv6, для подключения к клиенту DirectAccess все приложения и средства
администрирования должны поддерживать работу по протоколу IPv6.
Кроме того, при использовании приложения, подключающегося к клиенту DirectAccess с
использованием технологии Teredo для отправки трафика IPv6 поверх IPv4-Интернета, на
клиентском компьютере для этого приложения требуется правило брандмауэра с
установленным флажком Edge Traversal (обход узлов). Этот флажок можно установить
следующими способами:

Откройте оснастку брандмауэра ОС Windows в режиме повышенной безопасности (в
объекте групповой политики). Откройте свойства входящего правила, перейдите на
вкладку Advanced (дополнительно) и установите флажок Allow edge traversal
(разрешить обход узлов) в области Edge traversal (обход узлов).

Используйте параметр edge=yes для команды netsh advfirewall firewall при
добавлении или изменении входящего правила.
Для компьютера, к которому необходимо иметь доступ посредством Teredo, убедитесь в
наличии правила, разрешающего входящие эхо-запросы ICMPv6 с включенным
параметром обхода узлов. Для этого правила используется следующая команда Netsh.exe:
netsh advfirewall firewall add rule name="Входящий запрос ICMPv6 с обходом узлов"
protocol=icmpv6:128,any dir=in action=allow edge=yes profile=public,private
Ниже приведен пример включения правила удаленного рабочего стола с обходом узлов
посредством команды Netsh.exe:
netsh advfirewall firewall add rule name=”уд. рабочий стол” profile=public,private dir=in
program=system action=allow protocol=tcp localport=3389 edge=yes remoteip=<корпоративный
диапазон адресов v6>
Для проверки подлинности и шифрования сеансов удаленного рабочего стола используйте
следующее правило с защитным словом
netsh advfirewall firewall add rule name=”удаленный раб. стол” profile=public,private
dir=in program=system action=allow protocol=tcp localport=3389 security=authenc edge=yes
remoteip=<корпоративный диапазон адресов v6>
Для использования этой настройки необходимо убедиться, что имеется политика
транспортного режима IPsec, защищающая соединение сервера управления и клиента.
Примечание
Если компьютер, управляющий клиентом DirectAccess из интрасети, работает под
управлением ОС Windows Vista или Windows Server 2008 и требуется использовать
транспортный режим IPsec, оба компьютера должны иметь одинаковое время
жизни быстрого режима.
Публично доступные имена
Если в политиках DirectAccess вместо IP-адресов используются имена серверов, имена
сервера Teredo, ретранслятора 6to4 и сервера IP-HTTPS должны быть разрешаемыми в
публичном пространстве имен Интернета. Эти серверные службы могут физически
размещаться на одном сервере; в таком случае доступным должно быть только одно имя.
Если имена этих серверов не являются разрешаемыми снаружи, пользователи
DirectAccess не смогут подключиться через Интернет.
В качестве альтернативы политики DirectAccess можно настроить с использованием IPадресов серверов Teredo, ретранслятора 6to4 и сервера IP-HTTPS; в таком случае не
обязательно обеспечивать публичную разрешимость имен серверов.
Примечание
По умолчанию мастер DirectAccess Setup Wizard (мастер настройки DirectAccess)
настраивает ретранслятор 6to4 и сервер Teredo с использованием IPv4-адресов, а
сервер IP-HTTPS — с полным именем FQDN.
Связь между клиентами DirectAccess
В зависимости от используемых приложений клиенты DirectAccess могут непосредственно
связываться друг с другом даже за пределами интрасети. Приложения для такого
непосредственного взаимодействия обычно называют одноранговыми, или пиринговыми
(Peer-to-Peer, P2P).
Многие приложения P2P, такие Groove или Office Communicator, снабжены собственными
средствами безопасности. В некоторых приложениях собственные средства защиты
отсутствуют. К ним относятся «Удаленный помощник», «Удаленный рабочий стол» и
«Служба доступа к файлам и принтерам». Благодаря средствам протокола IPsec служба
DirectAccess обеспечивает безопасную связь этих приложений, даже если в них
отсутствуют собственные механизмы обеспечения безопасности.
Действия по защите нужных приложений:

Создайте правило транспортного режима IPsec и связанные правила брандмауэра для
всех приложений, которые необходимо защитить, используя следующие параметры
общей политики: Transport mode, RequestinRequestout, Non-Corp v6 <=> Non-Corp v6 ,
Auth = Computer certificate, Profile=public, private.

Создайте для всех приложений правила брандмауэра Windows. Например, для
удаленного рабочего стола правило брандмауэра Windows выглядит следующим
образом: Profile= Public, Private; Program = c:\windows\system32\mstsc.exe; Allow if secure
+ encryption; Inbound; TCP 3389.
Для настройки правила IPsec с помощью команды Netsh.exe используйте следующий
формат:
netsh advfirewall consec add rule endpoint1=<Non-Corp v6> endpoint2=<Non-Corp v6>
action=requestinrequestout profile=public,private auth1=computercert auth1ca=<CA Name>
Для настройки правила брандмауэра Windows с помощью команды Netsh.exe используйте
следующий формат:
netsh advfirewall firewall add rule name=”уд. рабочий стол” profile=public,private
program=system action=allow security=authenc protocol=tcp localport=3389
Кроме того, можно настроить дополнительные параметры безопасности,
предотвращающие связь между клиентами DirectAccess, если не обеспечена безопасность
соединения. Это делается путем изменения действия в правиле безопасности
подключения action=requireinrequestout, в результате чего узел обрывает все соединения с
узлами IPv6, для которых не используется шифрование.
Исходящие подключения к другим клиентам DirectAccess защищаются независимо от
приложения. Исходящие соединения с интернет-ресурсами и клиентами без службы
DirectAccess будут успешно работать без защиты соединения.
Обработка большого объема запросов
проверки подлинности
Для увеличения числа одновременно обрабатываемых запросов проверки подлинности
между сервером DirectAccess и контролером домена задайте для параметра реестра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\ MaxConc
urrentApi (REG_DWORD) значение 5 и перезапустите службу NETLOGON.
Использование смарт-карт со службой
DirectAccess
Если не указаны серверы управления, в стандартной конфигурации DirectAccess имеется
два правила туннельного режима IPsec, настроенные мастером DirectAccess Setup Wizard
(мастер настройки DirectAccess):

первый туннель от клиента DirectAccess до сервера DirectAccess для доступа к IPv6адресам DNS-серверов и контроллерам доменов AD DS.
Этот туннель использует учетные данные сертификата компьютера для первой
проверки подлинности и учетные данные пользователя (NTLMv2) для второй проверки
подлинности. Учетные данные пользователя (NTLMv2) служат для принудительного
использования AuthIP, а также потому, что клиентам DirectAccess нужен доступ к DNS и
контроллерам домена до того, как они смогут использовать учетные данные Kerberos
для второго туннеля.

Второй туннель — от клиента до сервера DirectAccess для доступа к адресному
пространству IPv6 интрасети.
Этот туннель использует учетные данные сертификата компьютера для первой
проверки подлинности и учетные данные пользователя (Kerberos V5) для второй
проверки подлинности.
Кроме того, настройки туннельного режима IPsec могут использоваться для того, чтобы
сервер DirectAccess требовал обязательной авторизации с применением смарт-карты для
удаленных пользователей. Эта авторизация туннеля IPsec может быть специально
использована для обязательного применения смарт-карт при удаленном подключении
DirectAccess. Авторизация IPsec — это дополнительная настройка туннелей IPsec,
требующая авторизации определенных групп пользователей или компьютеров путем
принудительного использования идентификатора безопасности на базе Kerberos,
создаваемого при входе пользователя со смарт-картой.
Авторизацию IPsec, требующую использования смарт-карты, следует настраивать только
для туннеля, используемого для доступа к интрасети (второй туннель, описанный выше),
ее не нужно использовать для туннеля, используемого для доступа к DNS, контроллерам
домена и серверам управления. Клиентам DirectAccess требуется доступ к базовой
инфраструктуре подтверждения учетных данных, включая учетные данные смарт-карты.
Эти учетные данные затем используются для предоставления доступа к остальным
ресурсам интрасети через второй туннель IPsec.
Для использования смарт-карт при авторизации в туннельном режиме IPsec необходимо
наличие инфраструктуры открытых ключей PKI и клиентской инфраструктуры смарт-карт.
Дополнительные сведения о развертывании инфраструктуры смарт-карт см. в следующих
источниках:

Инфраструктура открытых ключей для ОС Windows Server 2003 (на английском языке);

Развертывание смарт-карт (на английском языке);

Управление смарт-картами (на английском языке).
После развертывания инфраструктуры PKI и смарт-карт добавляются общие настройки
авторизации туннельного режима IPsec для объекта групповой политики сервера
DirectAccess, указывая идентификатор авторизации для входов с использованием смарткарт.
Принудительное использование смарт-карт при авторизации IPsec работает следующим
образом: IPsec можно настроить для поиска определенных идентификаторов безопасности
SID на базе Kerberos в клиентском маркере Kerberos.
IPsec настроен для принудительного использования проверки подлинности пользователя
на базе Kerberos и для поиска определенных проверенных пользователей. При
применении смарт-карт авторизованный пользователь представляется в виде
идентификатора SID (S-1-5-65-1), связанного с входами смарт-карты. Этот идентификатор
SID при настройке общих параметров авторизации туннельного режима называется This
Organization Certificate (сертификат этой организации).
При применении авторизации со смарт-картами на периметре с использованием политики
авторизации IPsec попытка входа пользователя без смарт-карты приводит к появлению
уведомления в области уведомлений. Ниже показан пример уведомления:
Пользователи щелкают это сообщение и предоставляют свою смарт-карту и код PIN для
получения доступа к ресурсам интрасети.
Можно заставить клиентов DirectAccess предоставлять учетные данные смарт-карты до
получения доступа к ресурсам интрасети путем установки флажка Require smart card
login for users (требовать входа по смарт-карте для пользователей) в окне странице
Connectivity (подключения) шага 2 мастера DirectAccess Setup Wizard (мастер настройки
DirectAccess). Ниже показан пример:
На изображении ниже показан пример общей настройки авторизации туннельного режима
IPsec при установке флажка Require smart card login for users (требовать входа по смарткарте для пользователей) в мастере DirectAccess Setup Wizard (мастер настройки
DirectAccess).
Для просмотра этого окна в оснасткеWindows Firewall with Advanced Security (Брандмауэр
Windows с повышенной безопасностью) выполните следующие действия:
1. Щелкните правой кнопкой мыши пункт Windows Firewall with Advanced Security
(брандмауэр Windows с повышенной безопасностью) и выберите пункт Properties
(свойства).
2. На вкладке IP Setting (параметры IP) в разделе IPsec tunnel authorization
(Авторизация туннеля IPsec) нажмите кнопку Customize (настроить).
3. Перейдите на вкладку Users (пользователи).
Для аналогичной настройки мастера настройки DirectAccess с помощью средства Netsh.exe
используйте следующие команды:
netsh advfirewall consec add rule name=”Туннель смарт-карты” endpoint1=Intranet IPv6
address space endpoint2=Any localtunnelendpoint=DirectAccess server IPv6 address 2
remotetunnelendpoint=any auth1=Computercert auth1ca=”Certificate Auth name
certmapping:yes” auth2=userkerb applyauthz=yes
netsh advfirewall set global ipsec authzusergrp=O:LSD:(A;;CC;;;S-1-5-65-1)
Блокирование клиентов DirectAccess
При необходимости заблокировать клиента DirectAccess и предотвратить его доступ к
ресурсам DirectAccess можно отключить учетную запись компьютера в каталоге Active
Directory. Это рекомендуемый способ блокировки.
Кроме того, можно включить строгую проверку цепочки сертификатов CRL для IPsec и
затем отозвать сертификат клиента DirectAccess, сделав невозможным проверку
подлинности на сервере DirectAccess. Строгая проверка цепочки сертификатов CRL не
включена по умолчанию, т.е. при отзыве сертификата компьютера-клиента DirectAccess он
по-прежнему имеет доступ к серверу DirectAccess.
Для включения строгой проверки CRL для проверки подлинности IPsec выполните
следующие действия:
1. На контроллере домена выполните следующие команды:
netsh adv set store gpo=[domain name]\[GUID for the DirectAccess server GPO]
netsh adv set global ipsec strongcrlcheck 2
2. На сервере используйте команду gpupdate /target:computer для обновления настроек
групповой политики конфигурации компьютеров.
Примечания

При включении строгой проверки CRL, если сервер DirectAccess не может
подключиться к точке распределения CRL, проверка подлинности IPsec для всех
клиентов DirectAccess закончится неудачей.

При использовании NAP и сертификатов работоспособности и включении строгой
проверки CRL проверка подлинности IPsec для всех клиентов DirectAccess
закончится неудачей. Сертификаты работоспособности не имеют цепочек
сертификатов CRL, поскольку их время жизни обычно составляет часы в отличие от
обычных сертификатов, действующих годами.
Обеспечение безопасности Internet Explorer
Выберите для параметра групповой политики Computer
Configuration\Policies\Administrative Templates\Windows Components\Internet
Explorer\Internet Control Panel\Security Page\Turn on automatic detection of the intranet
(Конфигурация компьютера\Политики\Административные шаблоны\Компоненты
Windows\Internet Explorer\Панель управления обозревателем\Страница
Безопасность\Включить автоматическое определение интрасети) значение Disabled
(выключено). Это отключает возможность утечки учетных данных NTLM в Internet Explorer®
при использовании однословных имен. Этот параметр без запроса можно задать в объекте
групповой политики, чтобы полностью запретить использование NTLM в зонах Internet
(Интернет) и Local Intranet Zone (локальная интрасеть). Добавьте сайты интрасети в зону
Trusted Sites (надежные узлы).
Включите этот параметр, чтобы предотвратить проникновение в зону Local Intranet Zone
(местная интрасеть) из зоны Internet (Интернет).
Проектирование решения на базе службы
DirectAccess
DirectAccess является очень гибким решением, которое можно развернуть разными
способами, соответствующими вашим потребностям. Многие решения следует принять
заранее, чтобы обеспечить соответствие решения на базе DirectAccess требованиям
вашей ИТ-среды. В этом разделе шаги проектирования разбиты на небольшие этапы,
которые помогут оценить систему в целом и принять взвешенное решение.
С чего начать?
Ниже представлены три основных шага проектирования развертывания службы
DirectAccess.
1. Выбор модели доступа.
2. Выбор модели масштабируемости.
3. Выбор способа развертывания.
Решение на каждом шаге повлияет на развертывание службы DirectAccess, типы сетевого
трафика и устранение неполадок с подключениями. Перед выполнением каждого шага
убедитесь, что вы представляете себе архитектуру в целом.
В следующих разделах описаны основные высокоуровневые вопросы, которые могут
повлиять на ваши решения.
Факторы, учитываемые при проектировании
решения
Протоколы IPv6 и IPsec являются ключевыми факторами, влияющими на все этапы
проектирования решения. Для планирования эффективного развертывания решения на
базе DirectAccess необходимо полностью понимать влияние этих технологий на
архитектуру.

IPv6 — независимо от выбранного проекта, доступными клиентам DirectAccess будут
только серверы и ресурсы (такие как принтеры, папки общего доступа и базы данных),
использующие протокол IPv6. Единственным способом обойти требование наличия
протокола IPv6 является использование устройства NAT-PT.

IPsec — протокол IPsec обеспечивает гибко настраиваемую среду для реализации
различных сценариев безопасного доступа, которые соответствуют практически любым
требованиям.
В следующем разделе приведены сведения о выборе модели доступа. Место прерывания
шифрования IPsec — на границе сети или на конечном сервере — а также выбранный
уровень проверки подлинности сыграют существенную роль при выборе модели доступа.
Примечание
ОС Windows Server 2003 и более ранние версии ОС Windows Server неполностью
поддерживают использование протокола IPsec с IPv6. ОС Windows Server 2008
поддерживает использование подключений IPsec по протоколу IPv6. Ресурсы с
адресами IPv6 на серверах под управлением ОС Windows Server 2003 будут
доступны клиентам DirectAccess только при выборе модели доступа «от узла до
периметра». Ресурсы с адресами IPv4 на серверах под управлением ОС Windows
Server 2003, включая большинство встроенных приложений и системных служб,
будут доступны клиентам DirectAccess только при использовании устройства NATPT.
Выбор модели доступа
Доступно три следующие модели доступа.

Полный доступ к интрасети (от узла до периметра)

Доступ к отдельным серверам (модифицированная модель «от узла до периметра»)

От узла до узла
Полный доступ к интрасети (от узла до периметра)
Модель «Полный доступ к интрасети» позволяет клиентам DirectAccess подключаться к
любым ресурсам интрасети. Этот доступ обеспечивается с использованием политик
туннельного режима IPsec, требующих проверки подлинности и шифрования; сессии IPsec
прерываются на шлюзе IPsec Gateway. Шлюз IPsec Gateway — это функция, по умолчанию
размещаемая на сервере DirectAccess, которую, однако, можно перенести на отдельный
сервер.
Эта модель доступа работает с серверами приложений под управлением ОС Windows
Server 2003; трафик, защищенный протоколом IPsec, используется за пределами
интрасети. Из-за схожести с существующей архитектурой виртуальных частных сетей VPN
развертывание архитектуры с такой моделью может оказаться проще и занять
минимальное время.
Доступ к отдельным серверам (модифицированная модель
«от узла до периметра»)
Эта модель очень блика к модели «Полный доступ к интрасети», описанной выше, с одним
важным дополнением. Передача данным между клиентом DirectAccess и шлюзом IPsec
Gateway также защищена шифрованием, настроенным в параметрах политики туннельного
режима IPsec, однако в этой модели добавляется еще один механизм проверки
подлинности.
Путем создания дополнительного правила IPsec, требующего шифрования ESP+NULL от
клиента до сервера приложений, подключение клиента будет шифроваться до шлюза IPsec
Gateway, однако проверка подлинности будет выполняться на всем пути до сервера
приложений. Это обеспечивает для клиентов DirectAccess высокий уровень уверенности в
том, что они взаимодействуют с подлинными серверами.
Кроме того, это модель упрощает создание ограничивающих политик, предотвращающих
доступ некоторых приложений или пользователей на клиентских компьютерах DirectAccess
к отдельным серверам.
На схеме ниже показана модель доступа к отдельным серверам.
Только проверка подлинности (нулевая инкапсуляция) — это политика, доступная только в
ОС Windows Server 2008 R2. Хотя она обеспечивает проверку подлинности IPsec при
обмене первыми пакетами, она не содержит средств проверки целостности и безопасности
каждого пакета, поскольку после начального согласования IKE последующие пакеты
отправляются без защиты IPsec, т. е. после сеанса согласования IKE трафик передается
без изменений. Это решение можно использовать в сетях с оборудованием, неспособным
обрабатывать или пересылать трафик, защищенный по протоколу IPsec.
Модель «от узла до узла»
Модель доступа расширяет действие этих политик IPsec на все пространство до сервера
приложений. В этом случае клиенты DirectAccess используют политику транспортного
режима IPsec, требующую использования шифрования и проверки подлинности,
прерывающихся на сервере приложений. Сервер DirectAccess или шлюз IPsec Gateway
выступают в качестве промежуточных устройств, просто пропуская трафик IPsec на
серверы приложений.
Компонент сервера DirectAccess, называемый системой защиты от атак, провоцирующих
отказ сервера (IPsec Denial of Service Protection, DoSP), выполняет мониторинг трафика
IPsec для предотвращения DoS-атак ресурсов интрасети из Интернета.
На схеме ниже показана модель доступа «от узла до узла».
Модель с одним и несколькими серверами
Службу DirectAccess можно установить с использованием одного сервера. Этот тип
установки позволяет задействовать все основные функции DirectAccess, необходимые для
ее использования. Поскольку назначением службы DirectAccess является предоставление
доступа удаленным пользователям, бесперебойность работы и масштабируемость
являются важными факторами. В этом разделе рассмотрены различные варианты
повышения надежности работы и масштабируемости службы DirectAccess.
Один сервер
При такой схеме все компоненты службы DirectAccess размещаются на одном сервере.
Ниже показан пример такой схемы:
Преимуществом такого сценария является сравнительная простота развертывания, при котором
требуется всего лишь один сервер DirectAccess.
Этот сценарий имеет и ограничения — единичная точка отказа и ограниченная
производительность сервера, определяющая максимальное число одновременных
подключений к серверу DirectAccess.
Несколько серверов для повышения бесперебойности
Службу DirectAccess можно установить на кластере Hyper-V® с передачей нагрузки при
сбое. Рекомендуемая конфигурация состоит из двух узлов Hyper-V с поддержкой передачи
нагрузки и кластеризацией одного сервера DirectAccess на виртуальной машине.
Использование двух узлов Hyper-V защитит систему от сбоя одного узла при обеспечении
работы сервера DirectAccess. При планировании конфигурации рекомендуется
ознакомиться со следующими источниками:

Пошаговое руководство по тестированию кластеров Hyper-V с переносом нагрузки при
сбое (на английском языке);

Hyper-V: пошаговое руководство по использованию динамической миграции в ОС
Windows Server 2008 R2 (на английском языке).
Помимо мастера DirectAccess Setup Wizard (мастер настройки DirectAccess) потребуется
следующая настройка.
1. Серверы Hyper-V должны иметь одинаковое аппаратное обеспечение.

Все серверы Hyper-V должны иметь по крайней мере три сетевых адаптера для
поддержки подключений Интернета, интрасети и подключения кластеризации.
Совмещение функций сетевых интерфейсов не поддерживается.
 Серверы Hyper-V объединяются в домен и подключаются к соответствующим сетям,
протоколы IPv4 и IPv6 на их сетевых адаптерах доступа в Интернет отключены.
2. Убедитесь, что на узлах Hyper-V включена поддержка предотвращения выполнения
данных и виртуализация процессоров.
3. Выполните следующие настройки Hyper-V:


Для повышения общей производительности в свойствах виртуальной машины в
диспетчере отказоустойчивости кластеров выполните следующие действия:

Не задавайте предпочитаемого владельца.

Для параметра Failback (восстановление размещения) задайте значение
Prevent Failback (запретить восстановление размещения). Если параметр
восстановления размещения включен, при миграции или восстановлении
виртуальной машины DirectAccess после сбоя узла могут происходить
ненужные простои.
Чтобы ускорить повторное подключение клиентов в случае быстрой миграции или
сбоя узла, включите флаг NLBSFlags, чтобы снизить время ожидания связывания
IPsec. В реестре Windows для параметра
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\ Oakley\NL
BSFlags задайте значение 1.
При задании для параметра реестра NLBSFlags значения 1 общее время
восстановления IPsec после сбоя составит две минуты: одна минута ожидания
окончания срока действия и одна минута на восстановление связей безопасности
IKE.
Кроме того, можно использовать шлюз Unified Access Gateway (UAG) для обеспечения
масштабируемости, бесперебойности и дополнительных средств управления при
развертывании службы DirectAccess. Дополнительные сведения см. на веб-странице
Вводные сведения о решении UAG DirectAccess (на английском языке).
Выбор способа развертывания
Для развертывания и настройки ресурсов DirectAccess можно использовать следующие
средства.

Консоль управления DirectAccess.

Установка с помощью сценариев и средства Netsh.exe.

Настройка клиентов вручную с использованием групповой политики.
Все эти методы имеют преимущества и ограничения, которые рассмотрены в следующих
разделах.
Консоль управления DirectAccess
Консоль управления DirectAccess позволяет развернуть службу DirectAccess несколькими
способами. В процессе работы мастера DirectAccess Setup Wizard (мастер настройки
DirectAccess) пользователь отвечает на несколько вопросов, помогающих определить
особенности развертывания службы DirectAccess. Перед применением сделанных
изменений можно сохранить настройки в файл XML.
Этот файл XML можно просматривать и изменять, что помогает подробно ознакомиться со
всеми заданными настройками. Для выполнения файла XML можно использовать
сценарий PowerShell® engine.ps1. Дополнительные сведения см. на веб-странице
Выполнение сценариев DirectAccess (на английском языке).
Сведения о редактировании этих сценариев см. в Приложении E — советы по
использованию сценариев далее в этом документе.
Установка с помощью сценариев и средства Netsh.exe
В случае нестандартного развертывания службы DirectAccess, при котором нужно
обеспечить соответствие специфическим требованиям, команды развертывания с
использованием сценариев и средства Netsh.exe можно создать самостоятельно. Такие
сценарии развертывания являются наиболее гибкими и позволяют создавать уникальные
решения со множеством особенностей, которые не рассматриваются в этом руководстве.
Настройка клиентов вручную с использованием групповой
политики
Групповые политики позволяют создавать, распространять и применять настройки
DirectAccess на компьютерах-клиентах, благодаря чему обеспечивается единовременное и
постоянное применение параметров DirectAccess. Групповые политики используются при
установке DirectAccess и при необходимости могут применяться и при установке с
использованием сценариев. Кроме того, можно изменять конфигурацию DirectAccess,
редактируя объекты групповой политики и их настройки.
Мониторинг службы DirectAccess
ОС Windows Server 2008 R2 содержит встроенные средства мониторинга сервера
DirectAccess и его компонентов с помощью узла мониторинга в оснастке DirectAccess. Узел
мониторинга позволяет контролировать трафик, передаваемые данные и счетчики трафика,
а также события различных компонентов сервера DirectAccess и его состояние.
Состояние сервера DirectAccess
Данные о состоянии сервера DirectAccess обновляются раз в 10 секунд путем опроса
соответствующих компонентов. Пока все компоненты имеют состояние Healthy (исправен),
сервер также имеет состояние Healthy (исправен). Если один или несколько компонентов
сообщают о состоянии Warning (предупреждение, желтый цвет), система также переходит
в состояние Warning (предупреждение). Если какой-либо из компонентов сообщает о
состоянии Error (ошибка) (показанном красным цветом), система приобретает состояние
Error (ошибка). Если получены сообщения о состояниях Warning (предупреждение) и Error
(ошибка), система имеет состояние Error (ошибка) (показано красным).
Помимо состояния отображается список ошибок и предупреждений, а также рекомендации
по их устранению. Часть общих сообщений об ошибках может информировать о высоком
уровне использования ресурсов процессора и памяти. Некоторые сообщения об ошибках
компонентов могут относиться к остановке сервера Teredo или прекращению работы
интерфейса ISATAP.
Ниже показан пример окна узла мониторинга DirectAccess:
Примечание
В ОС Windows Server 2008 R2 Release Candidate средства мониторинга
DirectAccess некорректно сообщают о невозможности получить доступ к DNSсерверу по адресу ISATAP. Включение и отключение интернет-интерфейса на
сервере DirectAccess позволяет обойти эту проблему.
Компоненты сервера DirectAccess
В разделе компонентов окна мониторинга DirectAccess показано общее состояние
следующих компонентов: Teredo Relay (ретрансляция Teredo), Teredo server (сервер
Teredo), 6to4 gateway (шлюз 6to4), ISATAP, IP-HTTPS, Network Security (сетевая
безопасность) и DNS-серверы. Для всех компонентов (за исключением DNS-сервера)
имеется кнопка Details (подробно), запускающая оснастку Performance Monitor (монитор
производительности) с заранее настроенными счетчиками для выбранного компонента.
Для компонентов Teredo Relay (ретрансляция Teredo), Teredo Server (сервер Teredo),
ISATAP и 6to4 (шлюз 6to4) состояние Healthy (исправен) (зеленый цвет) отображается в
том случае, если присутствует передача данных на любом виртуальном интерфейсе в
течение 10 секунд. Для компонентов IP-HTTPS и Network Security (сетевая безопасность)
состояние Healthy (исправен) (зеленый цвет) отображается в том случае, если в течение
последнего интервала времени имеется один или несколько активных сеансов или
туннелей. Если происходит сбой или атака на компонент, его состояние отображается
красным цветом. При отсутствии трафика (активных сеансов) состояние отображается
желтым цветом.
Пакет управления
Для продукта Microsoft System Center Operations Manager 2007 (Operations Manager 2007) с
пакетом обновления SP1 доступен пакет управления, обеспечивающий мониторинг,
уведомления и средства создания отчетов. После настройки мониторинга нужного сервера
DirectAccess задайте в реестре на этом сервере следующее значение:
HKEY_LOCAL_MACHINE\Software\Microsoft\DAServer\Management=1
Если необходимо осуществлять управление несколькими серверами, выполните это
действие на каждом из серверов DirectAccess.
Отображение сервера DirectAccess в серверной консоли
Operations Manager 2007
В главной серверной консоли Operations Manager 2007 сервер DirectAccess будет
отображаться в виде корневого элемента, а его компоненты — в виде дочерних элементов.
При развертывании на нескольких компьютерах, когда компоненты распределены по
различным серверам, каждый компьютер отображается в виде сервера DirectAccess, а
используемые на нем компоненты — в виде его дочерних элементов.
Уведомления сервера DirectAccess
При использовании пакета управления доступны следующие уведомления:
Сбои
Уведомление
Условие
Серьезность события
DirectAccess Server down
(сбой сервера DirectAccess)
Сбой сервера DirectAccess
определяется при сбое
любого из компонентов,
включенных на этом
сервере. Это накопительное
предупреждение.
Красный - ошибка
(значительное
предупреждение)
Teredo Server down (сбой
сервера Teredo)
Сбой службы IPHlpSvc.
Сигнал также создается в
этом случае. Событие SCM
7031 будет использовано
для создания сигнала, а
событие SCM 7036 — для
его отмены.
Красный - ошибка
(значительное
предупреждение)
Teredo Server down (сбой
ретрансляции Teredo)
Сбой службы IPHlpSvc.
Сигнал также создается в
этом случае. Событие SCM
7031 будет использовано
для создания сигнала, а
событие SCM 7036 — для
его отмены.
Красный - ошибка
(значительное
предупреждение)
6to4 Router down (сбой
маршрутизатора 6to4)
Сбой службы IPHlpSvc.
Сигнал также создается в
этом случае. Событие SCM
7031 будет использовано
для создания сигнала, а
событие SCM 7036 — для
его отмены.
Красный - ошибка
(значительное
предупреждение)
ISATAP Router down (сбой
маршрутизатора ISATAP)
Сбой службы IPHlpSvc.
Сигнал также создается в
этом случае. Событие SCM
7031 будет использовано
для создания сигнала, а
событие SCM 7036 — для
его отмены.
Красный - ошибка
(значительное
предупреждение)
IP-HTTPS Server down (сбой
сервера IP-HTTPS)
Сбой службы IPHlpSvc.
Сигнал также создается в
этом случае. Событие SCM
7031 будет использовано
Красный - ошибка
(значительное
предупреждение)
Уведомление
Условие
Серьезность события
для создания сигнала, а
событие SCM 7036 — для
его отмены.
Network Security down (сбой
службы «Сетевая
безопасность»)
Сбой службы BFE или
IKEEXT. Сигнал также
создается в этом случае.
Событие SCM 7031 будет
использовано для создания
сигнала, а событие SCM
7036 — для его отмены.
Красный - ошибка
(значительное
предупреждение)
Уведомление
Условие
Серьезность события
Network Security component
under potential DoS attack
(возможна DoS-атака
компонента «Сетевая
безопасность»)
Сигнал для компонента
Network Security (сетевая
безопасность)
Для обоих условий: Желтый
- предупреждение
(незначительное
предупреждение)
Безопасность
Поддерживаются два
условия:

Проверка наличия
событий IKE DoSprevention mode started
(запущен IKE-режим
предотвращения атак
типа «отказ в
обслуживании») и IKE
DoS-prevention mode
stopped (остановлен
IKE-режим
предотвращения атак
типа «отказ в
обслуживании») (код
события 4646)
Источник события: аудит
безопасности Microsoft
Windows.
Канал журнала событий:
Уведомление
Условие
Серьезность события
безопасность

TCP SYN Attack (атака TCP
SYN)
Проверка превышения
заданного порога
значением счетчика
Inbound Rate Limit
Discarded IPv6 IPsec
Unauthenticated
Packets/sec (входящих
пакетов IPv6 IPsec без
проверки подлинности,
отброшенных по
пределу скорости/сек).
Пороговое значение по
умолчанию: 100; число
проверяемых примеров:
3. Проверка
выполняется каждую
минуту. Имя объекта
для этого счетчика в
оснастке Performance
Monitor (монитор
производительности):
IPSec DOS Protection
(защита IPsec от атак
типа «отказ в
обслуживании»).
Сигнал для компонента
Network Security (сетевая
безопасность)
Проверка на наличие
событий
TCP_SYN_ATTACK_ENTRY
(код: 1055) и
TCP_SYN_ATTACK_EXIT
(код: 1063).
Источник события: TCPIP
Канал журнала событий:
Microsoft-WindowsTCPIP/Diagnostic
Желтый - предупреждение
(незначительное
предупреждение)
Уведомление
Условие
Серьезность события
(диагностика)
Производительность
Уведомление
Условие
Серьезность события
IPsec state utilization reaches
warning and critical levels
(использование ресурсов
IPsec достигло критического
уровня)
Сигнал для компонента
Network Security (сетевая
безопасность).
Для состояния
предупреждения: Желтый предупреждение
(незначительное
предупреждение)
Проверка превышения
счетчиком Current State
Entries (текущие записи о
состоянии) заданных
предупреждающих и
критических значений. По
умолчанию уровень
предупреждения: 1000;
число проверяемых
примеров: 5. По умолчанию
критический уровень: 2000;
число проверяемых
примеров: 5. Проверка
выполняется каждые 5
минут. Имя объекта для
этого счетчика в оснастке
Performance Monitor
(монитор
производительности): IPSec
DOS Protection (защита
IPsec от атак типа «отказ в
обслуживании»).
CPU utilization reaches
warning levels
(использование ресурсов
ЦП достигло критического
уровня)
Это общий сигнал сервера.
CPU utilization reaches
warning levels
Это общий сигнал сервера.
Для критического состояния:
Красный - ошибка
(значительное
предупреждение)
Уведомление
Условие
Серьезность события
Network Security ICMP
Queue overflow — warning
(переполнение очереди
Network Security ICMP предупреждение)
Сигнал для компонента
Network Security (сетевая
безопасность).
Желтый - предупреждение
(незначительное
предупреждение)
Network Security Data traffic
queue overflow warning
(переполнение очереди
данных сетевой
безопасности предупреждение)
Сигнал для компонента
Network Security (сетевая
безопасность).
(использование памяти
достигло уровня
предупреждения)
Проверка превышения
заданного порога значением
счетчика Inbound Rate Limit
Discarded ICMPv6
Packets/sec (входящих
пакетов IPv6 IPsec,
отброшенных по пределу
скорости/сек). По
умолчанию пороговый
уровень: 20; число
проверяемых примеров: 5.
Проверка выполняется
каждые 3 минуты. Имя
объекта для этого счетчика
в оснастке Performance
Monitor (монитор
производительности): IPSec
DOS Protection (защита
IPsec от атак типа «отказ в
обслуживании»).
Проверка превышения
заданного порога значением
счетчика Inbound Rate Limit
Discarded IPv6 IPsec
Authenticated Packets/sec
(входящих пакетов IPv6
IPsec с проверкой
подлинности, отброшенных
по пределу скорости/сек).
По умолчанию пороговый
Желтый - предупреждение
(незначительное
предупреждение)
Уведомление
Условие
Серьезность события
уровень: 100; число
проверяемых примеров: 5.
Проверка выполняется
каждые 3 минуты. Имя
объекта для этого счетчика
в оснастке Performance
Monitor (монитор
производительности): IPSec
DOS Protection (защита
IPsec от атак типа «отказ в
обслуживании»).
Сводный показатель состояния исправности
Уведомление
Условие
Серьезность события
Состояние исправности
сервера DirectAccess
формируется на основании
исправности его
компонентов
При наличии
предупреждения для любого
компонента формируется
предупреждение для
сервера DirectAccess.
Серьезность (желтое или
красное предупреждение)
формируется на основании
максимальной серьезности
предупреждений для
компонентов сервера
Интеграция службы DirectAccess со
средствами изоляции серверов и доменов
Изоляция серверов и доменов позволяет администраторам динамически разделять сеть
Windows на более защищенные и изолированные логические сети на базе политики IPsec
без необходимости вносить дорогостоящие изменения в сетевую инфраструктуру и
конфигурацию приложений. Это позволяет создать дополнительный уровень защиты на
основе политик, обеспечить лучшую защиту от сетевых атак и предотвратить
несанкционированный доступ к доверенным сетевым ресурсам, обеспечить соответствие
законодательным требованиям и снизить эксплуатационные расходы. Решения с
использованием изоляции серверов и доменов полностью совместимы со службой
DirectAccess. Дополнительные сведения о развертывании см. на веб-странице Изоляция
серверов и доменов (на английском языке).
Ссылки
Служба Active Directory (на английском
языке)
http://go.microsoft.com/fwlink/?LinkID=147288
Кластеризация (на английском языке)
http://go.microsoft.com/fwlink/?LinkId=147169
DNS (на английском языке)
http://go.microsoft.com/fwlink/?LinkId=147013
Групповая политика (на английском языке)
http://go.microsoft.com/fwlink/?LinkId=100760
IPv6 (на английском языке)
http://go.microsoft.com/fwlink/?LinkId=17074
IPsec (на английском языке)
http://go.microsoft.com/fwlink/?LinkId=50170
NAP (на английском языке)
http://go.microsoft.com/fwlink/?LinkId=56443
PKI (на английском языке)
http://go.microsoft.com/fwlink/?LinkId=83694
Диагностика и устранение неполадок
Ошибки оснастки DirectAccess записываются в журнал <системный
диск>\windows\tracing\DirectAccess.log.
Основные шаги диагностики неполадок:
1. Есть ли у удаленного пользователя доступ к интернет-ресурсам (например к сайту
www.microsoft.com)?
2. Щелкните правой кнопкой значок сетевого подключения и выберите команду Diagnose
and repair (диагностика и восстановление).
3. Вызовите командой Ping гарантированно работающий сервер интрасети. Успешно ли
выполнены команда ping и разрешение имени?
4. В командной строке Windows выполните команду netsh name show policy. Если клиент
DirectAccess определил, что он не находится в интрасети, таблица NRPT будет
содержать записи пространства имен DirectAccess после слов DNS Name Resolution
Policy Table Settings (параметры таблицы политики разрешения имен DNS). Если после
слов «Параметры таблицы политики разрешения имен DNS» записи DirectAccess
отсутствуют, клиент DirectAccess не был настроен с использованием записей таблицы
NRPT с использованием групповой политики либо клиент определил, что он находится
в интрасети.
5. В командной строке Windows выполните команду netsh interface teredo show state.
Убедитесь, что Teredo имеет состояние Qualified (проверено) (если не используется IPHTTPS, в этом случае клиент находится за прокси-сервером).
6. Выполните процедуру поиска и устранения неполадок с сертификатом компьютера,
включая проверку наличия нужного сертификата в хранилище сертификатов
компьютера-клиента DirectAccess.
7. Для определения нахождения в интрасети клиент DirectAccess должен иметь
возможность успешно подключиться к адресу URL-HTTPS, размещенному на сервере
нахождения в сети, и проверить его сертификат. Проверка сертификата включает
проверку самого сертификата SSL и факта того, что он не аннулирован. Сертификат
сервера нахождения в сети должен иметь данные точки распределения CRL,
доступной клиенту DirectAccess и имеющей полное имя FQDN, разрешаемое DNSсерверами, указанными в настройках TCP/IP клиента (внутренние DNS-серверы).
8. Для успешного создания подключения IP-HTTPS клиент DirectAccess должен иметь
возможность соединиться с адресом URL HTTPS на сервере IP-HTTPS (обычно это
сервер DirectAccess) и проверить сертификат этого сервера. Проверка сертификата
включает проверку самого сертификата SSL и факта того, что он не аннулирован.
Сертификат сервера IP-HTTPS должен иметь данные точки распределения CRL,
доступной клиенту DirectAccess и имеющей полное имя FQDN, разрешаемое DNSсерверами, указанными в настройках TCP/IP клиента (DNS-серверы Интернета).
9. При использовании средств диагностики IP-HTTPS для устранения неполадок
подключения IP-HTTPS необходимо в правилах брандмауэра разрешить серверу IPHTTPS отвечать на сообщения типа Echo Request.
10. Для диагностики подключений и разрешения имен используйте стандартные средства
диагностики IP-подключения.
Примечание
При диагностике службы DirectAccess не используйте команду NSLOOKUP.
Команда NSLOOKUP не поддерживает таблицу NRPT и не может выдать
правильные результаты.
Ниже приведен ряд дополнительных команд, полезных при диагностике проблем:
ipconfig /all
Отображение всех данных конфигурации IPподключений.
netsh interface teredo show state
Отображение текущего состояния Teredo.
netsh adv monitor show mmsa
Отображение всех связей безопасности
основного режима.
netsh adv monitor show qmsa
Отображение всех связей безопасности
быстрого режима.
gpresult /scope computer
Отображение всех групповых политик,
применяемых к компьютеру. Результат
работы этой команды — очень длинный
список, который лучше вывести в файл,
добавив к команде параметр > file.txt.
netsh name show policy
Отображение текущего содержимого
таблицы NRPT.
Для контроля маршрута клиента DirectAccess используйте средство сетевой трассировки
ОС Windows 7 и следующую процедуру:
1. В командной строке с правами администратора запустите следующую команду для
трассировки клиента DirectAccess: netsh trace start scenario=directaccess capture=yes
report=yes.
2. Воспроизведите проблему со службой DirectAccess.
3. Остановите трассировку командой netsh trace stop.
При выполнении этой процедуры Netsh.exe записывает данные трассировки в файл
NetTrace.etl в папке %LOCALAPPDATA%\Temp\NetTraces. Для просмотра содержимого
файла откройте его в приложении Microsoft Network Monitor 3.3.
Netsh.exe также записывает дополнительные данные среды и диагностики в файл
NetTrace.cab в папке %LOCALAPPDATA%\Temp\NetTraces.
Дополнительные сведения об использовании средств Netsh.exe и Network Monitor для
записи и просмотра файлов ETL см. на веб-странице Средства диагностики проблем с
помощью трассировки в ОС Windows 7 (на английском языке).
Приложение A — обзор установки
При установке сервера DirectAccess имеется три набора компонентов:

Компоненты доступа к Интернету — протоколы, обеспечивающие мост между
Интернетом и интрасетью организации.

Компоненты доступа к интрасети — протоколы, обеспечивающие мост между
интрасетью, в которой находится клиент (или самим сервером DirectAccess) и другими
устройствами IPv6 в интрасети.

Компоненты безопасности — дополнительные компоненты обеспечения безопасности
интрасети и клиентов DirectAccess.
Начальные шаги
Начните с выполнения следующих действий.
1. Установите ОС Windows Server 2008 R2 на сервер с двумя физическими сетевыми
адаптерами.
2. Включите сервер в домен Active Directory. Сервер DirectAccess должен входить в домен
Active Directory.
3. Установите на сервер DirectAccess сертификаты компьютера, которые будут
использоваться для проверки подлинности IPsec.
4. Настройте сервер DirectAccess таким образом, чтобы он находился во внешней сети и
один из его сетевых интерфейсов имел доступ в Интернет, а другой — в интрасеть.
Убедитесь, что оба сетевых адаптера включены и их IPv4-адреса настроены (если
отсутствует поддержка протокола IPv6). Для сервера DirectAccess крайне важно
получить данные конфигурации автоматически. В противном случае потребуется
тщательная ручная настройка.
Примечание
Поддержка протокола IPv6 не является обязательным требованием для
сервера DirectAccess. При ее отсутствии поддержку IPv6 можно обеспечить
автоматически с помощью технологий перехода.
5. Убедитесь, что порты и протоколы, упомянутые в разделе Исключения брандмауэра,
открыты на внутренних и внешних брандмауэрах.
6. Для сервера DirectAccess требуется по крайней мере два последовательных
публичных статических IPv4-адреса, разрешаемых снаружи с помощью DNS. Адреса в
диапазонах 10.0.0.0/8, 172.16.0.0/12 и 192.168.0.0/16 являются частными адресами IPv4
и не могут использоваться. Убедитесь в том, что имеются свободные IPv4-адреса и что
эти адреса могут быть опубликованы на доступном снаружи DNS-сервере. da.[название
организации].com или das.[название организации].com являются примерами имен,
которые можно использовать, специальные требования для них отсутствуют.
Изменение этого адреса приведет к изменению префикса 6to4 на 2002:[IPv4адреса]::/64
7. Если в организации отключен протокол IPv6 на клиентах и серверах, включите его.
8. Создайте группу безопасности в Active Directory и добавьте в нее учетные записи
компьютеров-клиентов DirectAccess.
9. Если сервере DirectAccess является также сервером нахождения в сети, установите
роль сервера IIS на сервер DirectAccess. Дополнительные сведения см. в разделе
Определение нахождения клиента в интрасети в этом документе.
10. Выберите один из сетевых адаптеров сервера в качестве интернет-интерфейса. Для
этого интерфейса требуется два последовательных публичных IPv4-адреса. Оба
адреса IPv4 должны быть назначены одному интерфейсу.
11. На сервере DirectAccess убедитесь, что интернет-интерфейс настроен как Public
(общественный) или Private (частный) (в зависимости от конфигурации сети), а
интерфейсы интрасети настроены как Domain (домен). Другие комбинации не
поддерживаются. Если используется более двух интерфейсов убедитесь, что выбрано
не более двух типов классификации.
Подробные инструкции по установке службы DirectAccess в тестовой среде см. в документе
Пошаговое руководство: демонстрация использования DirectAccess в тестовой среде (на
английском языке).
Приложение B — инструкции по
использованию мастера DirectAccess
Setup Wizard (мастер настройки
DirectAccess)
Примечание
Перед использованием мастера DirectAccess Setup Wizard (мастер настройки
DirectAccess) убедитесь, что выполненные предварительные шаги, описанные в
приложении А.
Консоль управления DirectAccess существенно упрощает настройку службу DirectAccess
благодаря набору шагов и окон мастера установки. После завершения всех шагов
созданную конфигурацию можно сохранить как набор сценариев для последующего
использования или применить непосредственно к серверу DirectAccess.
Установка консоли управления DirectAccess
1. В области Features Summary (сводка компонентов) диспетчера сервера нажмите
кнопку Add features (добавить компоненты).
2. В окне Select Features (выбранные компоненты) выберите DirectAccess Management
Console (консоль управления DirectAccess).
3. В окне Add Features Wizard (мастер добавления компонентов) нажмите кнопку Add
Required Features (добавить необходимые компоненты).
4. В окне Select Features (выбор компонентов) нажмите кнопку Next (далее).
5. В окне Confirm Installation Selections (подтверждение выбранных элементов для
установки) нажмите кнопку Install (установить).
6. В окне Installation Results (результаты установки) нажмите кнопку Close (закрыть).
Запуск оснастки DirectAccess Server Management (управление сервером DirectAccess)
1. Нажмите кнопку Start (пуск), выберите Administrative Tools (администрирование),
а затем — DirectAccess Management (управление компьютером).
2. Раскройте узел DirectAccess в дереве консоли.
3. Нажмите кнопку Setup (настройка) для настройки сервера DirectAccess.
Конфигурацию можно сохранить в любой момент, нажав кнопку Save (сохранить) в нижней
правой части окна настройки. Конфигурация будет сохранена в
файл %windir%\DirectAccess\DirectAccessConfig.xml. При повторном запуске оснастки
конфигурация будет загружена из файла DirectAccessConfig.xml, настройка будет
продолжена с места сохранения.
По завершении настройки нажмите кнопку Finish (готово) для просмотра конфигурации
DirectAccess. Затем нажмите кнопку Apply (применить) для применения настроек
DirectAccess.
Сохраненную конфигурацию DirectAccessConfig.xml можно применить с помощью
сценариев.
Для применения изменений, сделанных в консоли управления DirectAccess, необходимо
иметь права локального администратора, разрешение создавать и редактировать объекты
групповой политики и связывать их с доменом. При отсутствии этих разрешений консоль
будет работать, однако кнопка Apply (применить) будет недоступна. В этом случае
необходимо сохранить конфигурацию, не применяя ее.
Мастер DirectAccess Setup Wizard (мастер настройки DirectAccess) поможет выполнить
необходимые шаги настройки сервера DirectAccess. Ниже показан пример окна мастера
DirectAccess Setup Wizard (мастер настройки DirectAccess).
Шаг 1 — удаленные клиенты
Первым шагом в консоли настройки является выбор групп безопасности Active Directory,
содержащих учетные записи пользователей-клиентов DirectAccess. Ниже показан пример
окна:
Выбранные группы безопасности могут располагаться в разных доменах или лесах с
учетом того, что заданы нужные правила доверия. Группы безопасности должны
существовать до запуска мастера DirectAccess Setup Wizard (мастер настройки
DirectAccess).
Шаг 2 — сервер DirectAccess
Следующим шагом является настройка сервера DirectAccess. Он включает выбор методов
подключения и сертификатов.
Возможности подключения
В этом окне указывается, какой интерфейс подключен к Интернету, а какой — к интрасети
(внутренней сети). Кроме того, можно включить авторизацию с использованием смарт-карт.
Ниже показан пример окна настройки:
Сертификаты
В этом окне выбираются два сертификата:

Корневой сертификат, с которым должны быть связаны сертификаты клиентов
DirectAccess. Он будет использоваться для проверки сертификатов, отправленных
клиентами DirectAccess при проверке подлинности IPSec.

Сертификат для подключений поверх HTTPS (IP-HTTPS). Этот сертификат должен
содержать в поле Subject публичный IPv4-адрес сервера DirectAccess или полное имя
FQDN, разрешаемое в публичный IPv4-адрес с помощью DNS-серверов Интернета.
Кроме того, убедитесь, что в нем настроена точка распределения CRL, доступная из
Интернета. Этот сертификат можно использовать и для сервера размещения в сети.
Ниже показан пример окна настройки:
Шаг 3 — серверы инфраструктуры
В этом шаге настраиваются серверы инфраструктуры: DNS-серверы, контроллеры домена
и серверы управления.
Размещение
В окне Location (размещение) введите адрес HTTPS-URL, который будет использоваться
клиентами для определения, находятся ли они в интрасети. Здесь можно указать, что
сервер DirectAccess является также сервером нахождения в сети. Тем не менее,
настоятельно рекомендуется использовать для этого отдельный сервер с высокой
отказоустойчивостью.
Если указывается, что серверы DirectAccess и нахождения в сети совмещены, необходимо
выбрать сертификат, который будет использоваться для определения нахождения в сети.
Этот сертификат должен содержать в поле Subject внутренний IPv4-адрес сервера
DirectAccess или полное имя FQDN, разрешаемое во внутренний IPv4-адрес. Полное имя
FQDN не должно быть разрешаемым внешними DNS-серверами Интернета; внутренний
IPv4-адрес не должен быть доступен из Интернета. Кроме того, этот сертификат должен
иметь данные точки распределения CRL, доступной клиентам DirectAccess с
использованием внутренних DNS-серверов, указанных в настройках TCP/IP клиента.
Этот сертификат не должен совпадать с сертификатом, используемым для подключений
IP-HTTPS и выбранным в шаге 2 мастера DirectAccess Setup Wizard (мастер настройки
DirectAccess).
Ниже показан пример окна настройки:
DNS-сервер и контроллер домена
В этом шаге настраивается таблица NRPT, которую удаленные клиенты будут
использовать для выбора запросов DNS, направляемых на внутренние DNS-серверы.
Мастер также добавляет в таблицу суффикс DNS и адреса IPv6 или ISATAP DNS-сервера,
а также, в зависимости от сервера нахождения в сети, запись исключения для этого
сервера.
Эти записи можно изменить, дважды щелкнув их или щелкнув правой кнопкой и выбрав
команду Edit (изменить). Для добавления новых записей щелкните правой кнопкой пустую
строку и выберите команду New (создать). В качестве альтернативы можно просто
щелкнуть пустую строку. Для удаления записи из таблицы NRPT щелкните ее правой
кнопкой и выберите команду Delete (удалить).
Управление
Это окно предназначено для настройки серверов управления, которые будут
использоваться для управления клиентами DirectAccess. Это необязательный шаг
настройки.
Шаг 4 — серверы приложений
Последний шаг — указание серверов приложений, для которых будет использоваться
протокол IPsec. Эта возможность позволяет использовать изоляцию серверов и доменов
при развертывании службы DirectAccess.
При необходимости на этой странице настраивается дополнительный уровень проверки
подлинности для критически важных серверов. По умолчанию дополнительная проверка
подлинности модели «от узла до узла» не используется.
Приложение C — инструкции по установке
одиночного сервера DirectAccess с
использованием сценариев
Перед началом установки убедитесь, что выполненные предварительные шаги, описанные
в приложении А. Все приведенные ниже команды выполняются на сервере DirectAccess.
Для определения индексов интерфейса введите в командной строке следующую команду:
netsh interface ipv6 show interface
Запишите индекс интерфейса сетевого адаптера, который необходимо настроить. Во всех
инструкциях по настройке строка <индекс интерфейса#> соответствует этому индексу
интерфейса.
Настройка компонентов доступа к Интернету
Компонент
Назначение
Команда в командной строке
Windows
Сервер Teredo
Настройка Teredo с
указанием имени или IPадреса сервера Teredo
netsh interface ipv6 set teredo
server <ipv4-адрес сервера
teredo>
Сетевой интерфейс
Настройка интерфейсов
сервера DirectAccess
1. Запустите для
интерфейсов 6to4 и
Teredo следующую
команду:
netsh interface ipv6 set
interface <индекс
интерфейса #>
forwarding=enabled
2. Если имеется
интерфейс IPv6,
запустите следующую
команду:
netsh interface ipv6 set
interface <индекс
интерфейса #>
Компонент
Назначение
Команда в командной строке
Windows
forwarding=enabled
3. Для интерфейса IPHTTPS запустите
следующую команду:
netsh interface ipv6 set
interface
IPHTTPSInterface
forwarding=enabled
advertising=enabled
6to4
Включение протокола 6to4
netsh interface 6to4 set state
enabled
Сертификаты
Установка сертификатов
1. Установите
сертификаты
2. Запустите команду netsh
http add sslcert <args>
Интерфейс IP-HTTPS
Настройка интерфейса IPHTTPS
netsh interface httpstunnel
add interface server https://
[публичный IPv4-адрес или
FQDN]:443/IPHTTPS enabled
{certificates}
Маршрутизация IP-HTTPS
Настройка маршрутизации
IP-HTTPS
netsh interface ipv6 add route
<6to4 prefix>:<IP-HTTP
subnet ID>::/64
IPHTTPSInterface
publish=yes
Настройка компонентов доступа к интрасети
Компонент
Назначение
Команда в командной строке
Windows
ISATAP
Включение ISATAP
netsh interface isatap set
state enabled
ISATAP
Настройка ISATAP
netsh interface isatap set
router <имя или ipv4-адрес
Компонент
Назначение
Команда в командной строке
Windows
маршрутизатора ISATAP>
ISATAP
Настройка ISATAP
Сетевой интерфейс
Настройка перенаправления netsh interface ipv6 set
и объявления интерфейса
interface <индекс
интерфейса#>
forwarding=enabled
advertise=enabled
DNS
Публикация имени ISATAP в dnscmd /recordadd
DNS
<primary_dns_search_suffix>
isatap A
<внутренний_ipv4_адрес>
netsh interface ipv6 add
route 2002:<public_ipv4_addr
ess_hex_converted:1::/64
<индекс интерфейса #>
publish=yes
Примечание
Запустите эту
команду на DNSсервере.
DNS
Включение ответов DNS на
запросы ISATAP
Для каждого DNS-сервера
во всех доменах Active
Directory, содержащих
клиентов DirectAccess,
выполните следующие
действия:
1. На каждом DNSсервере, имеющем
связь с полномочными
DNS-серверами,
откройте командную
строку
2. Введите «dnscmd <имя
DNS-сервера> /info
/globalqueryblocklist» для
просмотра текущего
содержимого списка
Компонент
Назначение
Команда в командной строке
Windows
блокировки

Если список не
содержит слова
isatap, процедура
завершена

Если список
содержит слово
isatap,
идентифицируйте
значение
all_other_names
Например, если
результатом
предыдущей
команды является
текст «wpad isatap
xxх», значение
all_other_names —
это «wpad xxx».
3. Введите команду
«dnscmd <имя сервера>
/config
/globalqueryblocklist
all_other_names».
4. Введите команду
«dnscmd <имя сервера>
/info /globalqueryblocklist»
для повторного
просмотра содержимого
списка блокировок и
убедитесь, что в нем
отсутствует текст isatap.
Примечание
Запустите эту
команду на DNSсервере.
Настройка служб безопасности
Компонент
Команда в командной строке Windows
Предотвращение атак типа «отказ от
обслуживания» IPsec (внешний интерфейс)
netsh ipsecdosp add interface
<имя_интефейса_Internet> public
Предотвращение атак типа «отказ от
обслуживания» IPsec (внешний интерфейс)
netsh ipsecdosp add interface <имяинтерфейса-TLS> public
Предотвращение атак типа «отказ от
обслуживания» IPsec (внутренний
интерфейс)
netsh ipsecdosp add interface
<имя_интерфейса_интрасети> internal
Конфигурация IPSec
Конфигурация шлюза IPsec (модель «от узла до периметра»)
Компонент
Команда в командной строке Windows
Правило защиты трафика к DNS/КД
netsh advfirewall consec add rule
name="DirectAccess Policy ClientToDNSDC"
mode=tunnel profile=public,private
Endpoint1=<IPv6-адрес DNS/DC>
Endpoint2=Any LocalTunnelEndpoint=<IPv6адрес интернет-интерфейса сервера DA
или адрес 6to4> RemoteTunnelEndpoint=Any
Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=<имя
CA> Auth2=UserNTLM
qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1AES128+60min+100000kb
Правило защиты трафика к серверам
управления
netsh advfirewall consec add rule
name="DirectAccess Policy ClientToDNSDC"
mode=tunnel profile=public,private
Endpoint1=<IPv6-адреса серверов
управления> Endpoint2=Any
LocalTunnelEndpoint=<IPv6-адрес интернетинтерфейса сервера DA или адрес 6to4>
Компонент
Команда в командной строке Windows
RemoteTunnelEndpoint=Any
Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=<имя
CA> Auth2=UserNTLM
qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1AES128+60min+100000kb
Правило защиты трафика к остальным
компонентам корпоративной сети
netsh advfirewall consec add rule name="
DirectAccess Policy ClientToCorp"
mode=tunnel profile=public,private
Endpoint1=<IPv6-префикс корпоративной
сети prefix> Endpoint2=Any
LocalTunnelEndpoint=<IPv6-адрес интернетинтерфейса сервера DA или адрес 6to4>
RemoteTunnelEndpoint=Any
Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=
Auth1CA=<имя CA> Auth2=UserKerb
qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1AES128+60min+100000kb
Настройка клиента IPsec (модель "от узла до периметра")
Компонент
Команда в командной строке Windows
Правило защиты трафика к DNS/КД
netsh advfirewall consec add rule
name="DirectAccess Policy ClientToDNSDC"
mode=tunnel profile=public,private
Endpoint1=Any Endpoint2=<IPv6-адрес
DNS/КД> LocalTunnelEndpoint=Any
RemoteTunnelEndpoint=<IPv6-адрес
интернет-интерфейса сервера DA или
адрес 6to4> Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=<имя
CA> Auth2=UserNTLM
qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1-
Компонент
Команда в командной строке Windows
AES128+60min+100000kb
Правило защиты трафика в корпоративную
сеть
netsh advfirewall consec add rule name="
DirectAccess Policy ClientToCorp"
mode=tunnel profile=public,private
Endpoint1=Any Endpoint2=<IPv6-префикс
корпоративной сети >
LocalTunnelEndpoint=Any
RemoteTunnelEndpoint=<IPv6-адрес
интернет-интерфейса сервера DA или
адрес 6to4> Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=
Auth1CA=<имя CA> Auth2=UserKerb
qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1AES128+60min+100000kb
Правило защиты трафика к серверам
управления
netsh advfirewall consec add rule
name="DirectAccess Policy
ClientToManagementservers" mode=tunnel
profile=public,private Endpoint1=Any
Endpoint2=<IPv6-адреса серверов
управления> LocalTunnelEndpoint=Any
RemoteTunnelEndpoint=<IPv6-адрес
интернет-интерфейса сервера DA или
адрес 6to4> Action=RequireInRequireOut
Auth1=ComputerCert Auth1CA=<имя
CA> Auth2=UserNTLM
qmsecmethods=ESP:SHA1AES192+60min+100000kb,ESP:SHA1AES128+60min+100000kb
Правило защиты подключения для
исключения IPsec из NLA
Netsh advfirewall consec add rule
name=”DirectAccess Policy clientToNlaExempt”
mode=tunnel profile=public,private
endpoint1=<IPv6-префикс корпоративной
сети> endpoint2=<IPv6-адрес NLA>
action=noauthentication protocol=tcp port2=443
Приложение D — инструкции по настройке
клиента DirectAccess с помощью
сценариев и групповой политики
Примечание
Перед началом настройки убедитесь, что выполнены предварительные шаги,
описанные в приложении А.
Компоненты подключений
Компонент
Настройка Teredo как
корпоративного клиента
и
Команда в командной строке
Параметры групповой
Windows
политики
netsh interface ipv6 set teredo
enterpriseclient <имя или
ipv4-адрес сервера Teredo>
Computer Configuration|
Policies| Administrative
Templates| Network| TCPIP
Settings| Ipv6 transition
Technologies| Teredo
State=Enterprise Client
Задание сервера Teredo
и
Computer Configuration|
Policies| Administrative
Templates| Network| TCPIP
Settings| Ipv6 transition
Technologies| Teredo Server
Name=<имя или ipv4-адрес
сервера Teredo>
Настройка ретранслятора
6to4
netsh interface 6to4 set relay
<имя или ipv4-адрес
ретранслятора 6to4>
Computer Configuration|
Policies| Administrative
Templates| Network| TCPIP
Settings| Ipv6 transition
Technologies| 6to4 Relay
Name=<имя или ipv4-адрес
ретранслятора 6to4>
Включение клиента IPHTTPS и предоставление
данных сервера
netsh interface httpstunnel
add interface client
https://<myservername>/IPHT
TPS
Computer Configuration|
Policies| Administrative
Templates| Network| TCPIP
Settings| Ipv6 transition
Компонент
Команда в командной строке
Параметры групповой
Windows
политики
Technologies| IP-HTTPS
State=enabled AND <имя или
ipv4-адрес сервера
IPHTTPS>
Таблица Name Resolution Policy Table
Команды командной строки для таблицы NRPT отсутствуют, для управления используются
параметры групповой политики.
Таблицу NRPT следует настраивать с использованием пространств имен, для которых
выполняется настройка. При настройке службы DirectAccess это обычно означает, что
пространство имен интрасети начинается с точки (например, .internal.contoso.com
или .corp.contoso.com). С точки зрения клиента любой запрос, соответствующий одному из
этих пространств имен, будет отправлен на указанные внутренние DNS-серверы.
Убедитесь, что включены все внутренние пространства имен DNS, к которым необходимо
предоставить доступ клиентам DirectAccess.
Примечания

Дополнительные сведения см. в разделе Таблица политики разрешения имен и
служба DNS в этом документе.

Пространство имен должно начинаться с точки, в противном случае таблица NRPT
будет работать неправильно.
Для настройки таблицы NRTP с помощью групповой политики используйте
дополнительный компонент для соответствующего объекта групповой политики по адресу
Computer Configuration\Policies\Windows Settings\Name Resolution Policy. C помощью этого
дополнительного компонента можно создавать новые правила NRPT, а также изменять и
удалять существующие правила.
Приложение E — советы по
использованию сценариев
Сценарии являются мощным средством для создания нестандартных решений. Изучение
языка сценариев может показаться сложной задачей, поэтому в данном разделе
приведены сведения, помогающие понять синтаксис сценариев, использованных в этом
документе.

Полное описание использования средства Netsh.exe с командами ADVFIREWALL см.
на веб-странице Команды Netsh для настройки брандмауэра Windows и
дополнительных параметров безопасности (на английском языке).

Список параметров команды netsh interface ipv6 см. на веб-странице Команды Netsh
для настройки интерфейса (IPv4 и IPv6) (на английском языке).
Сценарии пользовательского интерфейса
DirectAccess
Конструкция сценариев
Средства сценариев интерфейса DirectAccess позволяют администратору использовать
сценарии PowerShell для выполнения комбинаций команд Netsh и PowerShell для
настройки сервера DirectAccess.
Консоль DirectAccess Management Console (консоль управления DirectAccess) позволяет
создать файл данных XML, который затем используется как входные данные для сценария
PowerShell engine.ps1. Файл данных размещается в
папке %WINDIR%\DirectAccess\DirectAccessConfig.xml. Этот файл XML создается при
каждом сохранении или применении параметров настройки в консоли DirectAccess
Management Console. Дополнительные сведения см. на веб-странице Выполнение
сценариев DirectAccess (на английском языке).
При доступе к именам тегов в файле XML администратор может настраивать сервер
DirectAccess и все необходимые групповые политики.
Ниже приведен пример XML-файла данных.
<root>
<ServerData>
<CorpPrefix>2002:1111::/48</CorpPrefix>
.
.
</ServerData>
.
.
</root>
CorpPrefix вызывается в сценарии с использованием следующего формата:
$xmldata.root.ServerData.CorpPrefix.
Функции обеспечивают выполнение следующих задач:

разворачивание переменных;

конструирование команд;

выполнение команд и выход из системы.
Этот список может быть расширен; при необходимости можно добавлять другие команды.
Список функций:

Исполнение команд PowerShell:
pscmdexec(строка команды,описание строки)

Исполнение команд Netsh:
netshcmdexec(строка команды,описание строки)

Исполнение команд netsh, связанных с ipsec и брандмауэром:
netshipseccmdexec(строка setstorecommand, строка ipseccommand, описание
строки)
Использование сценариев
Сценарий использует в качестве аргументов путь к файлу данных и путь к файлу журнала с
обязательным параметром режима.
Engine.ps1 –mode <serveronly|gpsettingonly|all> [–data <путь_к файлу_данных>] [-log
<путь_к_файлу_журнала>]
Описание первого параметра <serveronly|gpsettingonly|all>:

Serveronly: настройка только сервера DirectAccess. Параметры и политики групповой
политики не создаются.

GPSettingOnly: создается и настраивается групповая политика. Сервер DirectAccess не
настраивается.

All: настраивается сервер DirectAccess и групповые политики. Этот режим аналогичен
нажатию кнопки Apply (применить) в консоли DirectAccess Management Console.
Параметры data и log являются необязательными, если они отсутствуют, сценарий ищет
файл данных в местоположении по умолчанию и создает файл журнала в текущей папке с
именем по умолчанию.
Файл журнала
При выполнении сценария создается файл журнала DirectAccessLog.txt, содержащий
данные о выполненных сценарием действиях и время их выполнения. Файл журнала имеет
следующий формат:
<Временная отметка> Step: <описание>
Executing: <выполненная команда>
Output: <вывод команды>
Ограничения при использовании сценариев
Регистрация ISATAP на серверах DNS должна быть выполнена вручную, если протокол
IPv6 не развернут в интрасети и на компьютере, где выполняется сценарий, отсутствует
файл Dnscmd.exe. Есть два способа решить эту проблему:
1. Установите средство Dnscmd.exe с помощью средств удаленного администрирования
сервера. Сценарии будут работать правильно.
2. Добавьте новую запись типа A на DNS-сервере для isatap с внутренним IPv4-адресом
сервера DirectAccess. Этот адрес можно посмотреть в файле XML в строке <root><ServerData>-<TransitionTechnologies>-<ISATAP>-<CorpV4Address>.
Использование сценариев для настройки
правил IPsec
Правила IPsec сложно просматривать и изменять из-за большого объема содержащихся в
них данных. После знакомства с основными сведениями работа с ними упрощается.
Рассмотрим следующий пример:
netsh advfirewall consec add rule name="CorpNet IPv6 Tunnel-Srv" mode=tunnel
Endpoint1=2001:4898::/32 Endpoint2=Any LocalTunnelEndpoint=2001:1111::1111
RemoteTunnelEndpoint=Any Action=RequireInRequireOut Auth1=ComputerCert
Auth1CA="O=Microsoft Corporation, CN=Microsoft Corporate Root CA" Auth2=UserKerb,UserNTLM
Эта команда создает новое правило безопасного подключения для брандмауэра Windows с
именем «CorpNet IPv6 Tunnel-Srv», в котором используется туннельный режим IPsec. Это
правило будет применяться для шлюза Windows Server 2008 R2, оно предназначено для
зашиты трафика от внешнего IP-адреса определенного шлюза, предназначенного для
любых внешних IP-адресов (при развертывании службы DirectAccess этот туннель
используется для трафика управления из интрасети на внешние IP-адреса клиентов).
Параметр Endpoint1 задает диапазон адресов «внутренних подсетей-источников», которым
в данном случае является пространство IPv6-адресов – 2001:4898::/32. Параметр Endpoint2
задает «адрес назначения», в данном случае — любой адрес (значение Any). Значение
Any (любой) — это маска, обозначающая IP-адреса удаленных клиентов, поскольку мы не
знаем, какой IP-адрес будет использовать клиент. Параметр LocalTunnelEndpoint
обозначает «источник туннеля IPsec», в данном случае это внешний IPv6-адрес шлюза
IPsec Gateway, 2001:1111::1111.
Этой командой мы указали, что при попытке компьютера внутренней подсети
2001:4898::/32 создать соединение с внешним клиентом будет создан туннель путем
перенаправления трафика через внешний интерфейс шлюза 2001:1111::1111.
Кроме того, для каждого узла назначения этого туннеля (RemoteTunnelEndpoint) требуется
входящая RequireIn(bound) и исходящая RequireOut(bound) проверка подлинности, тип
требуемой проверки подлинности — сертификат (ComputerCert), выданный центром
сертификации Microsoft Corporate Root CA, а также используется проверка подлинности
Kerberos.
Приложение F — файл
DirectAccessConfig.xsd
Файл DirectAccessConfig.xml file содержит данные конфигурации DirectAccess из мастера
DirectAccess Setup Wizard (мастер DirectAccess Setup Wizard (мастер настройки
DirectAccess)). Ниже приведен XSD-файл определения схемы XML для файла
DirectAccessConfig.xml. Для создания файла DirectAccessConfig.xsd file скопируйте
содержимое в программу Notepad (блокнот) и сохраните с именем DirectAccessConfig.xsd.
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns="http://www.microsoft.com/networking/DirectAccess/v1"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.microsoft.com/networking/DirectAccess/v1"
attributeFormDefault="unqualified" elementFormDefault="qualified">
<xs:element name="root">
<xs:complexType>
<xs:all>
<xs:element name="ServerData">
<xs:complexType>
<xs:all>
<xs:element name="CorpPrefix" type="ipv6Prefix" />
<xs:element name="InternetInterface" type="interface" />
<xs:element name="InternalNetworkInterface" type="interface" />
<xs:element name="TransitionTechnologies">
<xs:complexType>
<xs:all>
<xs:element name="ISATAP" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
This MUST be specified if there is no pre-existing IPv6 or
ISATAP
deployment on the internal network.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:all>
<xs:element name="IsatapRouterName" type="domainName" />
<xs:element name="IsatapInterfaceName" type="domainName" />
<xs:element name="CorpV4Address" type="ipv4Address" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="Teredo">
<xs:complexType>
<xs:all>
<xs:element name="FirstInternetGlobalAddress"
type="ipv4Address" />
</xs:all>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="IPHttps">
<xs:complexType>
<xs:all>
<xs:element name="IpHttpsPrefix" type="ipv6Prefix" />
<xs:element name="IpHttpsCertHash" type="xs:hexBinary" />
<xs:element name="IpHttpsServerURL" type="xs:anyURI" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="DOSPConfig">
<xs:complexType>
<xs:all>
<xs:element name="IPsecUnauthenticatedPerIPRate" default="10240"
type="xs:unsignedInt" />
<xs:element name="IPsecAuthenticatedRate" default="0"
type="xs:unsignedInt" />
<xs:element name="ICMPv6Rate" default="10240" type="xs:unsignedInt"
/>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="IsV6Deployed" type="xs:boolean" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="IIS" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
This MUST be specified in case network location server is run on the
DirectAccess
server and certificate used for securing location identification is same as
that used by remote client to secure connectivity over IPHTTPS.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:all>
<xs:element name="IpHttpsAddresses">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address" type="ipAddress" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="InOutAddresses">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address" type="ipAddress" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="GPO">
<xs:complexType>
<xs:all>
<xs:element name="Common">
<xs:complexType>
<xs:all>
<xs:element name="AppServers" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
List of application server addresses that will enforce
authorization.
This must be specified in case the authorization option is
other than NoAuthorization.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address"
type="ipv6Address" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="DnsServers">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address"
type="ipv6Address" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="MgmtServers" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Address"
type="ipv6PrefixOrAddress" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="CorpV6" type="ipv6Prefix" />
<xs:element name="NonCorpV6" type="xs:string" />
<xs:element name="TunnelEndpointDnsDcMgmt" type="ipv6Address" />
<xs:element name="TunnelEndpointCorp" type="ipv6Address" />
<xs:element name="RootCert" type="xs:string" />
<xs:element name="RootCertNetshFormatted" type="xs:string" />
<xs:element name="CertType">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="Root"/>
<xs:enumeration value="Intermediate"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="SmartCard">
<xs:complexType>
<xs:all>
<xs:element name="Option">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="NoSmartCard"/>
<xs:enumeration value="RemoteSmartCard"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="SDDLString" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
This MUST be specified in case SmartCard option selected
is RequireSmartCard.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="DistinguishedDomainName"
type="distinguishedDomainName" />
<xs:element name="DomainName" type="domainName" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="ClientPolicies">
<xs:complexType>
<xs:all>
<xs:element name="SecurityGroups">
<xs:complexType>
<xs:sequence>
<xs:element name="SecurityGroup" type="sg"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="NRPT">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="entry">
<xs:complexType>
<xs:all>
<xs:element name="Name" type="xs:string" />
<xs:element name="DirectAccessDNSServers"
type="xs:string">
<xs:annotation>
<xs:documentation>
List of DNS server IPv6 addresses (, delimited) for
the DNS suffix
specified in Name element above. Can be empty if
specifying NRPT exepmption.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:all>
<xs:attribute name="PolicyName" type="xs:string"
use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:unique name="NRPTRuleName">
<xs:selector xpath="*" />
<xs:field xpath="@PolicyName" />
</xs:unique>
</xs:element>
<xs:element name="DnsFallBackOptions">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="DnsFallbackNameDoesNotExist"/>
<xs:enumeration value="DnsAlwaysFallbackForAnyError"/>
<xs:enumeration value="DnsAlwaysFallbackPrivateOnly"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="NCSI">
<xs:complexType>
<xs:all>
<xs:element name="NcsiUrl" type="xs:anyURI" />
<xs:element name="NcsiRrName" type="domainName" />
<xs:element name="NcsiRrIp" type="ipv6Address"
fixed="0:0:0:0:0:0:0:1" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="NID">
<xs:complexType>
<xs:all>
<xs:element name="NidCertHash" type="xs:hexBinary"
minOccurs="0"/>
<xs:element name="NidUrl" type="xs:anyURI" />
<xs:element name="NidAddress" type="ipv6Address" />
</xs:all>
</xs:complexType>
</xs:element>
<xs:element name="ClientToDnsPolicy" type="xs:string"
default="DirectAccess Policy-ClientToDnsDc" />
<xs:element name="ClientToCorpPolicy" type="xs:string"
default="DirectAccess Policy-ClientToCorp" />
<xs:element name="ClientToMgmtPolicy" type="xs:string"
default="DirectAccess Policy-ClientToMgmt" minOccurs="0" />
<xs:element name="ClientToApplicationServerPolicy" type="xs:string"
default="DirectAccess Policy-clientToAppServer" minOccurs="0" />
<xs:element name="ClientToApplicationServerExemptPolicy"
type="xs:string" default="DirectAccess Policy-clientToAppServerExempt" minOccurs="0" />
<xs:element name="ClientToNlaExemptPolicy" type="xs:string"
default="DirectAccess Policy-clientToNlaExempt" />
<xs:element name="IpHttpsOutRuleName" type="xs:string" default="Core
Networking - IPHTTPS (TCP-Out)" />
</xs:all>
<xs:attribute name="GPOName" type="xs:string" default="DirectAccess
Policy-{3491980e-ef3c-4ed3-b176-a4420a810f12}" />
</xs:complexType>
</xs:element>
<xs:element name="ServerPolicies">
<xs:complexType>
<xs:all>
<xs:element name="SecurityGroups">
<xs:complexType>
<xs:sequence>
<xs:element name="SecurityGroup" type="sg" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="ServerToDnsPolicy" type="xs:string"
default="DirectAccess Policy-DaServerToDnsDc" />
<xs:element name="ServerToCorpPolicy" type="xs:string"
default="DirectAccess Policy-DaServerToCorp" />
<xs:element name="ServerToMgmtPolicy" type="xs:string"
default="DirectAccess Policy-DaServerToMgmt" minOccurs="0" />
<xs:element name="IpHttpsInRuleName" type="xs:string" default="Core
Networking - IPHTTPS (TCP-In)" />
</xs:all>
<xs:attribute name="GPOName" type="xs:string" default="DirectAccess
Policy-{ab991ef0-6fa9-4bd9-bc42-3c397e8ad300}" />
</xs:complexType>
</xs:element>
<xs:element name="AppServerPolicies">
<xs:complexType>
<xs:all>
<xs:element name="SecurityGroups" minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
List of security groups containing servers that will enforce
authorization.
MUST be specified in case AuthorizationOption is other than
NoAuthorization.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="SecurityGroup" type="sg"
maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="AuthenticationOption">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="NoAuthentication"/>
<xs:enumeration value="SelectedServerEndToEnd"/>
<xs:enumeration value="EndToEndAuthentication"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="EndToEndIPsecCompatibilityMode" type="xs:boolean"
minOccurs="0">
<xs:annotation>
<xs:documentation xml:lang="en-us">
Whether IPsec connection security rules on application servers
should allow null encryption.
MUST be specified in case AuthorizationOption is other than
NoAuthorization.
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="ApplicationServerToClientPolicy" type="xs:string"
default="DirectAccess Policy-appServerToClient" minOccurs="0" />
<xs:element name="ApplicationServerToIpHttpsClientPolicy"
type="xs:string" default="DirectAccess Policy-appServerToIpHttpsClientPolicy"
minOccurs="0" />
</xs:all>
<xs:attribute name="GPOName" type="xs:string" default="DirectAccess
Policy-{f7b77f47-7c33-4d8c-bb9a-a913c5675d8d}" />
</xs:complexType>
</xs:element>
</xs:all>
</xs:complexType>
<xs:unique name="GPONames">
<xs:selector xpath="*" />
<xs:field xpath="@GPOName" />
</xs:unique>
</xs:element>
</xs:all>
<xs:attribute name="State" type="xs:string" fixed="Complete" use="required" />
<xs:attribute name="Version" type="xs:decimal" default="1.0" />
</xs:complexType>
</xs:element>
<xs:complexType name="sg">
<xs:annotation>
<xs:documentation xml:lang="en">
Type representing a security group.
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="Name" type="xs:string" />
<xs:element name="Type">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="computer"/>
<xs:enumeration value="group"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:all>
</xs:complexType>
<xs:complexType name="interface">
<xs:annotation>
<xs:documentation xml:lang="en">
Type representing an network interface. Holds interface properties.
</xs:documentation>
</xs:annotation>
<xs:all>
<xs:element name="Name" type ="xs:string" />
<xs:element name="Id" type="guid" />
</xs:all>
</xs:complexType>
<xs:simpleType name="ipv4Address">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IPv4 address
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="((0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([39][0-9]?))\.){3}(0|(1[0-9]{0,2})|(2(([0-4][0-9]?)|(5[0-5]?)|([6-9]?)))|([3-9][0-9]?))" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipv6Address">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IPv6 address
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4}))|((([0-9a-fAF]{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})))|((([0-9a-fAF]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*)|((([0-9a-fAF]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([09]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})))" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipv6Prefix">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IPv6 prefix
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="((([0-9a-fA-F]{1,4}:){7})([0-9a-fA-F]{1,4})/\d+)|((([0-9a-fAF]{1,4}:){6})(([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\d+)|((([0-9a-fA-
F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*/\d+)|((([09a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(::)(([0-9a-fA-F]{1,4}:)*([0-9a-fA-F]{1,4}))*(([09]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}))/\d+)" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="ipv6PrefixOrAddress">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IPv6 prefix or address
</xs:documentation>
</xs:annotation>
<xs:union memberTypes="ipv6Prefix ipv6Address" />
</xs:simpleType>
<xs:simpleType name="ipAddress" >
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of an IP address. This can be IPv4 or IPv6.
</xs:documentation>
</xs:annotation>
<xs:union memberTypes="ipv4Address ipv6Address" />
</xs:simpleType>
<xs:simpleType name="guid">
<xs:annotation>
<xs:documentation xml:lang="en">
The representation of a GUID, generally the id of an element.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}[a-fA-F0-9]{12}\}"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="domainName">
<xs:annotation>
<xs:documentation>
The domainName type represents a DNS domain name.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="([a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9]\.)*[a-zA-Z][a-zA-Z0-9\-]*[azA-Z0-9]" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="distinguishedDomainName">
<xs:annotation>
<xs:documentation>
This type represents a domain name in distinguished name format.
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:pattern value="(DC=[a-zA-Z][a-zA-Z0-9\-]*[a-zA-Z0-9],)*DC=[a-zA-Z][a-zA-Z0-9\]*[a-zA-Z0-9]" />
</xs:restriction>
</xs:simpleType>
</xs:schema>