Поделиться через

Шаг 1. Планирование расширенной инфраструктуры DirectAccess

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

Task Description
1.1 Планирование топологии сети и параметров Выберите место размещения сервера DirectAccess (на границе либо за устройством преобразования сетевых адресов (NAT) или брандмауэром) и запланируйте IP-адресацию, маршрутизацию и принудительное туннелирование.
1.2 Планирование требований к брандмауэру Определите, какой трафик DirectAccess будет пропускаться через пограничные брандмауэры.
1.3. Требования к сертификату плана Решите, будет ли использоваться для клиентской проверки подлинности протокол Kerberos или сертификаты и запланируйте сертификаты веб-сайта. IP-HTTPS — это протокол перехода, используемый клиентами DirectAccess для туннелирования трафика IPv6 через сети IPv4. Определите, будет ли проверка подлинности на сервере IP-HTTPS выполняться с помощью сертификата, выданного центром сертификации (ЦС), или с помощью самозаверяющего сертификата, автоматически выдаваемого сервером DirectAccess.
1.4 Планирование требований к DNS Запланируйте параметры DNS для сервера DirectAccess, для серверов инфраструктуры, для параметров локального разрешения имен и для подключения клиентов.
1.5 Планирование сервера сетевого расположения Сервер сетевых расположений используется клиентами DirectAccess, чтобы определить, находятся ли они во внутренней сети. Выберите, где будет размещен веб-сайта сервера сетевых расположений в вашей организации (на сервере DirectAccess или другом сервере) и определите требования для сертификатов, если сервер сетевых расположений расположен на сервере DirectAccess.
1.6. Серверы управления планами Вы можете удаленно управлять клиентскими компьютерами DirectAccess, размещенными за пределами корпоративной сети в Интернете. План управления серверами (такими как серверы обновления), которые используются для управления удаленными клиентами.
1.7 Планирование служб домен Active Directory Запланируйте контроллеры домена, требования Active Directory, клиентскую проверку подлинности и несколько доменов.
1.8 План объектов групповой политики Определите, какие GPO требуются вашей организации и как их создавать и редактировать.

1.1. Планирование топологии и параметров сети

В этом разделе описывается планирование сети, в том числе:

1.1.1. Планирование сетевых адаптеров и IP-адресации

  1. Определите, какую топологию сетевых адаптеров хотите использовать. DirectAccess можно настроить с использованием следующих топологий:

    • Два сетевых адаптера. Сервер DirectAccess можно установить на пограничном сервере, один сетевой адаптер которого подключен к Интернету, а другой — к внутренней сети. Также сервер можно установить за устройством NAT, брандмауэром или маршрутизатором, один сетевой адаптер которого подключен к сети периметра, а другой — к внутренней сети.

    • Один сетевой адаптер. Сервер DirectAccess установлен за устройством NAT, при этом единственный сетевой адаптер подключен к внутренней сети.

  2. Определите требования к IP-адресации:

    Для установки безопасного подключения клиентских компьютеров к внутренней сети корпорации в технологии DirectAccess используются протоколы IPv6 и IPsec. Однако для работы DirectAccess необязательно подключаться к Интернету по IPv6 или использовать во внутренних сетях оборудование с поддержкой IPv6. Сервер автоматически настраивает и использует технологии туннелирования IPv6 для туннелирования трафика IPv6 в Интернет с IPv4-адресацией (используя 6to4, Teredo или IP-HTTPS) и в интрасети, поддерживающей только IPv4 (используя NAT64 или ISATAP). Общий обзор этих переходных технологий см. в следующих ресурсах:

  3. Настройте требуемые адаптеры и адреса, опираясь на следующую таблицу. Для развертываний, использующих один сетевой адаптер, которые настроены за устройством NAT, настройте IP-адреса, используя только столбец Адаптер внутренней сети.

    Description Внешний сетевой адаптер Внутренний сетевой адаптер Routing requirements
    Интернет с IPv4-адресацией и интрасеть с IPv4-адресацией Настройте два статичных последовательных IPv4-адреса с соответствующими масками подсети (требуется только для Teredo).

    Кроме того, настройте IPv4-адрес шлюза по умолчанию интернет-брандмауэра или локального маршрутизатора поставщика услуг Интернета (ISP). Note: The DirectAccess server requires two consecutive public IPv4 addresses so that it can act as a Teredo server and Windows-based clients can use the DirectAccess server to detect the type of NAT device that they are behind.    		 Настройте следующее:

    — адрес интрасети IPv4 с соответствующей маской подсети.
    — специфичный для подключения DNS-суффикс в пространстве имен вашей интрасети. DNS-сервер также должен быть настроен на внутреннем интерфейсе. Caution: Do not configure a default gateway on any intranet interfaces.    		 Чтобы настроить сервер DirectAccess для связи со всеми подсетями во внутренней IPv4-сети, выполните следующие действия.

    Составьте список адресов IPv4 для всех узлов вашей интрасети.
    — Используйте команду route add -p или netsh interface ipv4 add route для добавления адресных пространств IPv4 как статических маршрутов в таблицу маршрутизации IPv4 сервера DirectAccess.
    IPv6-интернет и IPv6-интрасеть Настройте следующее:

    — Используйте настройки адреса, предоставляемые вашим провайдером.
    - Use the Route Print command to ensure that a default IPv6 route exists, and it is pointing to the ISP router in the IPv6 routing table.
    — Определите, используют ли маршрутизаторы вашего интернет-провайдера и интрасети предпочтения маршрутизатора по умолчанию, описанные в RFC 4191, и имеют ли они более высокий уровень предпочтения по умолчанию, чем локальные маршрутизаторы интрасети.
    Если эти условия выполняются, дальнейшие настройки маршрута по умолчанию не требуются. Использование большего приоритета для маршрутизатора провайдера подразумевает, что активный маршрут IPv6 по умолчанию сервера DirectAccess направлен в IPv6-интернет.

    Поскольку сервером DirectAccess служит IPv6-маршрутизатор, при наличии собственной инфраструктуры IPv6 веб-интерфейс может также получить доступ к контроллерам домена в интрасети. В этом случае на контроллере домена в сети периметра следует использовать фильтрацию пакетов, чтобы предотвратить подключение к IPv6-адресу имеющего доступ в Интернет интерфейса сервера DirectAccess.    		 Настройте следующее:

    — Если вы не используете уровни предпочтений по умолчанию, вы можете настроить интерфейсы интрасети с помощью следующей команды: netsh interface ipv6 set InterfaceIndex ignoredefaultroutes=enabled.
    После выполнения этой команды дополнительные маршруты по умолчанию, указывающие на маршрутизаторы интрасети, не будут добавлены в таблицу маршрутизации IPv6. Для получения индекса интерфейса вашей интрасети используйте следующую команду: netsh interface ipv6 show interface.    		 Если ваша интрасеть использует протокол IPv6, для настройки сервера DirectAccess и осуществления доступа ко всем расположениям IPv6 нужно выполнить следующие действия:

    Перечислите адресные пространства IPv6 для всех локаций в вашей интрасети.
    — Используйте команду netsh interface ipv6 add route, чтобы добавить адресные пространства IPv6 в качестве статических маршрутов в таблицу маршрутизации IPv6 сервера DirectAccess.
    IPv4-Интернет и IPv6-интрасеть Сервер DirectAccess перенаправляет IPv6-трафик по умолчанию через адаптер Microsoft 6to4 в ретранслятор 6to4 в IPv4-интернете. Можно настроить сервер DirectAccess для адреса IPv4 адаптера Microsoft 6to4 с помощью следующей команды: netsh interface ipv6 6to4 set relay name=<ipaddress> state=enabled.

    Note

    • Если клиенту DirectAccess был присвоен публичный IPv4-адрес, для подключения к интрасети он будет использовать технологию туннелирования 6to4. Если ему назначен частный IPv4-адрес, будет использоваться Teredo. Если клиент DirectAccess не может подключиться к серверу DirectAccess с помощью технологий 6to4 или Teredo, он будет использовать IP-HTTPS.
    • Для применения Teredo необходимо настроить два последовательных IP-адреса на внешнем сетевом адаптере.
    • Teredo не может использоваться, если на сервере DirectAccess всего один сетевой адаптер.
    • Клиентским компьютерам, поддерживающим IPv6 и подключающимся по этому протоколу к серверу DirectAccess, не требуется выполнять туннелирование.

1.1.2. Планирование возможностей подключения к интрасети IPv6

Для управления удаленными клиентами DirectAccess требуется IPv6. IPv6 позволяет серверам управления DirectAccess подключаться к клиентам DirectAccess в Интернете и удаленно управлять ими.

Note

  • Использование IPv6 для поддержки подключений, инициированных клиентскими компьютерами DirectAccess, к IPv4-ресурсам в сети вашей организации не требуется. Для этого применяется NAT64/DNS64.
  • Если вы не управляете удаленными клиентами DirectAccess, развертывать IPv6 необязательно.
  • Протокол автоматической адресации туннелей внутри сайта (ISATAP) не поддерживается в развертываниях DirectAccess.
  • При использовании IPv6 можно включить запросы записи ресурсов узла IPv6 (AAAA) для DNS64, выполнив следующую команду Windows PowerShell: Set-NetDnsTransitionConfiguration -OnlySendAQuery $false.

1.1.3. Планирование принудительного туннелирования

По умолчанию при использовании IPv6 и таблицы политик разрешения имен (NRPT) клиенты DirectAccess разделяют свой трафик интрасети и интернет-трафик следующим образом:

  • Запросы DNS-имен для полностью определенных доменных имен (FQDN), подключенных к интрасети, и весь трафик интрасети передаются через туннели, созданные с сервером DirectAccess, или непосредственно с серверами интрасети. Трафик интрасети от клиентов DirectAccess — это трафик IPv6.

  • Запросы DNS-имен для FQDN, которые соответствуют правилам исключения или не соответствуют пространству имен интрасети, а также весь трафик к интернет-серверам передаются через физический интерфейс, соединенный с Интернетом. Интернет-трафик от клиентов DirectAccess — это обычно трафик IPv4.

Напротив, некоторые виртуальные частные сети (VPN) удаленного доступа, в том числе VPN-клиенты, по умолчанию отправляют весь трафик интрасети и Интернета по VPN-подключению удаленного доступа. Трафик, направленный в Интернет, передается VPN-сервером на IPv4 веб-прокси сервера для доступа к ресурсам в IPv4 Интернете. Трафик интрасети и Интернета можно разделить для VPN-клиентов удаленного доступа, используя раздельное туннелирование. Для этого необходимо настроить таблицу маршрутизации IP на VPN-клиентах так, чтобы трафик к ресурсам интрасети отправлялся по VPN-подключению, а трафик для всех других ресурсов передавался с использованием физического интерфейса, подключенного к Интернету.

Вы можете настроить клиенты DirectAccess для передачи всего трафика через туннели на сервер DirectAccess с помощью принудительного туннелирования. Если настроено принудительное туннелирование, клиенты DirectAccess, которые определили, что они находятся в Интернете, удаляют свой маршрут IPv4 по умолчанию. За исключением локального трафика подсети, весь трафик от клиента DirectAccess — это IPv6-трафик, который проходит через туннели на сервер DirectAccess.

Important

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

Использование принудительного туннелирования приводит к следующим последствиям:

  • Клиенты DirectAccess используют для IPv6-подключения к серверу DirectAccess по IPv4 -интернету только протокол IP-HTTPS.

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

Important

Для использования принудительного туннелирования с помощью DNS64 и NAT64 необходимо реализовать подключение к IPv6-интернету. Один из способов для этого — сделать префикс IP-HTTPS глобально маршрутизируемым, чтобы домен ipv6.msftncsi.com был доступен по IPv6, а клиенты IP-HTTPS могли возвращать данные через сервер DirectAccess.

В большинстве случаев это невозможно, поэтому лучше всего создать виртуальные NCSI-серверы в корпоративной сети следующим образом:

  1. Добавьте запись NRPT для домена ipv6.msftncsi.com и сопоставьте ее в DNS64 с внутренним веб-сайтом (это может быть веб-сайт IPv4).
  2. Добавьте запись NRPT для домена dns.msftncsi.com и сопоставьте ее с корпоративным DNS-сервером для получения записи ресурсов узла IPv6 (AAAA), fd3e:4f5a:5b81::1. (Использование DNS64 только для отправки запросов записи ресурса узла (A) для этого FQDN может не сработать, так как DNS64 используется в развертываниях только с поддержкой IPv4. Поэтому следует настроить разрешение непосредственно через корпоративный DNS-сервер.)

1.2. Планирование требований брандмауэра

Если сервер DirectAccess находится за пограничным брандмауэром и размещен в IPv4-интернете, для трафика удаленного доступа необходимы следующие исключения:

  • UDP-конечный порт 3544 для входящего трафика Teredo и UDP-исходный порт 3544 для исходящего.

  • Входящий и исходящий трафик 6to4 для протокола IP 41.

  • Порт назначения IP-HTTPS по протоколу TCP — 443, а исходящий порт TCP — 443.

  • Если вы развертываете удаленный доступ с одним сетевым адаптером, а сервер сетевых расположений установлен на сервере DirectAccess, также следует добавить в список исключений TCP-порт 62000.

    Note

    Это исключение настраивается на сервере DirectAccess, а все другие — на пограничном брандмауэре.

В отношении трафика Teredo и 6to4 эти исключения должны применяться для обоих последовательных общедоступных IPv4-адресов для выхода в Интернет на сервере DirectAccess. Для IP-HTTPS данные исключения необходимо применить по адресу, зарегистрированному на общедоступном DNS-сервере.

Если сервер DirectAccess размещен в IPv6-интернете, для трафика удаленного доступа необходимы следующие исключения:

  • Код протокола IP 50

  • UDP-порт назначения 500 для входящих подключений и UDP-порт источника 500 для исходящих подключений

  • Входящий и исходящий трафик ICMPv6 (только при использовании Teredo)

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

  • Протокол ISATAP 41 для входящего и исходящего трафика

  • Протоколы TCP/UDP для всех типов трафика IPv4 и IPv6

  • ICMP для всех типов трафика IPv4 и IPv6 (только при использовании Teredo)

1.3. Планирование требований сертификатов

Существуют определенные сценарии, в которых при развертывании одного сервера DirectAccess требуются сертификаты:

Требования к центру сертификации (ЦС) для каждого сценария кратко описаны в следующей таблице.

IPsec authentication IP-HTTPS server Сервер сетевого определения местоположения
Внутренний ЦС необходим для выдачи компьютерных сертификатов на сервере DirectAccess и клиентам для проверки подлинности IPsec, если не используется прокси-сервер Kerberos для проверки подлинности. Internal CA:

Вы можете использовать внутренний ЦС для выдачи сертификата IP-HTTPS. Однако следует убедиться, что точка распространения CRL доступна из внешней сети.		 Internal CA:

Вы можете использовать внутренний центр сертификации (ЦС) для выдачи сертификата веб-сайта сервера сетевых расположений. Убедитесь, что точка распространения CRL обладает высоким уровнем доступности из внутренней сети.
Self-signed certificate:

Вы можете использовать самозаверяющий сертификат для сервера IP-HTTPS. Однако следует убедиться, что точка распространения CRL доступна из внешней сети.

Самозаверяющий сертификат не может использоваться в развертываниях на нескольких сайтах.		 Self-signed certificate:

Вы можете использовать самоподписанный сертификат для веб-сайта сервера сетевого расположения.

Самозаверяющий сертификат не может использоваться в развертываниях на нескольких сайтах.
Recommended

Public CA:

Рекомендуется использовать общедоступный ЦС для выдачи сертификата IP-HTTPS. Это обеспечивает внешний доступ к точке распространения CRL.

1.3.1. Планирование сертификатов компьютера для проверки подлинности IPsec

Если вы используете проверку подлинности IPsec на основе сертификатов, серверу и клиентам DirectAccess необходимо получить сертификат компьютера. Самый простой способ установить сертификаты — это настроить автоматическую регистрацию сертификатов компьютера на основе групповой политики. При этом все участники домена будут получать сертификат от корпоративного ЦС. Если в вашей организации не настроен корпоративный ЦС, изучите статью Службы сертификатов Active Directory.

К сертификату применяются следующие требования:

  • Сертификат должен использовать расширенное использование ключа (EKU) клиентской проверки подлинности.

  • Сертификат клиента и сертификат сервера должны быть связаны с одним корневым сертификатом. Корневой сертификат выбирается в параметрах конфигурации DirectAccess.

1.3.2. Планирование сертификатов для IP-HTTPS

Сервер DirectAccess действует как прослушиватель IP-HTTPS, поэтому вам следует вручную настроить на нем сертификат веб-сайта HTTPS. При планировании учитывайте следующее:

  • Рекомендуется использовать общедоступный ЦС, чтобы списки аннулирования сертификатов (CRL) были легко доступны.

  • In the Subject field, specify the IPv4 address of the Internet adapter of DirectAccess server or the FQDN of the IP-HTTPS URL (the ConnectTo address). Если сервер DirectAccess расположен за устройством NAT, следует указать общедоступное имя или адрес этого устройства.

  • Общее имя сертификата должно совпадать с именем узла IP-HTTPS.

  • В поле Улучшенное использование ключа введите идентификатор объекта проверки подлинности сервера (OID).

  • В поле Точки распространения CRL укажите точку распространения CRL, доступную клиентам DirectAccess, подключенным к Интернету.

  • У сертификата IP-HTTPS должен быть закрытый ключ.

  • Сертификат IP-HTTPS необходимо импортировать непосредственно в личное хранилище сертификатов.

  • В имени сертификатов IP-HTTPS может быть постановочный знак.

Если вы планируете использовать IP-HTTPS с нестандартным портом, выполните следующие действия на сервере DirectAccess.

  1. Удалите существующую привязку сертификата для 0.0.0.0:443 и замените ее на привязку сертификата для выбранного порта. В примере использован порт 44500. Prior to deleting the certificate binding, show and copy the appid.

    1. Чтобы удалить привязку сертификата, введите:

      netsh http delete ssl ipport=0.0.0.0:443

    2. Чтобы добавить новую привязку сертификата, введите:

      netsh http add ssl ipport=0.0.0.0:44500 certhash=<use the thumbprint from the DirectAccess server SSL cert> appid=<use the appid from the binding that was deleted>

  2. Чтобы изменить URL-адрес IP-HTTPS на сервере, введите:

    Netsh int http set int url=https://<DirectAccess server name (for example server.contoso.com)>:44500/IPHTTPS

    Net stop iphlpsvc & net start iphlpsvc

  3. Измените резервирование URL-адреса для kdcproxy.

    1. Чтобы удалить существующее резервирование URL-адреса, введите:

      netsh http del urlacl url=https://+:443/KdcProxy/

    2. Чтобы добавить новое резервирование URL-адреса, введите:

      netsh http add urlacl url=https://+:44500/KdcProxy/ sddl=D:(A;;GX;;;NS)

  4. Добавьте этот параметр, чтобы служба kppsvc прослушивала нестандартный порт. Чтобы добавить запись в реестр, введите:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KPSSVC\Settings /v HttpsUrlGroup /t REG_MULTI_SZ /d +:44500 /f

  5. Чтобы перезапустить службу kdcproxy на контроллере домена, введите:

    net stop kpssvc & net start kpssvc

Чтобы использовать IP-HTTPS с нестандартным портом, выполните следующие действия на контроллере домена.

  1. Измените параметр IP-HTTPS в объекте групповой политики клиента.

    1. Откройте редактор групповых политик.

    2. Перейдите в Конфигурация компьютера=>Политики=>Административные шаблоны=>Сеть=>Настройки TCPIP=>Технологии перехода на IPv6.

    3. Откройте параметр состояния IP-HTTPS и измените URL-адрес на имя сервера https:// DirectAccess (например, server.contoso.com<)>:44500/IPHTTPS.

    4. Click Apply.

  2. Измените параметры клиента прокси-сервера Kerberos в объекте групповой политики клиента.

    1. В редакторе групповой политики перейдите в раздел "Конфигурация компьютера=Политики>=>Административные шаблоны=> System=>Kerberos => Укажите прокси-серверы KDC для клиентов Kerberos".

    2. Откройте параметр состояния IPHTTPS и измените URL-адрес на имя сервера https:// DirectAccess (например, server.contoso.com<)>:44500/IPHTTPS.

    3. Click Apply.

  3. Измените параметры клиентской политики IPsec для использования ComputerKerb и UserKerb.

    1. В редакторе групповой политики перейдите в раздел "Конфигурация компьютера=>Политики> = Параметры Windows=> Параметры безопасности=> Брандмауэр Windows с расширенной безопасностью".

    2. Щелкните Правила безопасности подключений и дважды щелкните Правило IPsec.

    3. On the Authentication tab, click Advanced.

    4. Для Auth1: удалите текущий метод проверки подлинности и замените его на ComputerKerb. Для Auth2: удалите текущий метод проверки подлинности и замените его на UserKerb.

    5. Click Apply, and then OK.

To complete the manual process for using an IP-HTTPS non-standard port, run gpupdate /force on the client computers and the DirectAccess server.

1.3.3 Планирование сертификатов веб-сайта для сервера сетевого расположения

При планировании веб-сайта для сервера сетевого расположения учитывайте следующее:

  • In the Subject field, specify the IP address of the intranet interface of the network location server or the FQDN of the network location URL.

  • В поле Улучшенное использование ключа введите идентификатор объекта проверки подлинности сервера (OID).

  • В поле Точки распространения списков отзыва (CRL) укажите точку распространения списков отзыва, доступную клиентам DirectAccess, подключённым к интрасети. Точка распределения CRL должна быть недоступна за пределами внутренней сети.

  • Если вы планируете в дальнейшем настроить развертывания на нескольких сайтах или в кластере, имя сертификата не должно совпадать с внутренним именем серверов DirectAccess, которые будут добавлены в развертывание.

    Note

    Ensure that the certificates for IP-HTTPS and the network location server have a Subject Name. If the certificate does not have a Subject Name, but it has an Alternative Name, it will not be accepted by the Remote Access Wizard.

1.4. Планирование требований DNS

В этом разделе описываются требования к DNS для клиентских запросов DirectAccess и серверов инфраструктуры в развертывании удаленного доступа. Раздел включает следующие подразделы.

Запросы клиентов DirectAccess

Служба DNS используется для разрешения запросов от клиентских компьютеров DirectAccess, расположенных вне внутренней (корпоративной) сети. Клиенты DirectAccess пытаются подключиться к серверу сетевых расположений DirectAccess, чтобы определить, находятся ли они в Интернете или во внутренней сети.

  • Если подключение установлено успешно, клиенты идентифицируются как клиенты во внутренней сети, DirectAccess не используется, а клиентские запросы разрешаются с помощью DNS-сервера, настроенного для сетевого адаптера клиентского компьютера.

  • В противном случае считается, что клиенты расположены в Интернете, а клиенты DirectAccess будут использовать таблицу политики разрешения имен (NRPT), чтобы определить DNS-сервер, который будет использоваться при разрешении запросов имен.

Вы можете указать, что клиенты должны использовать для разрешения имен DirectAccess DNS64 или альтернативный внутренний DNS-сервер. При разрешении имен клиенты DirectAccess используют NRPT для определения способа обработки запроса. Клиенты запрашивают полное доменное имя или имя одной метки, например https://internal. Если запрашивается однокомпонентное имя, к нему добавляется DNS-суффикс, чтобы создать полное доменное имя. Если запрос DNS соответствует записи в таблице NRPT и для нее указан сервер DNS64 или DNS во внутренней сети, запрос отправляется для разрешения имен с использованием указанного сервера. Если соответствующая запись существует, но DNS-сервер не задан, это указывает на правило исключения — используется нормальное разрешение имен.

Note

Note that when a new suffix is added to the NRPT in the Remote Access Management Console, the default DNS servers for the suffix can be automatically discovered by clicking Detect.

Автообнаружение работает следующим образом:

  • Если корпоративная сеть использует только IPv4-адресацию или IPv4- и IPv6-адресацию, адрес по умолчанию — это адрес DNS64 внутреннего адаптера сервера DirectAccess.

  • Если корпоративная сеть основана на IPv6, адресом по умолчанию служит IPv6-адрес DNS-серверов корпоративной сети.

Note

Начиная с обновления Windows 10 мая 2020 г. клиент больше не регистрирует СВОИ IP-адреса на DNS-серверах, настроенных в таблице политики разрешения имен (NRPT). If DNS registration is needed, for example Manage Out, it can be explicitly enabled with this registry key on the client:

Путь: HKLM\System\CurrentControlSet\Services\Dnscache\Parameters.
Тип: DWORD
Имя значения: DisableNRPTForAdapterRegistration
Values:
1 — Регистрация DNS отключена (по умолчанию с обновления Windows 10 мая 2020 г.)
0 — включена регистрация DNS

Infrastructure servers

  • Сервер сетевого расположения

    Клиенты DirectAccess пытаются подключиться к серверу сетевых расположений, чтобы определить, находятся ли они во внутренней сети. У клиентов во внутренней сети должна быть возможность для разрешения имени сервера сетевых расположений, но если они расположены в Интернете, для них разрешение имени необходимо запретить. Для этого по умолчанию полное доменное имя (FQDN) сервера сетевой локации добавляется в таблицу NRPT как правило исключения. Кроме того, при настройке удаленного доступа автоматически создаются следующие правила:

    • Правило DNS-суффикса для корневого домена или доменного имени сервера DirectAccess, а также для IPv6-адресов, соответствующих адресу DNS64. В корпоративных сетях с поддержкой только IPv6 DNS-серверы интрасети настроены на сервере DirectAccess. Например, если сервер DirectAccess server причастен к домену corp.contoso.com, создается правило для DNS-суффикса corp.contoso.com.

    • Правило исключения для полного доменного имени сервера сетевого расположения. Например, если URL-адрес сервера сетевого расположения имеет значение https://nls.corp.contoso.com, для полного доменного имени nls.corp.contoso.com создается правило исключения.

  • IP-HTTPS server

    Сервер DirectAccess действует как прослушиватель IP-HTTPS и использует свой сертификат сервера для проверки подлинности клиентов IP-HTTPS. Имя IP-HTTPS должно разрешаться клиентами DirectAccess, использующими общедоступные DNS-серверы.

  • Проверка отзыва сертификатов (CRL)

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

  • ISATAP

    ISATAP позволяет корпоративным компьютерам получать IPv6-адрес и инкапсулирует IPv6-пакеты в заголовке IPv4. DirectAccess сервер используется для предоставления IPv6-подключения к ISATAP узлам в интрасети. В сетевой среде без встроенной поддержки IPv6 сервер DirectAccess автоматически настраивается как маршрутизатор ISATAP.

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

  • Connectivity verifiers

    Служба удаленного доступа создает веб-зонд по умолчанию, который клиентские компьютеры DirectAccess используют для проверки подключения к внутренней сети. Чтобы убедиться, что проба работает, как ожидается, необходимо вручную зарегистрировать следующие имена в DNS:

    • directaccess-webprobehost-Should resolve to the internal IPv4 address of the DirectAccess server, or to the IPv6 address in an IPv6-only environment.

    • directaccess-corpconnectivityhost-Should resolve to the local host (loopback) address. Необходимо создать следующие записи ресурса узла (A) и (AAAA): запись ресурса узла A со значением 127.0.0.1 и запись ресурса узла AAAA со значением, сформированным из префикса NAT64 с последними 32 битами, соответствующими 127.0.0.1. The NAT64 prefix can be retrieved by running the Windows PowerShell command get-netnattransitionconfiguration.

      Note

      Это действительно только в среде, поддерживающей только IPv4. В среде с поддержкой IPv4 и IPv6, а также в среде с поддержкой только IPv6 необходимо создать запись ресурса узла (AAAA) с петлевым IP-адресом ::1.

    You can create additional connectivity verifiers by using other web addresses over HTTP or by using ping. Для каждого средства проверки подключения должна существовать DNS-запись.

1.4.1. Планирование требований DNS-сервера

Далее представлены требования для DNS при развертывании DirectAccess.

  • Для клиентов DirectAccess необходимо использовать DNS-сервер под управлением Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows Server 2008 или любой другой DNS-сервер, поддерживающий IPv6.

    Note

    При развертывании DirectAccess не рекомендуется использовать DNS-серверы, работающие на Windows Server 2003. Хотя DNS-серверы Windows Server 2003 поддерживают записи IPv6, Windows Server 2003 больше не поддерживается корпорацией Майкрософт. Кроме того, не следует развертывать DirectAccess, если контроллеры домена работают под управлением Windows Server 2003 из-за проблемы со службой репликации файлов. Дополнительные сведения см. в разделе Конфигурации DirectAccess, которые не поддерживаются.

  • Используйте DNS-сервер, который поддерживает динамические обновления. Можно использовать DNS-серверы, не поддерживающие динамические обновления, но при этом следует вручную обновить записи на них.

  • Полное доменное имя точек распространения CRL, доступных через Интернет, должно разрешаться с помощью DNS-серверов Интернета. Например, если URL-адрес https://crl.contoso.com/crld/corp-DC1-CA.crl находится в Поле точек распространения CRL сертификата IP-HTTPS сервера DirectAccess, необходимо убедиться, что полное доменное имя crld.contoso.com может быть разрешено с использованием DNS-серверов Интернета.

1.4.2. Планирование локального разрешения имен

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

NRPT

В следующих ситуациях может потребоваться создать дополнительные правила NRPT:

  • Если необходимо добавить дополнительные суффиксы DNS для пространства имен интрасети.

  • Если полное доменное имя (FQDN) точек распространения CRL основано на пространстве имен интрасети, необходимо добавить правила исключения для полных доменных имен точек распространения CRL.

  • Если у вас настроен разделенный DNS, необходимо добавить правила исключения для имен ресурсов, к которым находящиеся в Интернете клиенты DirectAccess должны иметь доступ к версии для Интернета, а не к версии для интрасети.

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

    Например, если вы проверяете внешний веб-сайт test.contoso.com, это имя не разрешается с помощью DNS-серверов в Интернете, но сервер веб-прокси Contoso знает, как разрешить имя и направлять запросы к веб-сайту на внешний веб-сервер. Чтобы не позволить пользователям за пределами интрасети Contoso получить доступ к сайту, внешний веб-сайт разрешает только запросы от IPv4-адреса веб-прокси Contoso в Интернете. Таким образом пользователи интрасети могут получить доступ к веб-сайту, так как они применяют веб-прокси Contoso, а пользователи DirectAccess — не могут, так как они не используют веб-прокси Contoso. Если настроить правило исключения NRPT для сайта test.contoso.com, который использует веб-прокси Contoso, запросы веб-страницы для test.contoso.com направляются на сервер веб-прокси интрасети через IPv4-интернет.

Имена отдельных меток

Имена отдельных меток, например https://paycheck, иногда используются для серверов интрасети. Если запрошено однокомпонентное имя и настроен список поиска суффикса DNS, к однокомпонентному имени будут добавлены суффиксы из списка. Например, когда пользователь на компьютере, который является членом домена corp.contoso.com, вводит https://paycheck в веб-браузере, полное доменное имя, созданное в качестве имени, будет paycheck.corp.contoso.com. По умолчанию добавляемый суффикс основан на основном суффиксе DNS клиентского компьютера.

Note

В сценарии с непересекающимся пространством имен (когда суффикс DNS одного или нескольких компьютеров в домене не соответствует домену Active Directory, которому принадлежит компьютер), следует убедиться, что список поиска содержит все необходимые суффиксы. По умолчанию мастер удаленного доступа настраивает DNS-имя Active Directory в качестве основного суффикса DNS на клиенте. Добавьте суффикс DNS, используемый клиентами для разрешения имен.

Если в вашей организации развернуто несколько доменов и служба Windows Internet Name Service (WINS), и вы подключаетесь удаленно, однокомпонентные (одноуровневые) имена могут быть разрешены следующим образом:

  • Разверните зону прямого просмотра WINS в DNS. При попытке разрешить имя computername.dns.zone1.corp.contoso.com запрос направляется на сервер WINS, который использует только computername. Клиент считает, что выдает обычную запись ресурса узла DNS (A), но на самом деле это запрос NetBIOS. Дополнительные сведения см. в разделе "Управление зоной прямого просмотра".

  • Добавьте суффикс DNS, например, dns.zone1.corp.contoso.com, в политику домена по умолчанию (GPO).

Split-brain DNS

Split-brain DNS - это использование одного и того же домена DNS для разрешения имен в Интернете и интрасети.

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

Чтобы обе версии ресурса были доступны в среде с разделенной DNS, настройте ресурсы интрасети с альтернативными именами, которые не совпадают с именами, используемыми в Интернете, и сообщите пользователям о необходимости применять альтернативное имя при работе в интрасети. Например, настройте альтернативное имя www.internal.contoso.com для внутреннего имени www.contoso.com.

В среде без разделения DNS пространство имен Интернета отличается от пространства имен интрасети. Например, корпорация Contoso использует имя contoso.com в Интернете и имя corp.contoso.com в интрасети. Так как все ресурсы интрасети используют DNS-суффикс corp.contoso.com, правило NRPT для corp.contoso.com направляет все запросы DNS-имен для ресурсов интрасети на DNS-серверы интрасети. Запросы DNS-имен с суффиксом contoso.com не соответствуют правилу пространства имен интрасети corp.contoso.com в таблице NRPT и отправляются на DNS-серверы Интернета. При использовании развертывания DNS без разделения на зоны, ввиду отсутствия дублирования полных доменных имен для ресурсов интрасети и Интернета, дополнительная настройка NRPT не требуется. Клиенты DirectAccess могут получить доступ к ресурсам организации в Интернете и интрасети.

Поведение разрешения локальных имен для клиентов DirectAccess

Если имя не может быть разрешено с помощью DNS, для разрешения имени в локальной подсети служба DNS-клиента в Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, Windows 8 и Windows 7 может использовать локальное разрешение имен с помощью протоколов LLMNR (многоадресное разрешение имен для локальной сети) и NetBIOS через TCP/IP.

Локальное разрешение имен обычно требуется для однорангового соединения, когда компьютер находится в частных сетях, например, в домашних сетях с одной подсетью. Когда клиентская служба DNS выполняет локальное разрешение имен серверов интрасети, а компьютер подключен к общей подсети в Интернете, злоумышленники могут перехватывать сообщения LLMNR и NetBIOS через TCP/IP для определения имен серверов интрасети. Вы можете настроить локальное разрешение имен в зависимости от типов ответов, получаемых от DNS-серверов интрасети на странице "DNS" мастера настройки сервера инфраструктуры. Имеются следующие варианты:

  • Использовать локальное разрешение имен, если имя не существует в DNS. Этот параметр наиболее надежен, так как клиент DirectAccess выполняет локальное разрешение имен только для имен серверов, которые не удалось сопоставить с помощью DNS-серверов интрасети. Если DNS-серверы интрасети доступны, имена серверов интрасети определяются. Если DNS-серверы внутренней сети недоступны или возникают другие типы ошибок DNS, имена серверов внутренней сети не попадают в подсеть через локальное разрешение имен.

  • Использовать локальное разрешение имен, если имя не существует в DNS или DNS-серверы недоступны для клиентского компьютера, находящегося в частной сети (рекомендуется). Рекомендуется использовать этот параметр, потому что он позволяет применять локальное разрешение имен в частной сети, только если DNS-серверы интрасети недоступны.

  • Использовать локальное разрешение имен при любой ошибке разрешения DNS (наименее безопасное). Это наименее безопасный вариант, так как имена серверов интрасети могут попасть в подсеть при локальном разрешении имен.

1.5. Планирование сервера сетевых расположений

Сервер сетевых расположений — это веб-сайт, определяющий, находятся ли клиенты DirectAccess в корпоративной сети. Клиенты в корпоративной сети не используют DirectAccess для доступа к внутренним ресурсам, а подключаются к ним напрямую.

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

Убедитесь, что веб-сайт сервера сетевых расположений соответствует следующим требованиям:

  • это веб-сайт с сертификатом HTTPS-сервера;

  • Клиентские компьютеры DirectAccess должны доверять ЦС, который выдал сертификат сервера для веб-сайта сервера сетевого расположения.

  • клиентские компьютеры DirectAccess во внутренней сети должны иметь возможность для разрешения имени сайта сервера сетевых расположений;

  • Узел сервера местоположения сети должен обеспечивать высокую доступность для компьютеров на внутренней сети.

  • сервер сетевых расположений не должен быть доступен клиентским компьютерам DirectAccess в Интернете;

  • сертификат сервера необходимо проверить с помощью CRL.

1.5.1. План сертификатов для сервера сетевых расположений

При получении сертификата веб-сайта для сервера сетевых расположений учитывайте следующее:

  1. In the Subject field, specify an IP address of the intranet interface of the network location server or the FQDN of the network location URL.

  2. В поле Улучшенное использование ключа введите идентификатор объекта проверки подлинности сервера (OID).

  3. В поле Точки распространения списков отзыва (CRL) укажите точку распространения списков отзыва, доступную клиентам DirectAccess, подключённым к интрасети. Точка распределения CRL должна быть недоступна за пределами внутренней сети.

1.5.2. Настройка DNS для сервера сетевых расположений

Клиенты DirectAccess пытаются подключиться к серверу сетевых расположений, чтобы определить, находятся ли они во внутренней сети. У клиентов во внутренней сети должна быть возможность для разрешения имени сервера сетевых расположений, но если они расположены в Интернете, для них разрешение имени необходимо запретить. Для этого по умолчанию полное доменное имя (FQDN) сервера сетевой локации добавляется в таблицу NRPT как правило исключения.

1.6. Планирование серверов управления

Клиенты DirectAccess инициируют связь с серверами управления, которые предоставляют такие службы, как Центр обновления Windows и обновления антивирусного ПО. Клиенты DirectAccess также используют протокол Kerberos для связи с контроллерами домена и проверки подлинности перед доступом к внутренней сети. При удаленном управлении клиентами DirectAccess серверы управления взаимодействуют с клиентскими компьютерами для осуществления функций управления, например оценки программных или аппаратных активов. Служба удаленного доступа может автоматически обнаруживать некоторые серверы управления, в том числе:

  • Контроллеры домена — автоматическое обнаружение контроллеров домена выполняется для всех доменов в том же лесу, что и сервер DirectAccess и клиентские компьютеры.

  • Серверы Microsoft Endpoint Configuration Manager: автоматическое обнаружение серверов Configuration Manager выполняется для всех доменов в той же лесовой структуре, что и сервер DirectAccess и клиентские компьютеры.

Контроллеры домена и серверы Configuration Manager автоматически обнаруживаются при первом настройке DirectAccess. Обнаруженные контроллеры домена не отображаются в консоли, но параметры можно получить с помощью командлета Windows PowerShell Get-DAMgmtServer -Type All. Если контроллер домена или серверы Configuration Manager изменены, нажав "Обновить серверы управления" в консоли управления удаленным доступом, вы обновите список серверов управления.

Требования к серверу управления

  • Серверы управления должны быть доступны через первый (инфраструктурный) туннель. Если добавить серверы в список серверов управления при настройке удаленного доступа, они автоматически становятся доступными через этот туннель.

  • Серверы управления, инициирующие связь с клиентами DirectAccess, должны полностью поддерживать IPv6 с помощью собственного IPv6-адреса или адреса, назначенного ISATAP.

1.7. Планирование доменных служб Active Directory

В этом разделе описывается, как DirectAccess использует доменные службы Active Directory (AD DS). Раздел состоит из следующих подразделов:

DirectAccess использует объекты групповой политики AD DS и Active Directory следующим образом:

  • Authentication

    Службы AD DS используются для проверки подлинности пользователей. Туннель инфраструктуры использует проверку подлинности NTLMv2 для учетной записи компьютера, которая подключается к серверу DirectAccess. Эта учетная запись должна быть указана в домене Active Directory. Туннель интрасети применяет проверку подлинности Kerberos для создания пользователем второго туннеля.

  • Объекты групповой политики

    DirectAccess собирает параметры конфигурации в объектах групповой политики, которые применяются к серверам и клиентам DirectAccess, а также внутренним серверам приложений.

  • Security groups

    DirectAccess использует группы безопасности для обнаружения клиентских компьютеров DirectAccess и сбора данных о них. Объекты групповой политики применяются к требуемой группе безопасности.

  • Расширенные политики IPsec

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

Требования к AD DS

При планировании использования служб AD DS для развертывания DirectAccess необходимо учитывать следующие требования:

  • Не менее одного контроллера домена необходимо установить с операционной системой Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 или Windows Server 2008.

    Если контроллер домена находится в сети периметра (и, следовательно, доступен с сетевого адаптера сервера DirectAccess с выходом в Интернет), необходимо запретить серверу DirectAccess доступ к нему, добавив фильтры пакетов на контроллере домена, чтобы не допустить связи с IP-адресом адаптера с доступом в Интернет.

  • Сервер DirectAccess должен быть членом домена.

  • Клиенты DirectAccess должны быть членами домена. Клиенты могут принадлежать к:

    • Любому домену в одном лесу с сервером DirectAccess.

    • Любому домену, имеющему двустороннее доверие с доменом сервера DirectAccess.

    • Любой домен в лесу, имеющий двустороннее доверие с лесом, к которому принадлежит домен DirectAccess.

Note

  • Сервер DirectAccess не может быть контроллером домена.
  • Контроллер домена AD DS, используемый для DirectAccess, не должен быть доступен с внешнего интернет-адаптера сервера DirectAccess (т. е. адаптер должен отсутствовать в профиле домена брандмауэра Windows).

1.7.1. Планирование клиентской проверки подлинности

DirectAccess позволяет использовать сертификаты для проверки подлинности IPsec или встроенный прокси-сервер Kerberos, который проверяет подлинность с помощью имен и паролей пользователей.

Если вы решили использовать учетные данные AD DS для проверки подлинности, DirectAccess применяет один туннель безопасности, использующий Computer Kerberos для первой проверки подлинности и User Kerberos для второй. При применении такого режима проверки подлинности DirectAccess использует один туннель безопасности, предоставляющий доступ к DNS-серверу, контроллеру домена и другим серверам по внутренней сети.

Если вы выбрали двухфакторную проверку подлинности или защиту доступа к сети, DirectAccess применяет два туннеля безопасности. Мастер настройки удаленного доступа настраивает брандмауэр Windows с расширенными функциями безопасности, применяя правила безопасности соединения, которые определяют использование следующих типов учетных данных при согласовании ассоциаций безопасности IPsec для туннелей к серверу DirectAccess.

  • Туннель инфраструктуры использует учетные данные Computer Kerberos для первой проверки подлинности и учетные данные User Kerberos для второй.

  • Туннель интрасети использует учетные данные сертификата компьютера для первоначальной аутентификации и пользовательские учетные данные Kerberos для вторичной аутентификации.

Если DirectAccess выбирает разрешение доступа к клиентам под управлением Windows 7 или в мультисайтовом развертывании, он использует два туннеля безопасности. Мастер настройки удаленного доступа настраивает брандмауэр Windows с расширенными функциями безопасности, применяя правила безопасности соединения, которые определяют использование следующих типов учетных данных при согласовании ассоциаций безопасности IPsec для туннелей к серверу DirectAccess.

  • Туннель инфраструктуры использует учетные данные сертификата компьютера для первой проверки подлинности и NTLMv2 для второй. Учетные данные NTLMv2 вызывают принудительное использование протокола AuthIP и предоставляют доступ к DNS-серверу и контроллеру домена, прежде чем клиент DirectAccess сможет использовать учетные данные Kerberos для туннеля интрасети.

  • Туннель интрасети использует учетные данные сертификата компьютера для первоначальной аутентификации и пользовательские учетные данные Kerberos для вторичной аутентификации.

1.7.2. Планирование нескольких доменов

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

Note

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

Если это возможно, следует добавить общие суффиксы доменных имен в таблицу политик разрешения имен (NRPT) во время развертывания службы удаленного доступа. Например, если у вас два домена, domain1.corp.contoso.com и domain2.corp.contoso.com, вместо добавления двух записей в таблицу NRPT, можно добавить запись общего суффикса DNS с суффиксом доменного имени corp.contoso.com. Это происходит автоматически для доменов в одном корневом домене, но остальные домены необходимо добавить вручную.

Если служба WINS развернута в среде с несколькими доменами, следует развернуть зону прямого просмотра WINS в DNS. Дополнительные сведения см. в разделе 'Одинарные имена меток' в разделе 'План 1.4.2' для разрешения локальных имен ранее в этом документе.

1.8. Планирование объектов групповой политики

В этом разделе описывается роль объектов групповой политики (GPO) в инфраструктуре удаленного доступа. Раздел состоит из следующих подразделов:

Параметры DirectAccess, которые вы настраиваете при конфигурировании удаленного доступа, собираются в объекты групповой политики. Следующие типы объектов групповой политики заполняются параметрами DirectAccess и распространяются, как показано ниже:

  • Объект групповой политики клиента DirectAccess

    Этот GPO содержит параметры клиента, в том числе параметры технологии туннелирования IPv6, записи NRPT и правила безопасности подключений брандмауэра Windows в режиме повышенной безопасности. Этот GPO применяется к группам безопасности, указанным для клиентских компьютеров.

  • GPO сервера DirectAccess

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

  • GPO серверов приложений

    Этот GPO содержит параметры для выбранных серверов приложений, на которые при желании можно распространять проверку подлинности и шифрование с клиентов DirectAccess. Если проверка подлинности и шифрование не расширены, этот GPO не используется.

Объекты групповой политики можно создавать двумя способами:

  • Automatically-You can specify that they are created automatically. Для каждого GPO задано имя по умолчанию.

  • Manually-You can use GPOs that have been predefined by the Active Directory administrator.

Note

После того как DirectAccess сконфигурирован для использования определенных объектов групповой политики (GPO), его невозможно настроить для использования других объектов.

Независимо от того, используете ли вы автоматически или вручную настраиваемые GPO, вам следует добавить политику обнаружения медленного канала, если клиенты будут применять 3G-сети. Путь к параметру Политика: Настройка обнаружения медленных соединений для групповой политики следующий: Computer configuration/Policies/Administrative Templates/System/Group Policy.

Caution

Используйте следующую процедуру, чтобы выполнить резервное копирование всех GPO удаленного доступа перед выполнением командлетов DirectAccess: Резервное копирование и восстановление конфигурации удаленного доступа.

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

1.8.1. Настройка автоматически созданных объектов групповой политики

При использовании автоматически созданных GPO учитывайте следующее:

Автоматически созданные GPO применяются в соответствии с расположением и целевым параметром связи следующим образом:

  • Для GPO сервера DirectAccess параметр расположения и параметр связи указывают на домен, содержащий сервер DirectAccess.

  • При создании клиентских и серверных GPO для приложений местоположение задается в рамках одного домена, где будет создан GPO. Выполняется поиск имени GPO в каждом домене, и он заполняется параметрами DirectAccess, если он существует. Цель ссылки установлена в корневом каталоге домена, в котором был создан GPO. Таким образом, объект групповой политики создается в каждом домене, в котором имеются клиентские компьютеры или серверы приложений, и привязывается к его корневому каталогу.

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

  • разрешения на создание объектов групповой политики в каждом домене

  • разрешения для связывания всех выбранных корневых элементов клиентских доменов;

  • Разрешения на связывание для корневых элементов домена сервера GPO.

Кроме того, требуются следующие разрешения:

  • Для GPO требуются разрешения на создание, редактирование, удаление и изменение параметров безопасности.

  • Мы рекомендуем, чтобы администратор удаленного доступа получил разрешение для чтения GPO в каждом требуемом домене. Это позволяет Удаленному доступу убедиться, что не существует объектов групповой политики (GPOs) с одинаковыми именами при их создании.

1.8.2. Настройка вручную созданных объектов групповой политики

При использовании вручную созданных GPO учитывайте следующее:

  • Объекты групповой политики (GPO) должны существовать до запуска мастера настройки удаленного доступа.

  • Чтобы применить параметры DirectAccess, администратору удаленного доступа требуются разрешения полного доступа (изменение и удаление разрешений безопасности) к вручную созданным GPO.

  • Выполняется поиск ссылки на GPO по всему домену. Если объект групповой политики (GPO) не связан с доменом, ссылка автоматически создается в корневом элементе домена. Если требуемые разрешения для создания связи недоступны, формируется предупреждение.

1.8.3. Управление объектами групповой политики в среде с несколькими контроллерами домена

Каждый GPO управляется определенным контроллером домена следующим образом:

  • GPO сервера управляет один из контроллеров домена на сайте Active Directory, связанном с сервером. Если контроллеры домена на этом сайте доступны только для чтения, управление GPO сервера осуществляется контроллером домена с включенной записью, который ближе всего к серверу DirectAccess.

  • GPO для клиентов и серверов приложений управляются контроллером домена, который работает в качестве основного контроллера домена (PDC).

Если вы хотите вручную настроить параметры GPO, учитывайте следующее:

  • Чтобы определить, какой контроллер домена связан с сервером DirectAccess для GPO, выполните команду nltest /dsgetdc: /writable в командной строке с повышенными полномочиями на сервере DirectAccess.

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

Кроме того, если вы изменяете параметры на контроллере домена, который не связан с сервером DirectAccess (для GPO сервера) или не является PDC (для GPO клиента и сервера приложений), учитывайте следующее:

  • Перед изменение параметров убедитесь, что контроллер домена реплицирован с применением обновленного GPO и создайте резервную копию параметров GPO. Дополнительные сведения см. в статье Резервное копирование и восстановление конфигурации удаленного доступа. Если GPO не обновлен, во время репликации могут возникнуть конфликты объединения, что может привести к повреждению конфигурации удаленного доступа.

  • После изменения параметров необходимо дождаться репликации изменений на контроллеры домена, связанные с GPO. Не вносите дополнительные изменения, используя консоль управления удаленным доступом или командлеты удаленного доступа PowerShell, пока процесс репликации не завершится. Если GPO изменяется на двух контроллерах домена до завершения репликации, могут возникнуть конфликты объединения, что может привести к повреждению конфигурации удаленного доступа.

Кроме того, вы можете изменить параметр по умолчанию в диалоговом окне Изменение контроллера домена в консоли управления групповой политикой или с помощью командлета Windows PowerShell Open-NetGPO, чтобы изменения использовали заданный вами контроллер домена.

  • Чтобы сделать это в консоли управления групповой политикой, щелкните правой кнопкой домен или контейнер сайтов и выберите команду Изменить контроллер домена.

  • To do this in Windows PowerShell, specify the DomainController parameter for the Open-NetGPO cmdlet. Например, чтобы включить частные и общедоступные профили в брандмауэре Windows в GPO с именем domain1\DA_Server_GPO _Europe, используя контроллер домена europe-dc.corp.contoso.com, введите следующую команду:

    $gpoSession = Open-NetGPO -PolicyStore "domain1\DA_Server_GPO _Europe" -DomainController "europe-dc.corp.contoso.com"
Set-NetFirewallProfile -GpoSession $gpoSession -Name @("Private","Public") -Enabled True
Save-NetGPO -GpoSession $gpoSession

1.8.4. Управление ГПО удаленного доступа с ограниченными разрешениями

Для управления развертыванием удаленного доступа администратору удаленного доступа требуются разрешения полного доступа (изменение и удаление разрешений безопасности) к GPO, используемым в развертывании. Это связано с тем, что консоль управления удаленным доступом и модули PowerShell удаленного доступа читают конфигурацию из GPO удаленного доступа (т. е. GPO клиента, сервера и сервера приложений) и записывают ее в них.

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

Чтобы адаптировать эти требования, администратор домена должен создать две копии каждого GPO: промежуточную и производственную. Администратор удаленного доступа получает полный доступ к стадийным GPO. Администратор удаленного доступа указывает промежуточные GPO в консоли управления удаленным доступом и в командлетах Windows PowerShell как GPO, используемые для развертывания удаленного доступа. Это позволит администратору удаленного доступа читать и изменить конфигурацию удаленного доступа, когда необходимо.

Администратор домена должен убедиться, что промежуточные GPO не связаны с областью управления в домене и что у администратора удаленного доступа нет разрешений на связывание GPO в домене. Это гарантирует, что изменения, внесенные администратором удаленного доступа в промежуточные ГПО, не повлияют на компьютеры в домене.

Администратор домена связывает производственные GPO с необходимой областью управления и применяет соответствующие фильтры безопасности. Это гарантирует, что изменения данных GPO применяются к компьютерам в домене (клиентским компьютерам и серверам DirectAccess, а также серверам приложений). У администратора удаленного доступа нет полномочий на GPO в производственной среде.

Когда вносятся изменения в подготовительные GPO, администратор домена может просмотреть конфигурацию политики в этих GPO, чтобы убедиться, что она соответствует требованиям безопасности в организации. Затем администратор домена экспортирует параметры из промежуточных GPO, используя функцию резервного копирования, и импортирует их в соответствующие производственные GPO, которые будут применены к компьютерам в этом домене.

На схеме ниже показана эта конфигурация.

Управление GPO удаленного доступа

1.8.5. Восстановление удаленного объекта групповой политики

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

В консоли управления удаленным доступом отобразится следующее сообщение об ошибке: Не удается найти объект групповой политики (имя групповой политики). Чтобы удалить параметры конфигурации, выполните следующие действия:

  1. Run the Windows PowerShell cmdlet Uninstall-remoteaccess.

  2. Откройте консоль управления удаленным доступом.

  3. Отобразится сообщение об ошибке, говорящее, что GPO не найден. Щелкните Удалить параметры конфигурации. После завершения сервер будет восстановлен в состоянии без настроенных параметров.

Next steps