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

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

Задача	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 План объектов групповой политики	Определите, какие объекты групповой политики требуются вашей организации и как производить их создание и редактирование.

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

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

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

• 1.1.2 Планирование подключения iPv6 интрасети

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

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). Общие сведение об этих технологиях туннелирования см. в следующих разделах:

   • Технологии перехода IPv6

   • Спецификация протокола туннелирования IP-HTTPS

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

   Description	Внешний сетевой адаптер	Внутренний сетевой адаптер	Требования к маршрутизации
   Интернет с IPv4-адресацией и интрасеть с IPv4-адресацией	Настройте два статичных последовательных IPv4-адреса с соответствующими масками подсети (требуется только для Teredo). Кроме того, настройте IPv4-адрес шлюза по умолчанию интернет-брандмауэра или локального маршрутизатора поставщика услуг Интернета (ISP). Примечание. Для сервера DirectAccess требуется два последовательных общедоступных IPv4-адреса, чтобы он может выступать в качестве сервера Teredo, а клиенты под управлением Windows могут использовать сервер DirectAccess для обнаружения типа устройства NAT, за которым они находятся.	Настройте следующее: — адрес интрасети IPv4 с соответствующей маской подсети. — суффикс DNS для конкретного подключения пространства имен интрасети. DNS-сервер во внутреннем интерфейсе. Внимание. Не настраивайте шлюз по умолчанию для любых интерфейсов интрасети.	Чтобы настроить сервер DirectAccess для связи со всеми подсетями во внутренней IPv4-сети, выполните следующие действия. — список адресов IPv4 для всех расположений в интрасети. — Используйте команду маршрутизации add -p или netsh interface ipv4, чтобы добавить адресные пространства IPv4 в качестве статических маршрутов в таблицу маршрутизации IPv4 сервера DirectAccess.
   IPv6-интернет и IPv6-интрасеть	Настройте следующее: — Используйте конфигурацию адресов, предоставляемую вашим isP. — Используйте команду "Печать маршрута", чтобы убедиться, что существует маршрут IPv6 по умолчанию, и он указывает на маршрутизатор ISP в таблице маршрутизации IPv6. — Определите, используют ли маршрутизаторы по умолчанию маршрутизаторы isP и интрасети, описанные в RFC 4191, и используют ли маршрутизаторы локальной интрасети более высокого значения по умолчанию. Если эти условия выполняются, дальнейшие настройки маршрута по умолчанию не требуются. Использование большего приоритета для маршрутизатора провайдера подразумевает, что активный маршрут IPv6 по умолчанию сервера DirectAccess направлен в IPv6-интернет. Поскольку сервером DirectAccess служит IPv6-маршрутизатор, при наличии собственной инфраструктуры IPv6 веб-интерфейс может также получить доступ к контроллерам домена в интрасети. В этом случае на контроллере домена в сети периметра следует использовать фильтрацию пакетов, чтобы предотвратить подключение к IPv6-адресу имеющего доступ в Интернет интерфейса сервера DirectAccess.	Настройте следующее: — Если вы не используете уровни предпочтений по умолчанию, можно настроить интерфейсы интрасети с помощью следующего набораинтерфейса netsh ipv6 set InterfaceIndex ignoredeultroutes=enabled. После выполнения этой команды дополнительные маршруты по умолчанию, указывающие на маршрутизаторы интрасети, не будут добавлены в таблицу маршрутизации IPv6. Индекс интерфейса интерфейсов интрасети можно получить с помощью следующей команды: интерфейс netsh ipv6 отображает интерфейс.	Если ваша интрасеть использует протокол IPv6, для настройки сервера DirectAccess и осуществления доступа ко всем расположениям IPv6 нужно выполнить следующие действия: — вывод списка адресов IPv6 для всех расположений в интрасети. — Используйте команду ipv6 интерфейса netsh, чтобы добавить адресные пространства 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.

   Примечание.

   • Если клиенту 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 в Интернете и удаленно управлять ими.

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.

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

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

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

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

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

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

• Протокол 41 входящий и исходящий трафик 6to4.

• Конечный порт 443 IP-HTTPS-Передачи (TCP) и исходящий порт TCP 443.

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

  Примечание.

  Это исключение настраивается на сервере 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 требуются сертификаты:

• Шаг 1. Планирование расширенной инфраструктуры DirectAccess
  • 1.1 Планирование топологии сети и параметров
    • 1.1.1 Планирование сетевых адаптеров и IP-адресов
    • 1.1.2 Планирование подключения iPv6 интрасети
    • 1.1.3 План принудительного туннелирования
  • 1.2. Требования к брандмауэру плана
  • 1.3. Требования к сертификату плана
    • 1.3.1 Планирование сертификатов компьютера для проверки подлинности IPsec
    • 1.3.2 Планирование сертификатов для IP-HTTPS
    • 1.3.3 Планирование сертификатов веб-сайта для сервера сетевого расположения
  • 1.4. Требования к DNS плана
    • 1.4.1 Планирование требований к DNS-серверу
    • 1.4.2 План для разрешения локальных имен
  • 1.5 Планирование сервера сетевого расположения
    • 1.5.1 Планирование сертификатов для сервера сетевого расположения
    • 1.5.2 Планирование DNS для сервера сетевого расположения
  • 1.6. Серверы управления планами
  • 1.7 Планирование служб домен Active Directory
    • 1.7.1 Планирование проверки подлинности клиента
    • 1.7.2 Планирование нескольких доменов
  • 1.8 План объектов групповой политики
    • 1.8.1 Настройка автоматически созданных объектов групповой политики
    • 1.8.2 Настройка созданных вручную объектов групповой политики
    • 1.8.3 Управление группами групповой политики в среде с несколькими контроллерами домена
    • 1.8.4 Управление GPOs удаленного доступа с ограниченными разрешениями
    • 1.8.5 Восстановление из удаленного объекта групповой политики
  • Дальнейшие действия

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

Проверка подлинности IPsec	Сервер IP-HTTPS	Сервер сетевого размещения
Внутренний ЦС требуется для выдачи сертификатов компьютера серверу DirectAccess и клиентам для проверки подлинности IPsec, если для проверки подлинности не используется прокси-сервер Kerberos.	Внутренний ЦС: Вы можете использовать внутренний ЦС для выдачи сертификата IP-HTTPS. Однако следует убедиться, что точка распространения CRL доступна из внешней сети.	Внутренний ЦС: Вы можете использовать внутренний ЦС для выдачи сертификата веб-сайта сервера сетевых расположений. Убедитесь, что точка распространения CRL обладает высоким уровнем доступности из внутренней сети.
	Самозаверяющий сертификат: Вы можете использовать самозаверяющий сертификат для сервера IP-HTTPS. Однако следует убедиться, что точка распространения CRL доступна из внешней сети. Самозаверяющий сертификат не может использоваться в развертываниях на нескольких сайтах.	Самозаверяющий сертификат: Вы можете использовать самозаверяющий сертификат для веб-сайта сервера сетевых расположений. Самозаверяющий сертификат не может использоваться в развертываниях на нескольких сайтах.
	Рекомендуется Общедоступный ЦС: Рекомендуется использовать общедоступный ЦС для выдачи сертификата IP-HTTPS. Это обеспечивает внешний доступ к точке распространения CRL.

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

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

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

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

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

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

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

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

• В поле Субъект укажите IPv4-адрес интернет-адаптера сервера DirectAccess или полное доменное имя URL-адреса IP-HTTPS (адрес для подключения). Если сервер DirectAccess за устройством NAT, следует указать имя или адрес этого устройства.

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

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

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

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

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

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

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

1. Удалите существующую привязку сертификата для 0.0.0.0:443 и замените ее на привязку сертификата для выбранного порта. В примере использован порт 44500. Перед удалением привязки порта отобразите и скопируйте 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. Перейдите к configuration=Policies=>Administrative Templates=> Network=>TCPIP settings =>IPv6 transition> technologies.

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

   4. Щелкните Применить.

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

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

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

   3. Щелкните Применить.

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

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

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

   3. На вкладке Проверка подлинности нажмите кнопку Дополнительно.

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

   5. Нажмите кнопку Применить, а затем кнопку ОК.

Чтобы завершить ручной процесс настройки нестандартного порта для IP-HTTPS, выполните команду gpupdate /force на клиентских компьютерах и сервере DirectAccess.

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

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

• В поле Субъект введите IP-адрес интерфейса интрасети сервера сетевых расположений или полное доменное имя URL-адреса сервера сетевых расположений.

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

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

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

  Примечание.

  Убедитесь, что сертификаты для IP-HTTPS и сервера сетевых расположений содержат имя субъекта. Если в сертификате нет имени субъекта, но указано альтернативное имя, мастер удаленного доступа его не примет.

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

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

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

• 1.4.2 План для разрешения локальных имен

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

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

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

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

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

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

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

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

Серверы инфраструктуры

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

  Клиенты DirectAccess пытаются подключиться к серверу сетевых расположений, чтобы определить, находятся ли они во внутренней сети. У клиентов во внутренней сети должна быть возможность для разрешения имени сервера сетевых расположений, но если они расположены в Интернете, для них разрешение имени необходимо запретить. Для этого по умолчанию полное доменное имя сервера сетевых расположений добавляется в таблицу 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-сервер

  Сервер 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 использует ISATAP для установки IPv6-подключений к узлам ISATAP в интрасети. В сетевой среде без встроенной поддержки IPv6 сервер DirectAccess автоматически настраивается как маршрутизатор ISATAP.

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

• Средства проверки подключения

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

  • directaccess-webprobehost-Должен разрешать внутренний IPv4-адрес сервера DirectAccess или IPv6-адрес в среде, доступной только для IPv6.

  • directaccess-corpconnectivityhost-Должен разрешаться по адресу локального узла (loopback). Необходимо создать следующие записи ресурса узла (A и AAAA): запись ресурса узла A со значением 127.0.0.1 и запись ресурса узла AAAA со значением, составленным из префикса NAT64 с последними 32 разрядами, которые представляют 127.0.0.1. Префикс NAT64 можно получить с помощью следующей команды Windows PowerShell: get-netnattransitionconfiguration.

    Примечание.

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

  Вы можете создать дополнительные проверки подключения, используя другие веб-адреса HTTP или 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.

  Примечание.

  При развертывании 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, к однокомпонентному имени будут добавлены суффиксы из списка. Например, когда пользователь на компьютере, являющегося членом типов https://paycheck доменов corp.contoso.com в веб-браузере, полное доменное имя, созданное как имя, paycheck.corp.contoso.com. По умолчанию добавляемый суффикс основан на основном суффиксе DNS клиентского компьютера.

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

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

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

DNS с разделением мозга

Разделенная система 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. В поле Субъект введите IP-адрес интерфейса интрасети сервера сетевых расположений или полное доменное имя URL-адреса сервера сетевых расположений.

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

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

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

Клиенты DirectAccess пытаются подключиться к серверу сетевых расположений, чтобы определить, находятся ли они во внутренней сети. У клиентов во внутренней сети должна быть возможность для разрешения имени сервера сетевых расположений, но если они расположены в Интернете, для них разрешение имени необходимо запретить. Для этого по умолчанию полное доменное имя сервера сетевых расположений добавляется в таблицу 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). Раздел состоит из следующих подразделов:

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

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

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

• Аутентификация

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

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

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

• Группы безопасности

  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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 1.8.4 Управление GPOs удаленного доступа с ограниченными разрешениями

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

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

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

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

• GPO сервера DirectAccess

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

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

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

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

• Автоматически можно указать, что они создаются автоматически. Каждому объекту присваивается имя по умолчанию.

• Вручную можно использовать объекты групповой политики, предварительно определенные администратором Active Directory.

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

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

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

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

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

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

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

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

• разрешения для создания GPO в каждом домене;

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

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

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

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

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

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

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

• Мастер настройки удаленного доступа следует запускать, когда объекты групповой политики уже существуют.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Чтобы сделать это в Windows PowerShell, укажите параметр DomainController для командлета Open-NetGPO. Например, чтобы включить частные и общедоступные профили в брандмауэре 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 с необходимой областью управления и применяет соответствующие фильтры безопасности. Это гарантирует, что изменения данных GPO применяются к компьютерам в домене (клиентским компьютерам и серверам DirectAccess, а также серверам приложений). У администратора удаленного доступа нет разрешений для производственных GPO.

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

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

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

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

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

1. Запустите командлет Windows PowerShell Uninstall-remoteaccess.

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

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

Следующие шаги

• Шаг 2. Планирование развертываний DirectAccess