Active Directory vs. Microsoft Active Directory

Традиційно, для управління елементами доменної мережі використовується служба Active Directory. Але все частіше організації впроваджують в свою роботу різні хмарні служби, які вимагають створення своїх облікових записів. Інструментом для створення і управління обліковими записами користувачів, применыемых в різних хмарних служб Microsoft, які набуває організація, є Microsoft Active Directory. У цій статті ми поговоримо про деякі відмінності між Active Directory і Microsoft Active Directory, а також розглянемо основні сценарії їх синхронізації.




Я впевнена, що переважна більшість тих, хто читає цю статтю, знайомі з Active Directory, яка є частиною операційних систем Windows Server являє собою службу каталогів, запропоновану компанією Microsoft. Маючи обліковий запис AD, користувач автентифікований в системі і отримує доступ до додатків, файлових служб, принтерів та інших локальних ресурсів.

Так само, як і локальна Active Directory, Microsoft Active Directory аутентифікує користувачів і надає їм доступ до додатків. Однак, Microsoft Active Directory призначена для роботи користувач локальної інфраструктури, а при роботі зі сторонніми хмарними додатками, такими як Office365 і Windows Intune.

Наприклад, ваша організація набуває підписку на Windows Intune. При цьому ви, як адміністратор, отримуєте доступ до порталу керування Windows Intune і повинні надати іншим користувачам доступ до вашої мережі (всім або декільком — це вже деталі). Windows Intune — це служба Microsoft, яка не працює з локальної служби Active Directory. Для того, щоб створити облікові записи користувачів для доступу до локальних служб, які впроваджує і використовує організація, необхідно використовувати Microsoft Active Directory.

З технічної точки зору, потрібно відзначити, що для доступу до даних в локальній службі Active Directory бізнес-додатки можуть використовувати LDAP, а сторонні хмарні програми можуть взаємодіяти з даними з допомогою API Graph. Для аутентифікації AD DS використовується протокол Kerberos, а в Microsoft Active Directory — OAuth 2.0. На схемі показано далі, як додатки, розміщені або локально, або в хмарі, використовують схожі методології для доступу до даних посвідчень, які зберігаються в найбільш відповідною для них службі посвідчень.



Але повернемося до нашого прикладу. Компанія придбала підписку на Windows Intune, і тепер системний адміністратор повинен створити в Microsoft AD облікові записи для користувачів. Зробити він це може звичайно ручками через графічний інтерфейс або навіть використовувати командлети і скрипти PowerShell. Але, використовуючи цей варіант додавання користувачів, ви створюєте абсолютно самостійних користувачів, ніяк не пов'язаних з тими, що давно вже існують у вашій локальній сітці. Так, логіни можуть збігатися, а можуть і відрізнятися; паролі — тим більше. Все це — величезний джерело потенційної головного болю для адміна і регулярних звернень від користувачів в службу підтримки. Для того, щоб ці проблеми мінімізувати пропонується три сценарії синхронізації AD і Microsoft AD, про які ми поговоримо далі.

Синхронізація Active Directory, Microsoft Active Directory



Виділяють три основних сценарії синхронізації каталогів Active Directory, Microsoft Active Directory:
  1. Сценарій синхронізації теки дозволяє автоматично синхронізувати з хмарою нові облікові записи користувачів і груп, оновлення до існуючих облікових записів в локальній службі Active Directory, налаштувати клієнт для роботи в комбінованих сценарії з використанням Office 365 і включити рішення багатофакторної автентифікації в хмарі.
  2. Синхронізація Active Directory за допомогою сценарію синхронізації паролів у доповнення до можливостям синхронізації каталогів дає можливість користувачам задіяти пароль від локального облікового запису для доступу до локальних додатків і служб, що, в свою чергу, скорочує витрати на адміністрування паролів і дозволяє керувати політиками паролів з локального каталогу Active Directory.
  3. Синхронізація Active Directory за допомогою сценарію єдиного входу, на відміну від перших двох сценаріїв, не підтримує можливість включення рішення багатофакторної аутентифікації в хмарі, але зате підтримує цю можливість у локальному середовищі, а також забезпечує автентифікацію користувачів у локальному каталозі Active Directory і дозволяє реалізувати сценарії єдиного входу з використанням корпоративних облікових даних, налаштувати сторінку для єдиного входу і обмежити доступ до хмарних служб і додатків по місцю розташування, типу клієнта або кінцевій точці Exchange клієнта.
Все це, звичайно, чудово звучить, але більш цікаво подивитися, як кожен із сценаріїв синхронізації працює і в чому полягає його принципова особливість.

1 Сценарій синхронізації теки


Сценарій синхронізації каталогів використовується для синхронізації локальних об'єктів доменної мережі в хмару. При реалізації цього сценарію в результаті ви отримаєте обліковий запис користувача в Microsoft Active Directory, яка буде збігатися з локального облікового запису в усьому, крім пароля. Паролі при реалізації сценарію синхронізації каталогу НЕ синхронізуються. Тому тепер ви говорите вашим користувачам, що для доступу, наприклад, до Windows Intune можна використовувати свій звичайний логін, а ось пароль потрібно буде придумати інший. У цьому випадку, користувач при доступі до хмарі буде аутентифікований з допомогою саме Microsoft Active Directory. Приблизна схема того, як працює цей процес, представлена нижче.



Після того, як настройка виконана, адміністратори можуть управляти об'єктами каталогу, використовуючи локальну Active Directory, і ці зміни будуть синхронізовані з клієнтськими комп'ютерами. Синхронізація служби каталогів виконується за розкладом і синхронізуються з Azure AD.

Серед переваг сценарію синхронізації каталогу можна виділити:
  • Скорочення витрат на адміністрування. При використанні вже існуючих локальних облікових записів користувачів і груп немає необхідності керувати ними вручну в Microsoft AD, що економить бюджет і час.
  • Підвищення продуктивності. Автоматична синхронізація облікових записів користувачів і груп скорочує час, необхідне для забезпечення користувача доступом до хмарних служб і додатків.
  • Підвищення безпеки. Надання доступу та його відгук для облікових записів користувачів і груп відбувається автоматично, що дозволяє гарантувати доступ до ресурсів корпоративної мережі тільки тим, кому він дійсно потрібен, а також вказувати строк, на який надано доступ.


2 Синхронізація Active Directory за допомогою сценарію синхронізації паролів


Все-таки хворим місцем облікових записів користувачів є не логіни, а паролі. Логін зазвичай запам'ятати не складно, а от мати різні паролі для доступу до різних ресурсів — випробування для користувача. Тому він вигадує прості паролі, або пише їх на стікерах і клеїть на монітор, або здогадується використовувати скрізь один і той же пароль. Існує розширення сценарію синхронізації каталогу — сценарій синхронізації паролів. Якщо на комп'ютері вже реалізованої синхронізації каталогів увімкнути синхронізацію паролів, то співробітники вашої організації зможуть підключатися до хмарними служб Microsoft (наприклад, Office 365, Dynamics CRM, Windows InTune), використовуючи пароль від локального облікового запису. Зміна пароля локальної корпоративної мережі будуть синхронізовані з хмарою, причому паролі синхронізуються частіше, ніж інші дані каталогів.

Нижче наведена схема синхронізації Active Directory за допомогою сценарію синхронізації паролів. Щоб пароль був синхронізований, засіб синхронізації каталогів витягує хеш пароля користувача з локальної служби Active Directory і синхронізує його з Microsoft Active Directory.



Тепер зі спокійною душею говоримо користувачам, що ми використовуємо нову хмарну службу, доступ до якої можна отримати зі своїм звичайним логіном і паролем. Всі задоволені, всі щасливі.

При використанні даного сценарію синхронізації серед переваг слід відзначити:
  • Скорочення експлуатаційних витрат. Скорочення кількості паролів, які необхідні користувачу для роботи в корпоративній мережі, тягне за собою зменшення числа запитів на зміну пароля до служби підтримки.
  • Підвищення продуктивності. Скорочення числа паролів, які потрібні користувачеві доступ до тих чи інших ресурсів, збільшує час, протягом якого ці ресурси доступні.


Тим не менш, при реалізації сценарію синхронізації паролів, користувач все одно проходить процес аутентифікації за допомогою облікового запису Microsoft Active Directory, а ми хочемо піти далі і використовувати для аутентифікації саме служба Active Directory. Для того, щоб наш задум здійснити, необхідно використовувати сценарій синхронізації Active Directory за допомогою єдиного входу.

3 Синхронізація Active Directory за допомогою сценарію єдиного входу
Для реалізації єдиного входу повинен бути реалізований сценарій синхронізації каталогу і побудована інфраструктура служби токенів безпеки (STS). Azure AD підтримує сценарії єдиного входу, які використовують одну з таких служб токенів безпеки: Active Directory Federation Services, постачальник посвідчень Shibboleth, а також сторонні постачальники посвідчень.

Процес роботи сценарію єдиного входу представлений наступною схемою.


При реалізації сценарію єдиного входу налаштовуються федеративні відносини між службою STS (Security Token Service) і системою перевірки автентичності на Microsoft Active Directory. Користувач при спробі підключення до хмарі буде перенаправлено на сервер служби STS. Наприклад, при використанні служби ad FS, користувач буде перенаправлено на ADFS сервер, що можна буде побачити по зміні адреси в браузері:


Після успішної аутентифікації, користувач з обліковим записом каталогу Active Directory отримає токен автентифікації від локальної служби STS і з допомогою якого отримає доступ до хмарі. Принциповою відмінністю від перших двох сценаріїв є те, що у сценарії єдиного входу користувач автентифікований за допомогою Windows Server Active Directory.

Застосування сценарію єдиного входу пропонує головна перевага: працівник використовує свої облікові дані для доступу до локальних додатків і служб. Системні адміністратори також отримують ряд нових можливостей:
  • Керування політиками. Адміністратору не потрібно виконувати додаткові завдання в хмарі для того, щоб контролювати політики облікових записів Active Directory.
  • Управління доступом. Адміністратор може обмежити доступ до хмарних служб так, щоб доступ можна було отримати тільки через середовище організації або через інтернет-сервер.
  • Зниження кількості звернень за підтримкою. Тут все теж: менше паролів запам'ятовувати — менше звернень від користувачів.
  • Безпека. Так як всі сервери і служби, які використовуються в рамках реалізації сценарію єдиного входу, управляються і контролюються локально, то посвідчення користувачів і інформація про них захищені.
  • Підтримка суворої автентифікації. Сценарій єдиного входу дозволяє реалізувати багатофакторну автентифікацію хмарної служби або програми.


Сподіваюся, ця стаття дала вам уявлення про різницю між Active Directory і Microsoft Active Directory і сценарії їх синхронізації.

Докладні інструкції про те, як реалізувати кожний з описаних тут сценаріїв, ви можете подивитися на порталі TechnNet:
  1. Сценарій синхронізації теки
  2. Синхронізація Active Directory за допомогою сценарію синхронізації паролів
  3. Синхронізація Active Directory за допомогою сценарію єдиного входу


Спасибі!

Корисні посилання


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.