Главная Networks, Security, Windows, Без рубрики, Новое Microsoft DirectAccess 2012: DirectAccess и Windows 8
  • Microsoft DirectAccess 2012: DirectAccess и Windows 8

    ed31_earth_in_my_room

    В прошлой статье я постарался в понятной форме рассказать о технологии DirectAccess, о ее плюсах и минусах. Теперь, как и обещал, расскажу о том, каким образом настроить сервер DirectAccess в базовой конфигурации для работы только с клиентами Windows 8. Что значит в базовой конфигурации? Это когда у вас есть Windows Server 2012 на котором будет поднята роль для DirectAccess и  клиенты (с операционной системой Windows 8 Enterprise) имеющие  прямое подключение к интернету . В базовой конфигурации не будет использоваться инфраструктура открытых ключей (PKI) и  используется только одна входная точка (сервер DirectAccess), подключенная в одном сайте Active Directory. Так же в базовую конфигурацию не могут входить дополнительные опции, такие как двухфакторная аутентификация (OTP Auth), проверка доступа к сети (NAP). Ну и самое важное – в ней не могут использоваться клиенты Windows 7.

     

    Что потребуется для внедрения DirectAccess в базовой конфигурации:

     

    • Один сервер (можно виртуальный) с Windows Server 2012 (любая редакция)
    • Сервер введен в домен
    • Сервер находится за NAT (для подключения требуется только один сетевой адаптер)
    • Требуется проброс 443 (HTTPS) порта на сервер DirectAccess
    • На клиентах Direct Access установлена  Windows 8 Enterprise

     

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

     

    1. Для начала нам следует создать группу безопасности в Active Directory с именем DA_Clients_Win8 (название группы можете сменить), такое название мы взяли, что бы показать, что здесь будут находиться компьютеры с Windows 8. Расположение группы в каталоге выберете на свое усмотрение. По такому же принципу создайте еще одну группу DA_Servers. В эту группу мы добавляем объекты «Computer» с установленной Windows 8 Enterprise и сервером с DirectAccess соответственно.

     

     
    2. На сервере Direct Access поднимаем роль «Удаленный доступ»:
     

     

    В «Select features» можно выбрать Group Policy Management, Remote Server Administration Tools и другие, если хотите рулить процессом с самого сервера DirectAccess.

    В «Role Services» оставляем единственный выбор – «DirectAccess and VPN (RAS)»

     

     

    Так же нам требуется служба IIS, для этого соглашаемся со следующими шагами мастера установки.

     

    3. После завершения инсталляции запускам следующий мастер установки.

     

     

    В базовой конфигурации выбираем «Deploy DirectAccess only»

     

     

    Следующий этап – выбрать местоположения DirectAccess сервера относительно топологии сети организации. В этом примере будем использовать конфигурацию «Behind an edge device (with a single network adapter». Так же тут вписываем имя, через которое к нашему серверу подключаются внешние клиенты, в нашем случае – DA.CONTOSO.COM. Во внешней зоне своего домена создаем А-запись DA.CONTOSO.COM разрешающейся во внешний IP-адрес, 443 порт которого мы пробрасываем на сервер DirectAccess.

     

     

    Завершаем мастер настройки, если после применения параметров видим ошибки, не беспокоимся, мы их исправим далее. Но для понимания процесса посмотрите, на что жалуется установщик.

    4. После первоначальной настройки мы видим окно консоли «Remote Access Management Console»

     

     

    Идем в раздел «Configuration» и выбираем Edit на Step 1:

     

     

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

     

     

    На этом этапе выбираем группу, созданную нами ранее, для которой будет доступен DirectAccess, предварительно удалив группу Domain Computers. Снимаем галку «Enable DirectAccess for mobile computers only». Галку «Use force tunneling» оставляю на усмотрение. Если она включена, то абсолютно весь трафик удаленного клиента будет идти через сервер DirectAccess.

     

     

    На этом этапе нам дается возможность назвать подключение по DirectAccess как нам захочется. То, что будет написано в строке DirectAccess connection name будет показываться в списке подключений клиента. Активация галки  Allow DirectAccess clients to use local name resolution позволит клиентам обращаться к плоским именам. Если у клиента дома есть сетевое хранилище с именем NAS (как пример), то набрав данное имя в браузере, DirectAccess будет пытаться найти это имя на DNS-серверах организации и не даст достучаться до домашнего хранилища. Но если клиент указал в свойствах подключения разрешать такие имена локально, то у него получится. Но сначала мы должны разрешить это.

     

    5. Далее редактируем Step 2:

     

     

    Так как мы на первоначальной установке уже указали внешнее имя сервера DirectAccess, то первый этап оставляем без изменений.

     

     

    Второй этап оставляем без изменений. Но стоит заметить, что будет использоваться самоподписанный сертификат. Так же, если несколько сетевых адаптеров на сервере, стоит выбрать адаптер, который смотрит внутрь сети, в нашем случае LAN.

     

     

    На этом этапе мы не можем что-либо изменить, так как мы не используем инфраструктуру открытых ключей (PKI). Любая выставленная галка требует наличия PKI.

     

    6. Редактируем Step 3:

     

    Данный этап оставляем без изменений, система сама выдаст самоподписанный сертификат для имени DirectAccess-NLS.

     

     

    На этом этапе указываются исключения в NRTP (Name Resolution Table Policy), для данного списка будут использоваться DNS-сервера указанные в сетевом интерфейсе клиента. Тут к дефолтным именам можно добавить имена, которые обязательно должны обработаться DNS из настроек TCP/IP сетевого интерфейса клиента, даже если они имеют домен организации, например Lync сервера.

     

     

    Следующий этап оставляем без изменений, если только у вас есть несколько доменных суффиксов.

     

     

    Завершающий шаг так же оставляем без изменений

     

     

    Четвертый шаг в конфигурации нам не нужен. Нажимаем принять конфигурацию и должны получить принятую конфигурацию без ошибок.

     

    7. После принятия конфигурации мы увидим такую картину в разделе «DASHBOARD», это говорит нам о том, что все ок, только политики еще не обновились на самом сервере, так как не были обновлены групповые политики с контролера домена. Перегружаем сервер DirectAccess.

     

     

    Если все нормально загрузилось, должны увидеть все запущенные сервисы:

     

     

    Проверяем групповые политики, мы должны увидеть в корне домена две групповых политик DirectAccess, данные политики можно перенести из корня в нужное организационное подразделение.

     

     

    Обязательно проверить DNS, должны увидеть там записи отмеченные красным

     

     

    На этом базовая настройка сервера закончена. Остался клиент. Если клиент уже введен в домен и физически подключен в сеть организацию, то требуется обновить групповые политики на компьютере через gpupdate /force и перегрузить. После перезагрузки клиент готов к подключению DirectAccess.

    Что бы DirectAccess заработал, надо соблюдать несколько правил:

     

    • Windows Firewall на клиенте должен быть включен
    • Профиль, который для внешнего подключения (не с работы, а дома, например) подключения к сети должен быть не доменный (можно частный или публичный).
    • Групповые политики должны быть применены на клиенте. Проверяем: gpresult /r /scope:computer и ищем имена групповых политик DirectAccess и проверяем принадлежность к группе безопасности.

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

    Так же можно воспользоваться PowerShell командной Get-DAConnectionStatus. Статус ConnectedRemotely говорит нам о том, что мы подключены к корпоративной сети.

     

     

    Offline Doman Join (Server 2012/Windows 8)

    Возможность подключения машины к домену без наличия физического подключение к доменной сети появилось в Windows Server 2008 R2. Данная функция давала возможность заранее ввести клиента в домен, что экономило время разворачивания, если клиенты по какой-либо причине не находились заранее в одной физической сети. Синтаксис команды был прост, в результате выполнения которой создавала объект «Компьютер» в Active Directory и создавался текстовый файл. Выполняя команду на клиенте, указывался путь к этому файлу (его надо было перенести на клиент) и машина после загрузки считала себя в домене, но аутентифицироваться во время загрузки компьютера не получалось, пока не было общей сети с контролером домена.

    В Windows Server 2012 функционал Offline Domain Join расширился, а с DirectAccess обрел очень интересную и нужную особенность. Теперь можно любого удаленного клиента под управлением Windows 8 добавить в домен с помощью Offline Domain Join, и после перезагрузки клиент будет полноценно подключен к доменной сети через DirectAccess! Честно, это очень удобно. То есть, создав файл (так называемый «блоб») по добавлению клиента к домену на сервере с Windows Server 2012, затем переместив его любым способом на клиента, и запустив похожую команду, но уже на клиенте. После перезагрузки клиент будет в домене и сможет войти под доменной учетной записью, так как связь с контролерами домена будет установлена уже на этапе загрузки компьютера.

     

    Что бы это чудо свершилось, требуется:

     

    • Windows Server 2012. Не обязательно контролер домена, уровень леса может остаться без изменений (например, 2008 R2). Но надо установить компонент RSAT (Remote Server Administration Tools) на Windows Server 2012, можно на сам сервер DirectAccess.
    • Клиент обязательно должен быть под Windows 8 Enterprise
    • Настроенный DirectAccess 2012
    • Доступ в интернет со стороны клиента, так и со стороны доменной сети

     

    Опишу данную процедуру по шагам:

    На сервере из командной строки:

     

    • md С:\ODJ (создаем в корне диска C:\ папку «ODJ»)
    • djoin /provision /machine COMPUTERNAME /domain DOMAIN.NAME /policynames “DirectAccess Client Settings” /certtemplate DA_Computers_Authentication /savefile c:\odj\provision.txt /reuse

     

    Пояснение:

    /machine COMPUTERNAME – имя компьютера, который будет добавляется в домен

    /domain DOMAIN.NAME – имя целевого домена

    /policynames “DirectAccess Client Settings” – GPO, которое хотим переместить к подключаемому клиенту (обязательно должно быть клиентское GPO для DirectAccess)

    /certtemplate DA_Computers_Authentication – Если используется сертификат компьютера для аутентификации для DirectAccess, то нужно указать правильный шаблон

    /reuse – Ключ, который обнулит пароль компьютера, если компьютер с именем в команде уже есть. Лучше создать заранее объект «Компьютер» в правильно организационном подразделении (базовые «лучшие рекомендации»)

    Ключи /policynames и /certtemplate и отличают новый Offline Domain Join от старого, в старом их не было (есть еще несколько новых ключей, но в данном случае они не нужны).

    На клиенте заранее перенести файл provision.txt с сервера в папку C:\ODJ на клиенте.

     

    И из командной строки:

     

    • djoin /requestodj /loadfile C:\ODJ\provision.txt /windowspath %windir% /localos

     

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

    В данной статье я показал, как настроить базовую конфигурацию DirectAccess 2012 для клиентов Windows 8 и рассказал об улучшенном функционале Offline Domain Join в новой версии сервера. В следующей статье я покажу, как дать возможность клиентам под операционной системой Windows 7 получить все преимущества от DirectAccess, так как для этого требуется инфраструктура открытых ключей (PKI).

     

    Предыдущие стать из цикла DirectAccess 2012:

    Microsoft DirectAccess 2012: Введение

    Дмитрий Фомичев

Комментарии

  1. “создаем А-запись DA.CONTOSO.COM разрушающеюся на внешний IP-адрес” – исправьте, а то прямо режет глаз.
    И почему “В базовой конфигурации выбираем «Deploy DirectAccess only»”? Объясните разницу между представленными вариантами.

  2. Сергей, добрый день.
    Возможно мне показалось, но какой-то приказной тон прослеживается в Ваших словах. Тут никто никому ничем не обязан =)
    Как получилось написать, так пусть остается.
    «В базовой конфигурации выбираем «Deploy DirectAccess only» – из скриншота должно быть понятно, что в других случаях сервис удаленного доступа будет установлен вместе с VPN или только VPN без DirectAccess. Так как в данной статье рассматривается только служба DirectAccess, вот и выбран вариант «Deploy DirectAccess only».

  3. Извините, не хотел быть грубым. Спасибо за разъяснения. Жду информацию о том же, но только с клиентами на Windows 7 и использованием PKI. Не скоро, IMHO, на Windows 8 средние/крупные компании обновятся.

  4. Спасибо за нормальный how-to, надеюсь в скором времени протестировать

  5. Спасибо за хорошую статью. Как раз разворачиваю 2012 инфраструктуру. Очень помогает 🙂
    Ну и конечно интересно почитать DA for PKI/win7, особенно PKI 🙂

  6. Спасибо за статью!
    При использовании Windows 2012 + 8 так и остается ограничение, что по DirectAccess можно получить доступ к внутренним компьютерам, только у которых есть IPv6 адрес (и, соответственно, не видны компьютеры на которых есть только IPv4 адрес)?
    Не сталкивались, DirectAccess нельзя ставить на контроллер домена?

  7. Александр, требование к наличию IPv6 внутри сети не выдвигается. Это обно из улучшение в 2012, сам сервер DirectAccess преобразует IP6 в IPv4, до этого требовалось ставить UAG. Об этом сказано в первой статье.
    На контролер домена ставить можно (запрета нет), еще и не то умудряются на контролер поставить =) Другое дело что это очень далеко от бестпрактиса.

  8. Спасибо за быстрый ответ!
    Забавно, поднял DirectAccess как сказано в этой статье. Если он на одной машине с контроллером домена, то да, все устанавливается, но не работает (IPHTTPS подключается, но при запросе Get-DAConnectionStatus пишет что NameResolutionFailure и пишет что постоянно идет попытка подключения DirectAccess). Как только разнес контроллер домена и DirectAccess на разные виртульные машины – все заработало.
    Но появилась другая проблема. По IPv6 все работает, могу зайти в локальные папки и на интранет сайты. По IPv4 не пингую ни сервер DirectAccess, ни контроллер домена, ни какие-либо другие локальные компьютеры.
    Речь идет о тестовой середе, все машины чистые и установлены с нуля. Даже, честно, уже и не знаю что может быть причиной.

  9. К сожалению не экспериментировал с установкой DirectAccess на контроллер домена, но может здесь вы найдете ответ – http://technet.microsoft.com/en-us/library/jj204618.aspx

    И уточните откуда и куда вы пингуете по IPv4? Если вы с клиента DirectAccess, то пинги IPv4 не будут работать, нужно только по DNS именам.

  10. Все верно, пингую с ноутбука, который посредством 3G подключается через DirectAccess к вымышленному офису. Если пинговать по именам – все работает, т.к. имена резолвятся в IPv6. Если пинговать по IPv4, то пакеты не идут. Иными словами, на практике получается, что IPv6 так и остается обзательным требованием на серверах и компьютерах в офисе, чтобы до них можно было достучаться через DirectAccess?

  11. Нет, так как теперь на DirectAccess есть служба NAT64/DNS64, то требование в IPv6 на машинах внутри сети отпадает. Работает примерно так, мы обладая только IPv6 адресом обращаемся к ресурсу по ДНС имени получаем от службы NAT64/DNS64 IPv6 адрес который соответствует IPv4 адресу этого ресурса.

  12. Спасибо, теперь все стало понятно! Ввел Windows XP ради примера в домен, она зарегистрировала A запись в DNS, минут через 30-40 этот компьютер начал пинговаться с DirectAccess клиентов (видимо, NAT64/DNS64 вносит такую задержку).
    И действительно, как только сервер DirectAccess повышаю до контроллера домена, клиенты не могут к нему подключиться. Ну да ладно, в рабочей среде такого и не будет.
    Спасибо!

  13. Прошу подготовить статью с разворачивание DirectAccess 2012 c использованием PKI! А также осветить вопрос публикации DA через Forefront TMG 2010!

  14. Как и обещал, сет статей закончу. Но не сейчас.

  15. Всё проделал как описано выше, в состояние операций напротив Network location server образуется ошибка: «Не получен отклик с URL-адреса сервера сетевых расположений. Подключение DirectAccess может выполняться неправильно, и клиенты DirectAccess, находящиеся в корпоративной сети, могут лишиться доступа к внутренним ресурсам.»

  16. Подскажите куда копать, IIS запущен. Windows server 2012 essentials.

  17. Привет.
    Когда клиент внутри сети, он может попасть на сайт NLS? (http://nls.doman.name)
    Профиль у сетевого подключения доменный?
    И даже с этой ошибкой клиент внутри сети нормально к сетевым ресурсам обращается?

  18. Доброе утро! С самого сервера не могу попасть на nls.contoso.local . Профиль доменная сеть-contoso.local.

  19. И сразу попутный вопрос, веб сервер отдельно нужно как-то настраивать или всё должно делаться через управление конфигурацией Удаленный доступ?

  20. Отдельно настраивать не надо.
    telnet nls.domain.name 80 отклик есть?
    С других машин на сайт заходит?

  21. На nls.contoso.local нету отклика. Как нибудь проверить можно, где хоть эта ссылка должна быть указана, что именно nls… должен быть. В iis или где нибудь еще? Подскажите.

  22. nls.domain.local – я как пример написал, у Вас адрес может быть другой. В моей инструкции это DirectAccess-NLS.
    Если сервер находится там же, где DA, то доступ к нему надо проверить с других клиентов, а не с сервера.
    И я в прошлом сообщение косякнул, не 80 порт надо проверять, а 443.
    Если вы делал по инструкции, то проверьте доступ к страничке https://DirectAccess-NLS.contoso.com

  23. Телнетом заходит directaccess-nls.contoso.local по 443, в браузере в режиме просмотра каталога не показывает: Ошибка HTTP 403.14 – Forbidden.

  24. С клиента внутри сети тоже самое, доступ запрещен 403.

  25. Ну тут уже хз, надо смотреть в конкретном случае. В сети есть статейки, как люди DA поднимали на Essential. Может там найдете подсказку.

  26. Вечер добрый! И снова здраствуйте). На essential так и не удалось всё настроить, пришлось разносить на разные машины. Существует ли зависимость в ipv6 со стороны клиента?

  27. Всё , вопрос исчерпан. Ipv4 и только и всё работает.

  28. Вопрос: как пингануть клиента ? Клиент серверы видит нормально , а с самого сервера не могу пингонуть и подключиться удаленно.

  29. А если у меня в инфраструктуре есть Exchange и на него уже проброшен 443 порт, тогда как быть?

  30. “В следующей статье я покажу, как дать возможность клиентам под операционной системой Windows 7 получить все преимущества от DirectAccess, так как для этого требуется инфраструктура открытых ключей (PKI).” – выходила ли где-то эта статья?

    Как раз интересуют особенности подключения win7 клиентов к DA. Может кто-то еще может подсказать? В частности, возможно ли настроить это подключение к серверу с одним сетевым интерфейсом (поднял PKI, все настроил, клиенты win8 подключаются нормально, win7 – нет). Один адаптер используется потому, что в корпоративной сети нет NAT’а, только белые IP.

    Или подсказать, где прочитать полный список ограничений использования одного сетеровго адаптера на сервере DA? (грешу на него, т.к. предварительно делал лабу в тестовой среде, там клиенты win7 подключаются, но там настраивал по типу Edge).