Light-electric.com

IT Журнал
3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Настройка direct access

Пошаговая установка DirectAccess

Возьмите сервер с Windows Server 2008 R2 и двумя сетевыми картами с последовательными адресам, и это пошаговое руководство позволит уже сегодня получить собственную постоянно доступную виртуальную частную сеть DirectAccess.

Я сижу у кофейне со своим мобильным компьютером, который является членом корпоративного домена. По щелчку буквы диска H: я могу увидеть файлы и папки на внутреннем файлом сервере. При выполнении команды gpupdate /force или wuauclt /detectnow применяются групповые политики и проверяется наличие обновлений, поступающих с внутренних контроллеров домена и WSUS-серверов. Короче говоря, я использую DirectAccess и мне это нравится.

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

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

Шаг 1. Создайте и подготовьте сервер DirectAccess

Начните с подготовки машины под управлением Windows Server 2008 R2 с двумя сетевыми картами. Эта машина должна быть членом внутреннего домена Active Directory. Одну сетевую карту подключите к внешней подсети, а другую — к внутренней сети. Далее нужно установить сертификаты и компоненты DirectAccess. Так как этот сервер будет служить мостом между внешней и внутренней сетью надо обеспечить, чтобы на нем присутствовали все необходимые обновления.

Также потребуются два последовательных IP-адреса, например 98.34.120.34 и 98.34.120.35. Очень важно, чтобы они были последовательными. Получение таких адресов может оказаться сложной задачей для ИТ-отдела небольшой компании. Нужно очень аккуратно подходить к выбору Интернет-провайдера.

К выбору адресов надо отнестись очень внимательно. Все дело в том, какие адреса считаются «последовательными». В консоли DirectAccess Management в алфавитном порядке перечисляются все открытые IPv4-адреса, назначенные Интернет-адаптеру. Поэтому в DirectAccess следующие пары адресов не считаются последовательными: w.x.y.9 и w.x.y.10 (потому что они упорядочиваются, как w.x.y.10, w.x.y.9), w.x.y.99 и w.x.y.100 (они упорядочиваются, как w.x.y.100, w.x.y.99), w.x.y.1, w.x.y.2 и w.x.y.10 (они сортируются, как w.x.y.1, w.x.y.10, w.x.y.2). В этих случаях вам потребуются другие наборы последовательных адресов.

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

Шаг 2. Создание внешних записей DNS

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

Допустим, в среде есть две записи A — directaccess.company.com и crl.company.com. Для создания этих записей может потребоваться помощь вашего Интернет-провайдера.

Шаг 3. Создание инфраструктуры PKI с помощью служб Active Directory Certificate Services

Одна из компонентов безопасности DirectAccess — взаимная проверка подлинности средствами служб Certificate Services инфраструктуры открытых ключей (PKI). Добавьте роль Active Directory Certificate Services (ADCS) и службу роли Certification Authority (CA) на имеющийся сервер, например на контроллер домена. Настройте его как корневой CA и создайте новый закрытый ключ, оставив все остальные параметры со значениями по умолчанию.

Далее надо создать шаблон сертификата веб-сервера. В консоли Server Manager перейдите к роли ADCS и щелкните Certificate Templates. Щелкните правой кнопкой Web server template и выберите Duplicate Template.

Создайте шаблон Windows Server 2008 Enterprise и откройте консоль свойств. На вкладке Request Handling выберите Allow private key to be exported. На вкладке Security предоставьте группам Domain Computers и Authenticated Users разрешения Read и Enroll. Выйдите из консоли Properties и щелкните правой кнопкой только что созданный шаблон. Выберите Change Names и задайте шаблону понятное имя.

Добавьте шаблон в папку CA Certificate Templates, для чего щелкните правой кнопкой папку и выберите New/Certificate Template to Issue. Выберите и выпустите только что созданный шаблон.

Шаг 4. Установите список CRL на сервере DirectAccess

Используемому инфраструктурой PKI сертификату нужен доступ к списку CRL. Список содержит перечень отозванных сертификатов, которые стали недействительными. Вы должны иметь доступ к списку CRL как из Интернета, так и из интрасети, поэтому ваш сервер DirectAccess как нельзя лучше подходит для их размещения.

Начните с установки роли IIS с составом служб ролей по умолчанию. В диспетчере IIS Manager создайте новую виртуальную папку по имени CRLD, которая «смотрит» на папку C:inetpubwwwrootcrld. Включите функцию Directory Browsing на странице свойств виртуальной папки.

Далее создайте общую папку C:inetpubwwwrootcrld под именем CRLD$. Предоставьте учетной записи компьютера CA разрешение Full Control для доступа к этой общей папке.

Вернитесь на страницу свойств виртуального каталога, выберите Configuration Editor и перейдите к system.webserver/security/request Filtering. Присвойте параметру Double Escaping значение True.

Далее создайте путь для клиентов, которые будут выполнять разрешение для обнаружения CRL как из внутренних, так и внешних сетей. Вернитесь на контроллер домена, откройте консоль Certification Authority и щелкните правой кнопкой корневой узел консоли и откройте окно свойств сервера CA. На вкладке Extensions выберите расширение CRL Distribution Point (CDP). Щелкните Add и введите внешний адрес, которые внешние клиенты будут использовать для получения списка CRL.

Я использую такой адрес: http://crl.company.com/crld/ .crl. Ваш адрес будет похожим за исключением полного имени сервера. Установите все флажки в нижней части страницы. Снова щелкните Add, чтобы создать подключение для внутренних клиентов. Введите путь UNC, которые внутренние клиенты могут использовать для доступа к CRL.

Мой путь таков: \crl.company.internalcrld$ .crl. Так как это внутреннее подключение к сети, где опубликован список CRL, нужно установить флажки Publish CRLs и Publish Delta CRLs.

Вернитесь в консоль CA, щелкните правой кнопкой Revoked Certificates и последовательно выберите All Tasks/ Publish. Если вы все сделали правильно, вы должны увидеть в общей папке два файла списков CRL.

Шаг 5. Установка сертификатов на серверах DirectAccess и сетевых расположений

Ранее вы уже создали шаблоны сертификатов. Теперь время создать сами сертификаты. Серверу DirectAccess и соответствующему серверу сетевых расположений для взаимной проверки подлинности требуются сертификаты веб-сервара.

Откройте MMC-консоль Certificates на сервере DirectAccess и перейдите к хранилищу Certificates/Personal. Щелкните правой кнопкой Certificates и последовательно выберите All Tasks/Request New Certificate. В консоли Certificate Enrollment выберите сертификат, созданный на шаге 3.

Откроется ссылка с предложением ввести дополнительную информацию для запроса сертификата. Щелкните ссылку и в открывшемся окне выберите вкладку Subject. Задайте общее имя и альтернативное имя DNS. Последнее представляет собой внешнее полное внешнее имя вашего сервера DirectAccess (например, у меня это имя directaccess.company.com). Последовательно щелкните OK и Enroll, чтобы отправить заявку на сертификат.

Сервер сетевых расположений (NLS) является внутренним сервером, на котором установлена роль IIS. NLS не нужно много ресурсов, поэтому его без опаски можно установить на существующем сервере. В таком же порядке установите созданный на шаге 3 сертификат на сервере NLS. Однако на этот раз есть небольшая разница. Вместо внутреннего полного имени сервера DirectAccess надо указать полное имя, разрешаемое в локальной сети.

В моем случае это имя nls.company.internal, которое я добавил в DNS как CNAME, в котором указал реальное имя сервера NLS. DirectAccess общается в NLS по протоколу HTTPS, поэтому надо создать привязку HTTPS к этому CNAME на веб-сайте по умолчанию.

Шаг 6. Подготовка клиентов средствами групповых политик

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

В консоли Group Policy Management Editor перейдие к узлу Computer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/Windows Firewall with Advanced Security. Создайте новое правило входящих подключений. Выберите правило типа Custom для All programs, в поле Protocol выберите ICMPv6, а в поле Echo request — конкретный тип ICMP.

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

Можно создать еще одну конфигурацию клиентов в том же или новом объекте групповой политики (GPO). На этот раз в редакторе групповых политик перейдите к узлу Computer Configuration/Policies/Windows Settings/Security Settings/Public Key Policies и просмотрите свойства политики Certificate Services Client – Auto-Enrollment. В Configuration Model установите флажок Enabled, а также установите два флажка, которые станут доступными. Щелкните ОК.

Последний параметр групповой политики вы найдете в узле Public Key Policies/Automatic Certificate Request Settings. Щелкните его правой кнопкой и выберите New/Automatic Certificate Request. Откроется окно мастера настройки автоматического запроса сертификатов (Automatic Certificate Request Setup Wizard). Он позволяет задать типы сертификатов, которые компьютер будет запрашивать автоматически. Выберите шаблон Computer и пройдите мастер.

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

Шаг 7. Подготовка доменных служб

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

Во-вторых, надо изменить настройку DHCP-сервера. Если в вашей среде не реализован протокол IPv6, измените настройку DHCP-сервера — отключите на сервере режим DHCPv6 без отслеживания состояния.

В-третьих надо изменить DNS. В некоторых случаях для работы DirectAccess требуется протокол ISATAP (Intra-Site Automatic Tunneling Address Protocol). Этот протокол обычно входит в глобальный список блокировки на DNS-сервере, поэтому ISATAP над удалить из этого списка. Для этого в редакторе реестра на каждом DNS-сервере перейдите узлу HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDNSParameters и удалите запись ISATAP. После этого надо перезапустить службы.

Читать еще:  Vba закрыть access

Шаг 8. Установка DirectAccess

Теперь мы готовы устанавливать DirectAccess. Эта операция выполняется средствами диспетчера сервера (Server Manager). После установки откройте консоль DirectAccess и перейдите к узлу Setup. Настройка DirectAccess состоит из четырех шагов:

  1. Задайте глобальную группу, содержащую учетные записи компьютеров, которым надо предоставить внешний доступ.
  2. Укажите сетевые интерфейсы Интернета и внутренней сети, а также сервер CA и внешний сервер сертификатов. Это просто, если вы переименовали интерфейсы и сертификаты, задав им легкие для запоминания имена.
  3. Укажите инфраструктурные серверы, которые могут взаимодействовать с внешними клиентами. Здесь надо указать URL-адрес сервера NLS, а также имя и параметры IPv6 сервер DNS, контроллера домена и любых других серверов, которые вы используете для управления клиентами, например серверов WSUS или System Center. На всех серверах должна быть включена поддержка IPv6.
  4. Завершите конфигурирование, указав все остальные серверы, к которым надо предоставить доступ внешним клиентам. Это серверы, обслуживающие клиентские приложения.

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

Разворачиваем DirectAccess на базе Windows Server 2012 R2

В этой статье мы пошагово опишем процедуру разворачивания службы удаленного доступа Direct Access на самой свежей серверной платформе Microsoft — Windows Server 2012 R2. Вообще говоря, служба Direct Access предполагает несколько сценариев работы, мы попытаемся рассмотреть наиболее общий сценарий организации сервиса DirectAccess.

Прежде чем приступить, вкратце напомним о том, что такое служба DirectAccess. Компонент DirectAccess впервые была представлена Micrisoft в Windows Server 2008 R2 и предназначался для организации прозрачного доступа удаленных компьютеров ко внутренним ресурсам сети компании. При подключении через DA пользователь может полноценно пользоваться корпоративными и доменными сервисами, а сотрудники ИТ-поддержки управлять таким компьютеров и поддерживать его актуальном с точки зрения безопасности состоянии. По своей сути DirectAccess во многом напоминает традиционное VPN подключение к корпоративной сети. Рассмотрим основные отличия DirectAccess от VPN:

  • Для установки соединения с помощью DirectAccess пользователю не нужно запускать VPN клиент – подключение осуществляется автоматически при наличия доступа в Интернет
  • Для организации соединения между клиентом DA и сервером нужно открыть только 443 порт
  • Компьютер пользователя обязательно должен находится в домене AD, а это значит что на него действуют все доменные групповые политики (конечно есть трюки, позволяющие запускать VPN до входа в Windows, но это обычно практически не практикуется)
  • Канал связи между удаленным ПК и корпоративным шлюзом шифруется стойкими алгоритмами с использованием IPsec
  • Возможно организовать двухфакторную аутентификацию с использованием системы одноразовых паролей

В чем же основные отличия версии DirectAccess в Windows Server 2012 / 2012 R2 от версии Windows 2008 R2. Основное отличие – снижение требований к смежной инфраструктуре. Так, например:

  • Сервер DirectAccess теперь не обязательно должен быть пограничным, теперь он может находиться за NAT.
  • В том случае, если в качестве удаленных клиентов используется Windows 8 Enterprise, разворачивать внутреннюю инфраструктуру PKI не обязательно (за аутентификацию клиентов будет отвечать Kerberos-прокси, расположенный на сервере DA)
  • Не обязательно стало наличие IPv6 во внутренней сети организации
  • Поддержка OTP (One Time Password) и NAP (Network Access Protection) без необходимости развёртывания UAG

Требования и инфраструктура, необходимы для развертывания DirectAccess на базе Windows Server 2012 R2

  • Домен Active Directory и права администратора домена
  • Выделенный (рекомендуется) сервер DA под управлением Windows Server 2012 R2, включенный в домен Windows. Сервер имеет 2 сетевые карты: одна находится во внутренней корпоративной сети, другая – в DMZ сети
  • Выделенная DMZ подсеть
  • Внешнее DNS имя (реальное или через DynDNS) или IP адрес, доступный из интернета, к которому будут подключатся клиенты DirectAccess
  • Настроить перенаправление трафика с порта TCP 443 на адрес сервера DA
  • Развернутая инфраструктура PKI для выпуска сертификатов. В certificate authority нужно опубликовать шаблон сертификата Web Server и разрешено его автоматическое получение (auto-enrollmen) (Если в качестве клиентов будут использоваться только Windows 8 — PKI не обязателен).
  • В качестве клиентов могут выступать компьютеры с Windows 7 и Windows 8.x редакций Professional / Enterprise
  • Группа AD, в которой будут состоять компьютеры, которым разрешено подключаться к сети через Direct Access (допустим, эта группа будет называться DirectAccessComputers)

Установка роли Remote Access

Запустим консоль Server Manager и с помощью мастера Add Roles and Features установим роль Remote Access.

В составе роли Remote Access нужно установить службу DirectAccess and VPN (RAS).

Все остальные зависимости оставляем по умолчанию.

Настройка службы Direct Access в Windows Server 2012 R2

После окончания установки службы Remote Access, откройте оснастку Tools -> Remote Access Management.

Запустится мастер настройки роли удаленного доступа. Укажем, что нам нужно установить только роль DA — Deploy DirectAccess only.

После этого должно открыться окно, в правой половине которого в графическом виде показаны четыре этапа (Step 1 – 4) настройки службы DA.

Первый этап (Step 1: Remote Clients).

Укажем, что мы разворачиваем полноценный DirectAccess сервер с возможностью доступа клиентов и их удаленного управления Deploy full DirectAccess for client access and remote management.

Далее, нажав кнопкуAdd нужно указать группы безопасности AD, в которой будут находиться учетные записи компьютеров, которым разрешено подключаться к корпоративной сети через Direct Access (в нашем примере это группа DirectAccessComputers).

Следующий шаг – нужно указать список внутренних сетевых имен или URL-адресов, с помощью которых клиент может проверить (Ping или HTTP запрос), что он подключен к корпоративной сети. Здесь же можно указать контактный email службы helpdesk и наименование подключения DirectAccess (так оно будет отображаться в сетевых подключениях на клиенте). В случае необходимости можно включить опцию Allow DirectAccess clients to use local name resolution, позволяющую разрешить клиенту использовать внутренние DNS-сервера компании (адреса DNS серверов могут получаться по DHCP).

Второй этап (Step 2: Remote Access Server)

Следующий шаг — настройка сервера Remote Access. Указываем, что наш сервер удаленного доступа представляет собой конфигурацию с двумя сетевыми картами — Behind an edge device (with two network adapters), одна их которых находится в корпоративной сети, а вторая подключена напрямую в Internet или DMZ-подсеть. Здесь же нужно указать внешнее DNS имя или IP адрес в Интернете (именно с этого адреса пробрасывается 443 порт на внешний интерфейс сервера DirectAccess), к которому должны подключаться клиенты DA.

Затем нужно указать какая сетевая карта будет считаться внутренней (Internal – LAN), а какая внешней (External – DMZ).

Свернем пока мастер настройки сервера Direct Access и сгенерируем сертификат сервера DA. Для этого создадим новую оснастку mmc, в которую добавим консоль Certificates, управляющую сертификатами локального компьютера (Computer Account)

В консоли управления сертификатами запросим новый персональный сертификат, щелкнув ПКМ по разделу Certificates (Local Computer) -> Personal -> Certificates и выбрав в меню All Tasks-> Request New Certificate

Запросим сертификат через политику Active Directory Enrollment Policy. Нас интересует сертификат на основе шаблона WebServers.

В настройках запроса нового сертификата на вкладке Subject заполним поля, идентифицирующие нашу компанию, а на вкладке Private Key укажем, что закрытый ключ сертификата можно экспортировать (Make private key exportable).

Сохраним изменения и запросим новый сертификат у CA.

Вернемся в окно настроек сервера DirectAccess и, нажав кнопку Browse, выберем сгенерированный сертификат.

На следующем шаге мастера выберем способ аутентификации клиентов Direct Access. Укажем, что используется аутентификация по логину и паролю AD (Active Directory credentials – username/password). Отметим чекбокс Use computer certificates (Использовать сертификаты компьютеров) и Use an intermediate certificate. Нажав кнопку Browse, нужно указать центр сертификации, который будет отвечать за выдачу сертификатов клиентов.

Третий этап (Step 3: Infrastructure Servers)

Третий этап – настройка инфраструктурных серверов. Нам будет предложено указать адрес сервера Network Location Server, находящегося внутри корпоративной сети. Network Location Server — это сервер, с помощью которого клиент может определить, что он находится во внутренней сети организации, т.е. не требуется использовать DA для подключения. NLS – сервером может быт любой внутренний веб-сервер (даже с дефолтной страничкой IIS), основное требование – сервер NLS не должен быть доступен снаружи корпоративной сети.

Далее укажем список DNS серверов для разрешения имен клиентами. Рекомендуется оставить опцию Use local name resolution if the name does not exist in DNS or DNS servers are unreachable when the client computer is on a private network (recommended).

Затем укажем DNS-суффиксы внутренних доменов в порядке приоритета их использования.

В окне настройки Management ничего указывать не будем.

Четвертый этап (Step 4: Application Servers)

Этап настройки серверов приложений. На этом этапе можно настроить дополнительную аутентификацию и шифрование трафика между внутренними серверами приложений и клиентами DA. Нам это не требуется, поэтому оставим опцию Do not extend authentication to application servers.

На этом мастер настройки роли Remote Access завершен, нам осталось сохранить изменения.

После окончания работы мастер создаст две новых групповых политик DirectAccess Client Settings и DirectAcess Server Settings, которые прикреплены к корню домена. Их можно оставить там, либо перелинковать на нужный OU.

Тестируем работу Direct Access на клиенте Windows 8

Чтобы протестировать работу Direct Access с клиента, добавим это компьютер (напомним, что это должен быть ПК с Windows 8.X Enterprise ) в группу DirecAccessCompurers, обновим на нем групповые политики (gpupdate /force).

Отключаем тесовую машину от корпоративной сети и подключаемся в интернету через Wi-Fi. Система автоматически подключается к корпоративной сети через DirectAccess, о чем свидетельствует статус Connected значка Workplace Connection (именно так мы назвали наше подключение при настройке сервера) в списке сетей.

Читать еще:  Функция avg в access

Наличие подключения к сети через DirectAccess можно проверить с помощью PowerShell команды:

Если она возвращает ConnectedRemotely, значит подключение DA к корпоративной сети

Настройка direct access

Вопрос

В данный момент разбираю тему DirectAccess по материалам экзамена 70-411.

Сделал как по инструкции, а именно:

3 виртуальные машины на Hyper-V:

LSN-PC-001 — Win2012, AD, DNS, DHCP

