Полное руководство по UAG DirectAccess (часть 4) — требования к инфраструктуре

Введение

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

Компоненты инфраструктуры решения UAG DirectAccess

Хотя мастер UAG DirectAccess выполняет большую часть настройки за вас, существует ряд компонентов инфраструктуры, которые необходимо установить, прежде чем вы сможете развернуть решение UAG DirectAccess. Мастер UAG DirectAccess настроит многие из них за вас, но другие компоненты потребуют, чтобы вы установили и настроили их отдельно. Хорошей новостью является то, что большинство этих инфраструктурных сервисов вы уже используете и с которыми уже знакомы, так что кривая обучения не будет такой крутой. Основная проблема, с которой вам, как администратору UAG DirectAccess, придется столкнуться, — это количество «движущихся частей», задействованных в решении. Однако, как только вы настроите UAG DirectAccess в тестовой среде, вы поймете, как все эти части работают вместе, и все это будет иметь смысл, и на самом деле может показаться, что настроить его довольно просто.

Ключевые компоненты инфраструктуры UAG DirectAccess включают следующее:

• Доменные службы Active Directory и групповая политика

• Службы доменных имен (DNS)

• Инфраструктура открытых ключей (PKI) и службы сертификации Windows Active Directory

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

• Серверы списка отозванных сертификатов (CRL)

• Брандмауэр Windows с повышенной безопасностью и сетевыми брандмауэрами

• VPN-серверы удаленного доступа

• Инфраструктура NAP и смарт-карт

В этой и следующей части этой серии мы обсудим каждый из этих серверов и технологий, а также то, как они интегрируются с решением UAG DirectAccess. В этой части (Часть 4) основное внимание будет уделено первым трем: доменным службам Active Directory и групповой политике, службам DNS и PKI/Windows Active Directory Certificate Services.

Доменные службы Active Directory и групповая политика

И клиент DirectAccess, и сервер UAG DirectAccess должны быть членами домена. Учетная запись клиентского компьютера DirectAccess и учетная запись пользователя могут быть членами домена или леса, отличного от сервера UAG DirectAccess, но в этом случае необходимо убедиться, что между лесом сервера UAG и компьютером/компьютером существует двустороннее доверие. лес учетных записей пользователей. Нет условий для конфигурации рабочей группы, на стороне клиента или на стороне сервера.

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

Еще одна причина, по которой компьютеры должны быть членами домена, — это возможность сопоставления сертификатов компьютеров в хранилище NT Auth Store в Active Directory. Это необходимо для проверки подлинности сертификата компьютера, которая используется для проверки подлинности первого и второго туннелей IPsec DirectAccess. Если сертификат компьютера не сопоставлен, компьютер не сможет установить эти туннели. Active Directory также позволяет нам использовать возможность автоматического развертывания сертификатов через групповую политику. Мы рассмотрим развертывание сертификатов компьютеров позже при обсуждении PKI и служб сертификации Windows Active Directory.

Еще одна важная вещь, которую следует понимать в отношении Active Directory, заключается в том, что не требуется функциональный уровень домена. Вы можете запустить свою текущую инфраструктуру Active Directory на функциональном уровне Windows Server 2003 и заставить работать DirectAccess. Контроллер домена Windows Server 2008 или Windows Server 2008 R2 не требуется.

Службы доменных имен (DNS)

DNS является частью всех сетей, поэтому для вас это не будет новой технологией. Фактически, вы можете использовать любую версию DNS, которая вам нравится, в решении UAG DirectAccess. Однако уровень функциональности, которую вы получаете, зависит от того, что могут поддерживать ваши DNS-серверы. Если вам нужна полная функциональность, ваши DNS-серверы должны поддерживать записи IPv6 Quad A (AAAA) и иметь возможность принимать динамическую регистрацию этих записей. Если вы используете Windows Server 2008 или более позднюю версию в качестве корпоративного DNS-сервера, он будет соответствовать этим требованиям.

Динамические регистрации IPv6 используются в основном в двух областях:

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

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

Однако вы по-прежнему можете использовать другие DNS-серверы, например DNS-серверы сторонних производителей или Windows Server 2003 и более ранних версий. Вы потеряете некоторые функциональные возможности, поскольку эти серверы не поддерживают динамическую регистрацию записей IPv6, а это означает, что клиентам DirectAccess потребуется использовать NAT64/DNS64 для всех своих взаимодействий с ресурсами в корпоративной сети. Ранее мы обсуждали некоторые ограничения NAT64/DNS64. Однако, если вас устраивают эти ограничения, вам не нужно обновляться до DNS-серверов Windows Server 2008 или более поздней версии.

Инфраструктура открытых ключей (PKI) и службы сертификации Windows Active Directory

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

Если у вас нет какой-либо PKI, не позволяйте этому требованию стать препятствием для развертывания DirectAccess. Требования PKI относительно просты. Вам нужны сертификаты в трех местах для развертывания UAG DirectAccess:

• Всем клиентским компьютерам DirectAccess требуется сертификат компьютера, предоставленный ЦС вашего предприятия. Это позволяет автоматически сопоставлять сертификаты компьютеров с учетными записями компьютеров и значительно повышает общую безопасность решения. Это параметр по умолчанию для UAG DirectAccess, и мы настоятельно рекомендуем использовать центр сертификации служб сертификации Windows Active Directory и групповую политику для автоматизации развертывания сертификатов компьютеров в инфраструктуре домена/леса.

• Серверу сетевых расположений требуется сертификат веб-сайта, поскольку компьютеры, настроенные как клиенты DirectAccess, пытаются использовать SSL-подключение к серверу NLS, чтобы определить, находится ли клиент DirectAccess в корпоративной сети или вне ее. Windows PKI не требуется, но упрощает задачу назначения сертификатов веб-сайтам. Список отзыва сертификатов ЦС, выдавшего этот сертификат, должен быть доступен компьютерам, которые настроены как клиенты DirectAccess, когда они подключены к корпоративной сети.

• Серверу UAG DirectAccess требуется сертификат веб-сайта для привязки к его прослушивателю IP-HTTPS. Несмотря на то, что у вас есть возможность использовать частную инфраструктуру открытого ключа на основе инфраструктуры ЦС служб сертификации Windows Active Directory, мы настоятельно рекомендуем вам использовать коммерческий сертификат, чтобы обеспечить высокую доступность CRL, указанного в сертификате. Если клиент DirectAccess в Интернете пытается использовать IP-HTTPS для подключения к серверу UAG DirectAccess и не может подключиться к CRL, указанному в сертификате, соединение IP-HTTPS завершится ошибкой.

Вы можете запустить свою частную PKI с одного сервера сертификатов Windows Server 2008 или Windows Server 2008 R2. На самом деле, если единственным сервером Windows Server 2008 или более поздней версии является сервер UAG DirectAccess, вы можете использовать ЦС Windows Server 2003 и Active Directory Windows Server 2003 для создания и развертывания сертификатов. Что касается сертификата IP-HTTPS, вы можете использовать свою частную PKI для проверки концепции и небольших пилотных развертываний, но вы избавите себя от многих проблем, если будете использовать коммерческий сертификат для своей рабочей версии DirectAccess.

Резюме

Развертывание UAG DirectAccess зависит от наличия и правильной настройки необходимых компонентов инфраструктуры. В этой части 4 нашей серии статей о UAG DirectAccess мы начали обсуждение того, как настроить инфраструктуру, чтобы DirectAccess работал. В следующем месяце, в части 5, мы продолжим это обсуждение с подробным описанием серверов сетевого расположения, серверов списков отзыва сертификатов (CRL), брандмауэра Windows в режиме повышенной безопасности и сетевых брандмауэров, VPN-серверов удаленного доступа, NAP и инфраструктуры смарт-карт. Тогда увидимся!

• Полное руководство по UAG DirectAccess (часть 5) — требования к инфраструктуре (продолжение)