Що потрібно для впровадження DirectAccess в базовій конфігурації:
Тож почнемо. У цьому посібнику буде використовуватися англомовний інтерфейс.
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»
Завершуємо майстер настройки, якщо після застосування параметрів бачимо помилки, які не турбуємося, ми їх виправимо далі. Але для розуміння процесу подивіться, на що скаржиться установник.
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 говорить нам про те, що ми підключені до корпоративної мережі.
Що б це диво сталося, потрібно:
Опишу дану процедуру по кроках:
На сервері з командного рядка:
- 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
Якщо все пройшло штатно, то буде потрібно перезавантаження, після якої можна буде аутентифицироваться за допомогою доменної облікового запису. І якщо аутентифікація пройшла успішна, то перевірити доступ до доменних ресурсів.