LSN-PC-002 — Win2012, DirectAccess

LSN-PC-003 — Windows 8.1

Network: vSwitch — «Corp» (internal), «Internet» (internet)

IPv4 192.168.6.1/24, IPv6 on — «Corp»

IPv 192.168.6.10/24, IPv6 on — «Corp»

IPv 131.107.0.10/24, IPv6 on — «Internet»

IPv 192.168.6.12/24, IPv6 on — «Corp»

IPv 131.107.0.20/24, IPv6 on — «Internet»

Настроил DirectAccess в режиме «пограничный» с внешним IPv4-адресом 131.107.0.10. Конфигурация удачно настроилась, без ошибок. GPO удачно применилось на сервере и клиенте.

После подключения клиента к vSwitch «Internet» (и отключения «Corp») не получаю доступ к \LSN-PC-001.TEST3.LAN. Просмотрел много видео и статей. Не смог найти решение. ((

  • Изменено Xudojnik 18 сентября 2015 г. 22:49

Ответы

Direct Access работает только в КорпоративнойEnterprise редакции Windows (для 7-ки ещё и Ultimate)

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

Windows 10® Enterprise
Windows 10® Enterprise 2015 Long Term Servicing Branch (LTSB)
Windows® 8 Enterprise
Windows® 7 Ultimate
Windows® 7 Enterprise

  • Помечено в качестве ответа Xudojnik 20 сентября 2015 г. 9:36

Все ответы

IPv 192.168.6.12/24, IPv6 on — «Corp»

IPv 131.107.0.20/24, IPv6 on — «Internet»

Настроил DirectAccess в режиме «пограничный» с внешним IPv4-адресом 131.107.0.10. Конфигурация удачно настроилась, без ошибок. GPO удачно применилось на сервере и клиенте.

После подключения клиента к vSwitch «Internet» (и отключения «Corp») не получаю доступ к \LSN-PC-001.TEST3.LAN. Просмотрел много видео и статей. Не смог найти решение. ((

а зачем клиенту вообще изначально две сетевые назначены? и по какой инструкции вы делали?

посмотрите эту статью. а так же офлайн подлючение клиента к Direct Access серверу.

и вот ещё статья, если решите убрать DA сервер за NAT.

  • Изменено Anahaym 19 сентября 2015 г. 0:35

Клиенту нужны 2 сетевые платы для симуляции подключения то к корпоративной сети «Corp», то к «Internet», с учетом того, что обе платы не включаются одновременно.

Инструкцией служит «Official Microsoft Learning Product 20411D Administering Windows Server 2012» Module 8 Lab A Implementing DirectAccess by Using the getting Started Wizard

эту статью прочитал, делал так же, за исключением того, что использовал самозаверяющий сертификат, создаваемый мастером настройки (как в инструкции).Кстати, хочу заметить у меня не создается т.н. «Подключение к рабочему месту» — соединение необходимое для подключения клиента к DA.

Скорее всего, какая-то мелочь, которую я не могу найти. Мне нужна просто помощь в диагностике. Несколько раз сносил и заново ставил конфигурацию DA, все то же. ((

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

Мне нужна просто помощь в диагностике.

gpresult /R на клиенте покажет какие групповые политики применились к клиенту

кстати, 8.1 — корпоративная установлена на клиенте?

  • Изменено Anahaym 19 сентября 2015 г. 13:21

Да, можно использовать и одну плату, естественно. Но тогда придется вручную менять адрес интерфейса при подключению к «Internet» и наоборот. Ваш вариант просто альтернативный.

gpresult /R — как писал выше GPO удачно применились. Прилагаю для информации:

Программа формирования отчета групповой политики операционной системы
Microsoft (R) Windows (R) версии 2.0
c Корпорация Майкрософт, 2012. Все права защищены.

Создано 19.09.2015 в 20:21:10

Конфигурация ОС: Рядовая рабочая станция
Версия ОС: 6.2.9200
Имя сайта: Default-First-Site-Name
Перемещаемый профиль: Н/Д
Локальный профиль: C:UsersAdministrator
Подключение по медленному каналу: Нет

Конфигурация компьютера
————————
CN=LSN-PC-003,CN=Computers,DC=TEST3,DC=LAN
Последнее применение групповой политики: 19.09.2015 в 19:26:54
Групповая политика была применена с: LSN-PC-001.TEST3.LAN
Порог медленного канала для групповой политики: 500 kbps
Имя домена: TEST3
Тип домена: Windows 2008 или более поздняя версия

Примененные объекты групповой политики
—————————————
Параметры клиента DirectAccess
Default Domain Policy

Следующие политики GPO не были применены, так как они отфильтрованы
———————————————————————
Local Group Policy
Фильтрация: Не применяется (пусто)

Параметры сервера DirectAccess
Фильтрация: Отказано (безопасность)

Компьютер является членом следующих групп безопасности
——————————————————
Администраторы
Все
Пользователи
СЕТЬ
Прошедшие проверку
Данная организация
LSN-PC-003$
DA_Clients
Domain Computers
Подтвержденное центром проверки подлинности удостоверение
Обязательный уровень системы

Конфигурация пользователя
—————————
CN=Administrator,CN=Users,DC=TEST3,DC=LAN
Последнее применение групповой политики: 19.09.2015 в 18:56:58
Групповая политика была применена с: LSN-PC-001.TEST3.LAN
Порог медленного канала для групповой политики: 500 kbps
Имя домена: TEST3
Тип домена: Windows 2008 или более поздняя версия

Следующие политики GPO не были применены, так как они отфильтрованы
———————————————————————
Параметры клиента DirectAccess
Фильтрация: Отключено (GPO)

Default Domain Policy
Фильтрация: Не применяется (пусто)

Local Group Policy
Фильтрация: Не применяется (пусто)

Параметры сервера DirectAccess
Фильтрация: Отключено (GPO)

Пользователь является членом следующих групп безопасности
———————————————————
Domain Users
Все
Пользователи
Администраторы
ИНТЕРАКТИВНЫЕ
КОНСОЛЬНЫЙ ВХОД
Прошедшие проверку
Данная организация
ЛОКАЛЬНЫЕ
Domain Admins
Group Policy Creator Owners
Schema Admins
Enterprise Admins
Подтвержденное центром проверки подлинности удостоверение
Denied RODC Password Replication Group
Высокий обязательный уровень

7 шагов диагностики клиентов DirectAccess

DirectAccess является новой технологией удаленного доступа от Microsoft, позволяющей всегда быть подключенным к сети компании независимо от места нахождения. К тому же, DirectAccess позволяет ИТ персоналу предприятия всегда быть подключенным к управляемым ими активам, чтобы иметь постоянную возможность управления этими активами, содержать их в актуальном состоянии, обеспечивать их соответствие и всегда держать их под контролем сотрудников ИТ отдела предприятия. DirectAccess обеспечивается сочетанием Windows 7 и Windows Server 2008 R2, и становится еще мощнее, если добавить в эту конфигурацию продукт Unified Access Gateway (UAG) 2010. Хотя работа DirectAccess возможна без UAG, без данного продукта это решение не является жизнеспособным, готовым к работе на предприятиях решением.

Я использую DirectAccess уже достаточно длительное время и не знаю, чтобы я делала без него. Очень удобно иметь постоянное подключение. Мне не нужно думать о запуске VPN подключений, не нужно беспокоиться о том, будет ли работать мое VPN подключение, и не нужно иметь дела с ужасными веб-приложениями, которые доступны через SSL VPN шлюз. Благодаря DirectAccess я могу использовать свои всевозможные приложения для настольных компьютеров на своем клиенте для выполнения качественной работы без необходимости задумываться о подключении. Я просто всегда подключена. С точки зрения пользователя – это мечта, ставшая реальностью.

Однако, администраторам, возможно, придется диагностировать DirectAccess подключения от случая к случаю. Хотя DirectAccess подключения весьма надежны, в мире нет ничего идеального, и могут возникать ситуации, когда клиенты не могут подключиться, в результате чего вам придется определять причины проблемы. Именно это мы и будем обсуждать в этой статье: некоторые основные шаги, которые можно предпринять для диагностики подключений DirectAccess клиентов.

Основываясь на документации Microsoft и своем собственном опыте проб и ошибок, предлагаю вам свой план из семи шагов по диагностике подключения DirectAccess клиентов:

  • Проверить, что клиенты DirectAccess получили свои параметры групповой политики
  • Проверить, что клиент знает, что он находится не в интрасети
  • Проверить NRPT параметры на DirectAccess клиенте
  • Проверить IPv6 адрес на DirectAccess клиенте
  • Убедиться в наличии проверки подлинности для DirectAccess туннелей
  • Проверить работоспособность подключения к DNS и контроллерам домена

А теперь давайте рассмотрим каждый шаг более подробно.

Проверка параметров групповой политики

DirectAccess клиенты получают свои клиентские параметры через групповую политику. Если групповая политика не применена к DirectAccess клиенту, он не сможет работать в качестве DirectAccess клиента. Есть множество способов проверки параметров групповой политики на DirectAccess клиенте, но моим любимым является проверка брандмауэра Windows на наличие правил безопасности подключений (Connection Security Rules), которые DirectAccess клиенты используют для подключения к UAG DirectAccess серверу. Эти правила назначаются групповой политикой, поэтому если они есть, то групповая политика применена.

Можно ввести wf.msc в строку поиска на машине Windows 7, чтобы открыть консоль брандмауэра Windows Firewall with Advanced Security. В левой панели консоли нажмите на разделе Правила безопасности подключения (Connection Security Rules).

Если вы видите три правила, показанных на рисунке 1: UAG DirectAccess Client ‘ Clients Access Enabling Tunnel ‘ All, UAG DirectAccess Clients ‘ Clients Corp Tunnel и UAG DirectAccess Clients ‘ Example NLA, то можете быть уверены, что групповая политика применена.

Проверка того, что клиент знает, что он находится не в интрасети

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

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

netshdns show state

Эта команда должна вернуть результат, похожий на рисунок 2 ниже.

Как показано на рисунке, расположение машины обозначено как Вне корпоративной сети (Outside corporate network). Если бы машина сообщила о том, что она находится в пределах корпоративной сети, когда на самом деле это не так, то вам пришлось бы искать причину такого сообщения. А если машина, находясь в корпоративной сети, сообщает о том, что она находится за ее пределами, также придется искать причину этого. Во втором случае неисправность, скорее всего, в проблеме подключения к серверу сетевых расположений (Network Location Server — NLS).

Проверка параметров таблицы политики разрешения имен на клиенте DirectAccess

Таблица политики разрешения имен (Name Resolution Policy Table — NRPT) используется клиентом DirectAccess для определения того, какой DNS сервер должен использоваться для разрешения имени. Когда DirectAccess клиент находится во внутренней сети, NRPT отключена, и единственным DNS сервером, используемым клиентом, является DNS сервер, настроенный на его сетевой карте. Однако когда DirectAccess клиент находится за пределами корпоративной сети, NRPT включается и используется для определения того, какой DNS сервер будет использоваться для разрешения имен в зависимости от имени, которое нужно разрешить.

Читать еще:  System unauthorized access

Параметры таблицы NRPT можно посмотреть с помощью следующей команды:

netsh namespace show effectivepolicy

На рисунке 3 видно, что все имена в домене corp.contoso.com будут отправляться на DNS сервер по адресу 2002:836b:3::836b:3, а это 6to4 адрес на сервере UAG DirectAccess. Сервер UAG DirectAccess используется в качестве DNS сервера, так как UAG DirectAccess использует DNS64 в качестве DNS прокси для клиентов DirectAccess. Обратите внимание, что имя nls.corp.contoso.com не имеет адреса DNS сервера в списке, поскольку оно представляет собой исключение из серверов в corp.contoso.com собрании. Причина в том, что вам не нужно, чтобы клиент DirectAccess подключался к NLS, находясь за пределами корпоративной сети, поскольку клиент DirectAccess использует подключение к NLS для определения того, когда он находится в корпоративной сети!

Проверка IPv6 адресов на клиенте DirectAccess

DirectAccess клиенты используют IPv6 для взаимодействия с DirectAccess сервером. Это всегда так. Клиент DirectAccess может также использовать IPv6 для взаимодействия с ресурсами в интрасети. Это будет так, если ресурсы интрасети поддерживают IPv6. Однако если ресурс интрасети не поддерживает IPv6, то UAG DirectAccess сервер будет использовать NAT64/DNS64 для перевода IPv6 сообщений с DirectAccess клиента IPv4 ресурсу в интрасети. Очень важно понимать, что DirectAccess клиент всегда использует IPv6 при подключении к UAG DirectAccess серверу.

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

Вы можете определить то, какая технология туннелирования IPv6 используется, запустив команду ipconfig /all.

На рисунке 4 выше видно, что Tunnel adapter 6TO4 Adapter используется для подключения к UAG DirectAccess серверу и что для него назначен IP адрес и основной шлюз. Основной шлюз – это 6to4 адрес UAG DirectAccess сервера.

При диагностике DirectAccess клиента необходимо убедиться в том, что для него имеется IPv6 адрес. Если нет IPv6 адреса, это указывает на то, что есть проблемы в настройке IPv6 на клиенте и внимание нужно уделить этому аспекту. Могут также возникать проблемы с подключением к UAG DirectAccess серверу, поэтому нужно обязательно выполнить пинг IPv6 адреса сервера UAG, такого адреса IPv6, который указан в строке основного шлюза адаптера 6to4.

Проверка аутентификации клиента DirectAccess

Когда клиент DirectAccess подключается к UAG DirectAccess серверу, он использует IPsec туннели для обеспечения подключения к корпоративной сети. Здесь используется два туннеля:

  • Туннель инфраструктуры (Infrastructure Tunnel) ‘ это туннель, создаваемый до входа пользователя с помощью сертификата компьютера и учетной записи пользователя компьютера в Active Directory, а также с помощью проверки подлинности NTLMv2. Используется два способа проверки подлинности для создания первого туннеля, и клиент DirectAccess может получить доступ только к определенному количеству компьютеров через туннель инфраструктуры.
  • Туннель интрасети (Intranet Tunnel) ‘ этот туннель создается после создания туннеля инфраструктуры, поскольку туннель инфраструктуры необходим для предоставления доступа к контроллерам домена для проверки подлинности Kerberos. Туннель интрасети использует проверку подлинности на основе сертификата компьютера и на основе учетной записи вошедшего пользователя (Kerberos) для создания второго туннеля. Туннель интрасети позволяет пользователю подключаться к остальной части сети.

Вопрос заключается в следующем: как узнать, какой способ проверки подлинности используется и что не/работает? Одним из способов сделать это является использование консоли брандмауэра Windows Firewall with Advanced Security. Разверните раздел Наблюдение (Monitoring), затем разверните раздел Сопоставления безопасности (Security Associations) и нажмите на разделе Основной режим (Main Mode). Здесь вы видите сопоставления безопасности в основном режиме для туннелей инфраструктуры и интрасети, как показано на рисунке 5. Обратите внимание, что в разделе Второй способ проверки подлинности (2nd Authentication Method) есть подключения, использующие NLTMv2 и Kerberos V5. NTLM используется для проверки подлинности туннеля инфраструктуры, а Kerberos используется туннелем интрасети.

Обычно у вас не должно возникать проблем с NTLM проверкой подлинности. Чаще проблемы возникают с проверкой подлинности Kerberos. Убедитесь, что учетная запись пользователя не отключена и что она использует текущий пароль, а не кэшированный пароль. Обратите внимание, что вы не увидите никаких подключений по туннелю интрасети Kerberos, пока не попытаетесь подключиться к ресурсу, который не входит в состав собрания серверов, определенных как серверы инфраструктуры. Эти соединения проходят через туннель инфраструктуры с NTLM проверкой подлинности.

Проверка подключения к DNS серверам и контроллерам домена

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

Например, можно выполнить следующую команду:

и вы получите результат подобный тому, что показан на рисунке 6 ниже. Здесь показано, что клиент DirectAccess смог подключиться к контроллеру домена, а также предоставлена информация о IPv6 адресе контроллера домена. Следует отметить, что если контроллер домена не имеет IPv6 адрес, вы все равно увидите здесь IPv6 адрес, но это будет NAT64 адрес.

Вы легко можете проверить разрешение имен с помощью пинга, как показано на рисунке 7 ниже.

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

Заключение

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

Установка роли Remote Access и настройка службы Direct Access

Запустить консоль Диспетчер сервера и с помощью мастера добавления роли и компонентов установить роль Удаленного доступа.

В составе роли Remote Access нужно установить службу DirectAccess and VPN (RAS) и Routing(маршрутизация).

После окончания установки службы Remote Access, открыть оснастку инструменты — менеджер удаленного доступа.

Запустится мастер настройки роли удаленного доступа. Указать, что нужно установить только роль DA — развертывание DirectAccess и VPN.

После этого должно открыться окно, в правой половине которого в графическом виде п

Чтобы создать SSL сертификат в центре сертификации необходимо подправить шаблон Веб-Сервер так, чтобы учетная запись WSE обладала правами “чтение” и “выпуск”, для этого выбрать управление, выбрав шаблон перейти в свойствабезопасность,добавить учетную запись сервера WSE,разрешить чтение и подачу заявки. Необходимо добавить сертификат для компьютера, в разделе личное создать

Сохранить изменения и запросить новый сертификат .Вернуться в окно настроек сервера DirectAccess и, нажав кнопку Просмотреть, выбрать сгенерированный сертификат(Рисунок 18)

Рисунок 18. редактирование шаблона

Первый этап

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

Рисунок 19. Выбор групп

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

Опция Использовать принудительное туннелирование – означает, что удаленные клиенты при доступе к любым удаленным ресурсам (в том числе обычным веб-сайтам) всегда использовать сервера DA (т.е. весь внешний трафик клиента проходит через корпоративный шлюз). Следующий шаг – указать список внутренних сетевых имен или URL-адресов, с помощью которых клиент может проверить (Ping или HTTP запрос), что он подключен к корпоративной сети. Здесь же можно указать контактный email службы helpdesk и наименование подключения DirectAccess (так оно будет отображаться в сетевых подключениях на клиенте.(Рисунок 20) В случае необходимос

Рисунок 20. Ресурс необходимый для подключения к внутренней сети

Второй этап —настройка сервера удаленного доступа. Указать, что сервер удаленного доступа представляет собой конфигурацию с одной сетевой картой, которая находится в корпоративной сети. Нужно указать внешнее DNS имя или IP адрес в Интернете (именно с этого адреса пробрасывается 443 порт на внешний интерфейс сервера DirectAccess), к которому должны подключаться клиенты DA.(Рисунок 21)

Рисунок 21. Выбо

.

Рисунок 22. Сертификат

На следующем шаге мастера выбрать способ аутентификации клиентов Direct Access. Указать, что используется аутентификация по логину и паролю AD (Active Directory credentials – username/password). Отметить использовать сертификаты компьютеров и использовать данный сертификат. Нажав кнопку просмотреть, нужно указать центр сертификации, который будет отвечать за выдачу сертификатов клиентов(Рисунок 22).

Третий

Сервер сетевой инфраструктуры — это сервер, с помощью которого клиент может определить, что он находится во внутренней сети организации, т.е. не требуется использовать DA для подключения. NLS – сервером может быть любой внутренний веб-сервер, основное требование – сервер NLS не должен быть доступен снаружи корпоративной сети. Далее указать список DNS серверов для разрешения имен клиентами. Рекомендуется оставить опцию Использовать локальное разрешение имен, если имя не существует в DNS или DNS-серверы недоступны для клиентского компьютера, находящегося в частной сети).Затем указать DNS-суффиксы внутренних доменов в порядке приоритета их использования. В окне настройки управления ничего указывать не требуется.

Четвертый этап — настройка серверов приложений. На этом этапе можно настроить дополнительную аутентификацию и шифрование трафика между внутренними серверами приложений и клиентами DA. Выбрать опцию Не использовать сквозную проверку подлинности для выбранных серверов-приложений.На этом мастер настройки роли Remote Access завершен, необходмо сохранить изменения. (Рисунок 23)

Рисунок 23. Состояние работы DirectAccess

Ссылка на основную публикацию
Adblock
detector