J3qx

information archive

Microsoft DirectAccess 2012: DirectAccess и Windows 8

Posted by j3qx на Январь 8, 2013

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).

©  http://itband.ru/2013/01/direct-access-1
© Дмитрий Фомичев
Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

 
%d такие блоггеры, как: