У цій статті я зосереджуся на основних принципах та архітектури DRS. Деталі настройки можна подивитися в четвертому модулі курсу «Корпоративні пристрою. Як управляти гібридними обліковими даними ».
У чому основна проблема?
У доменній мережі засобами групових політик подібних ситуацій легко уникнути. Починаючи з пароля для логіна на доменне пристрій, закінчуючи сертифікатами для аутентифікації при доступі до додатка. Як бути з пристроями, які в домен включити неможливо? Підходи можуть бути різними: можна налаштувати обов'язкове використання пароля або PIN-коду для входу на пристрій, можна згенерувати і встановити сертифікат на планшет. Тільки для різних платформ ці процедури відрізняються, робити це доведеться вручну і напевно ІТ-персоналу, і кожен новий пристрій породжує відповідну ланцюжок дій. А хочеться, щоб з таким завданням міг впоратися власник пристрою, причому тоді, коли в цьому дійсно виникне необхідність.
У чому основна ідея?
Як випливає з назви служби, DRS реалізує процедуру реєстрації пристрою. У процесі реєстрації DRS генерує X.509-сертифікат, який завантажується на пристрій, а також створює в Active Directory новий об'єкт, що містить інформацію як про пристрій, так і користувача, зареєструйте.
Кожен раз, коли користувач підключається з зареєстрованого пристрою до додатка, виконується аутентифікація користувача (або він вводить пароль, або використовується cookie) і здійснюється перевірка сертифіката. І тільки якщо обидві перевірки успішно пройдені, користувач отримує доступ до додатка. По суті ми маємо справу з двухфакторной аутентификацией.
Але важливо відзначити кілька моментів:
- Процедура реєстрації максимально проста і не вимагає попереднього налаштування пристрою ІТ-спеціалістом.
- DRS підтримує різні платформи:
- Windows 8.1 і вище
- iOS 6 і вище
- Android - Samsung KNOX
- Windows 7 Pro (включена в домен)
- DRS не вимагає розгортання PKI
Як це виглядає?
Процес реєстрації пристрою зображений на наступному малюнку.
Отже, співробітник компанії знаходиться за межами компанії і в браузері планшета і не включеного в домен, набирає URL корпоративного порталу SharePoint. Запит через WAP перенаправляється ADFS, і ми бачимо таку картину.
Як видно, елементи сторінки аутентифікації ADFS, так само як і сторінок повідомлень про помилки (картинка, логотип, тексти повідомлень), налаштовуються. Користувач вказує логін і пароль своєї доменної облікового запису, причому логін вводиться в форматі User Principal Name (UPN). Так як пристрій поки не зареєстровано, в доступі відмовлено.
Натиснувши на кнопку Join. побачимо вже знайоме вікно аутентифікації ADFS.
Якщо пароль введений вірно, то пристрій зареєструється, і ми повертаємося до попереднього вікна, де можна помітити, що операція Workplacejoin завершена.
Що ж відбувається за кадром? На самому планшеті за допомогою оснастки Certificates можна виявити появу нового сертифіката.
Саме він і буде тепер використовуватися в якості другого фактора аутентифікації при підключенні до додатка.
У Active Directory відповідний сертифікату об'єкт можна знайти в новому контейнері RegisteredDevices. Ім'я об'єкта збігається з CN сертифіката. Атрибути цього об'єкта можна подивитися, наприклад, за допомогою ADSI Edit.
Серед атрибутів ми знайдемо ім'я пристрою, тип і версію ОС, SID користувача, який виконав реєстрацію, дату і час реєстрації та ін.
Пробуємо знову підключитися до порталу, знову потрапляємо на сторінку ADFS, знову вводимо credentials облікового запису AD. Але тепер крім перевірки пароля успішно завершується і перевірка сертифіката, і доступ до додатка отримано.
Більш того, після першого успішного підключення користувач отримує SSO для цього додатка. Він може закрити браузер, перезавантажити машину, відкрити браузер знову, набрати URL і ... отримати доступ до додатка без жодних додаткових запитань. Дійсно, cookies забезпечують перший фактор аутентифікації, сертифікат - другий. Природно, ненадовго, і періодично користувачеві доведеться підтверджувати свою автентичність введенням пароля. Але це термін контролює ІТ.
Додаткові міркування безпеки
Давайте повернемося до ситуації з втратою / крадіжкою планшета. Якщо пристрій вже зареєстровано, для додатка реалізований SSO, і пристрій потрапив в чужі руки. Перша лінія захисту - пароль або PIN-код для входу в пристрій. Для недоменних пристроїв обов'язкову блокування можна включити, наприклад, через Microsoft Intune або інше MDM-рішення. Якщо цього не було зроблено? Виходить, ми дали зловмиснику додаткові козирі - йому залишається просто відкрити браузер і набрати URL. Очевидно, в такій ситуації власник повинен якомога швидше повідомити свою службу ІТ. Що тоді зробить ІТ? Подивимося на кілька варіантів.
Якщо сервіс реєстрації пристроїв взагалі не використовується.
Обидва рішення, а також інші варіанти, які можна запропонувати, цілком можна застосувати, але не ідеальні.
Якщо пристрій було зареєстровано.
Адміністратору достатньо знайти в AD об'єкт, асоційований з загубленим пристроєм і або видалити об'єкт, або в його властивості для атрибута msDS-IsEnabled задати значення FALSE.
Тоді при підключенні до додатка сертифікат пристрою не пройде перевірку, і користувач отримає повідомлення про помилку. Таким чином, ми блокуємо доступ конкретного пристрою.
Але це вже тема окремої розмови.
Деталі по встановленню та налагодженню ADFS і DRS можна знайти, наприклад, тут:
Особливості настройки для пристроїв iOS, створення політик умовного доступу, розгортання WAP і ін .: