Latest / M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською / Microsoft Entra Domain Services простими словами: застарілі застосунки в Azure без власних контролерів домену (ШІ-дубляж)

Transcript

Microsoft Entra Domain Services простими словами: застарілі застосунки в Azure без власних контролерів домену (ШІ-дубляж) · M365.FM – подкаст про Microsoft 365, Copilot і ШІ українською

• 0:00
  Готові до 10-х днів Microsoft 365, Co-Pilot, She, Azure та людей, що формують майбутні роботи.
• 0:07
  Цього січня конференція М365 повертається, і ми стаємо ще масштабнішими.
• 0:12
  Приєднуйтесь до нас на живі сесії, реальні демо та отримайте практичні знання від MVP та експертів з усього світу.
• 0:18
  Жодних загальних слайдів, жодних нескінченних модних слів.
• 0:21
  Ми розв'язуємо реальні завдання, Co-Pilot Studio, She-агенти, Fabric, безпека, управління та автоматизація.
• 0:29
  Незалежно від того, чи ви IT-фахівець, розробник чи бізнес-лідер, у нас є сесії саме для вас.
• 0:35
  За 10 повних днів ви зможете вивчити різні технології та поспілкуватися зі світовою спільнотою.
• 0:40
  Дивіться наживо та приносте практичні ідеї у свою організацію.
• 0:44
  Січень 2027 року. 10-х днів. Одна спільнота Microsoft. Реєстрацію відкрито.
• 0:51
  Переходьте на M365.con.net та забронюйте своє місце сьогодні.
• 0:56
  Це M365.con.net.
• 1:00
  Приєднуйтесь на M365.con.net і побачимось у січні.
• 1:05
  Вітаю всіх. Це ще один епізод Microsoft Knowledge Nuggets на M365.fm.
• 1:10
  Я Мірко Пітерс.
• 1:11
  Уявіть, що ви переносите старий бізнес-додаток із сервера в офісі на віртуальну машину Azure.
• 1:16
  Додаток тепер у хмари, але він все ще потребує домену Windows.
• 1:19
  Він хоче приєднатися до домену, шукати користувачів через LDAP,
• 1:22
  входити через Kerberas і застосовувати групові політики.
• 1:24
  Більшість людей вважають, що EntraID замінює всі функції Active Directory.
• 1:28
  Це не так.
• 1:29
  Сучасні хмарні додатки можуть входити через EntraID,
• 1:32
  але старі Windows-програми все ще потребують того ж типу домену, що був у серверній.
• 1:36
  Наприкінці цього епізоду ви зрозумієте, де доречні EntraID, Active Directory та EntraDomain Services
• 1:41
  і дізнаєтесь одну деталь, що змінить ваш підхід до керування.
• 1:44
  Інформація про ідентифікацію рухається лише в одному напрямку.
• 1:47
  Чому сам лише EntraID не може запускати будь-який застарілий додаток?
• 1:50
  Почнімо з того, що EntraID робить добре.
• 1:53
  Це рецепція для ваших хмарних сервісів.
• 1:55
  Він знає, хто ви, перевіряє ваш вхід і вирішує,
• 1:57
  чи можете ви отримати доступ до Microsoft 365, Teams, SharePoint чи хмарного бізнес-додатка.
• 2:01
  Ви входите один раз, а потім перемикаєтесь між сервісами без потреби вводити пароль знову і знову.
• 2:06
  Це єдиний вхід – сінгл Sign-on.
• 2:08
  EntraID також може запросити другу перевірку через багатофакторну автентифікацію,
• 2:13
  перевірити пристрій, місце входу та правила доступу вашої компанії.
• 2:17
  Для сучасних додатків ця модель працює чудово.
• 2:19
  Ви відкриваєте браузер, додаток спрямовує вас на EntraID,
• 2:22
  ви входите, можливо, підтверджуєте запит на телефоні,
• 2:25
  і EntraID надсилає додатку «Безпечне повідомлення про вхід».
• 2:28
  Додаток считує це повідомлення і надає вам доступ.
• 2:30
  За цієї моделі немає потреби в приєднанні до домену,
• 2:33
  використанні застарілих Windows Server чи пошуку застосунком класичного корпоративного каталогу.
• 2:37
  Але старіші застосунки виросли в іншому світі.
• 2:39
  Уявіть фінансовий застосунок, який роками працював на Windows Server,
• 2:42
  де користувачі входять у систему з ПК, приєднаних до домену.
• 2:45
  Застосунок шукає дані працівників через LDAP,
• 2:47
  поширений спосіб для старішого програмного забезпечення шукати в корпоративному каталозі.
• 2:50
  Він може використовувати Kerberas, старіший метод входу в Windows,
• 2:53
  який дозволяє системам довіряти одна одній.
• 2:55
  Він може покладатися на групові політики набір корпоративних правил,
• 2:58
  що керують налаштуваннями на комп'ютерах Windows.
• 3:00
  Такий застосунок не вміє считувати сучасні хмарні повідомлення для входу.
• 3:03
  Він очікує на запит до мережі, щоб знайти традиційний домен Windows.
• 3:07
  І якщо він його не знаходить, застосунок може не впустити користувачів,
• 3:09
  не знайти службовий обліковий запис або просто відмовитися запускатися.
• 3:12
  Ви, ймовірно, бачили подібне не лише в ІТ.
• 3:15
  Нова розетка не допоможе, якщо вилка старої машини до неї не підходить.
• 3:18
  Електрика є, але з'єднання не те.
• 3:20
  Тепер уявіть, що компанія переносить цей фінансовий застосунок
• 3:23
  і його базу даних на віртуальні машини Azure.
• 3:25
  Сервери переїхали, а старі потреби – ні.
• 3:27
  Ви можете залишити Active Directory в офісі
• 3:29
  та з'єднати Azure з ним через VPN – приватний мережевий тунель.
• 3:32
  Тоді застосунок в Azure надсилатиме запити через це з'єднання,
• 3:35
  коли йому знадобиться домен.
• 3:37
  Це може спрацювати, але застосунок тепер залежить
• 3:39
  від стабільності мережевого каналу та локального контролера домену.
• 3:42
  І якщо з цим з'єднанням виникає проблема,
• 3:44
  хмарний застосунок також матиме проблеми.
• 3:46
  Інший варіант – створити власні віртуальні машини контролерів домену Azure.
• 3:49
  Контролер – це сервер, на якому працює традиційний домен Active Directory,
• 3:52
  що обслуговує каталог, входи в систему та інші доменні завдання.
• 3:55
  Це теж працює, але тепер ваша команда володіє більшою кількістю серверів.
• 3:58
  Хтось має їх оновлювати та моніторити.
• 4:00
  Вам потрібні резервні копії, плани відновлення,
• 4:02
  план синхронізації контролерів домену,
• 4:04
  а також захист потужних облікових записів адміністраторів,
• 4:06
  що керують доменом.
• 4:07
  Для деяких компаній такий контроль є доцільним.
• 4:09
  Для інших це зайва робота лише для того,
• 4:11
  щоб підтримувати роботу старішого застосунку.
• 4:13
  Отже, прірва досить вузька, але вона реальна.
• 4:15
  Застосунок працює в Azure, проте все ще говорить старою мовою Active Directory.
• 4:19
  Що таке Microsoft Entra Domain Service насправді –
• 4:22
  це керований домен Windows, який працює всередині вашої мережі Azure.
• 4:26
  Це визначення простою мовою.
• 4:28
  Контролери домену працюють у фоновому режимі під повним керуванням Microsoft,
• 4:31
  тоді як ваші віртуальні машини Azure та старіші додатки використовують звичні доменні служби.
• 4:36
  Уявіть свою хмарну інфраструктуру як офісну будівлю.
• 4:38
  Entra ID – це стійка реєстрації на вході.
• 4:41
  Вона перевіряє вашу особу під час входу в Microsoft 365 чи інші хмарні додатки
• 4:44
  та застосовує корпоративні правила до цього входу.
• 4:46
  Entra Domain Service зросташована в зачиненому офісному приміщенні позаду.
• 4:49
  Старіші системи не потребують відвідування стійки реєстрації, як сучасні хмарні додатки.
• 4:53
  Їм потрібен старий каталог поруч, який розуміє їхню мову і може відповідати на їхні запити.
• 4:57
  Це офісне приміщення позаду і є керований домен.
• 5:00
  Ось у чому річ – вам не потрібно створювати контролери домену самостійно.
• 5:03
  Ви не входите до них через віддалений робочий стіл.
• 5:05
  Ви не вирішуєте, скільки їх запускати, не встановлюєте патчі Windows і не керуєте зв'язком між ними.
• 5:08
  Microsoft бере на себе все це.
• 5:10
  Ваше завдання – підключити потрібні віртуальні машини Azure та додатки до керованого домену.
• 5:14
  Після підключення вони можуть використовувати звичні служби Active Directory.
• 5:17
  Віртуальна машина Windows може приєднатися до домену,
• 5:19
  а старіші додатки – використовувати LDAP для пошуку користувачів, груп та даних каталогу.
• 5:23
  Можна використовувати Kerberas – метод входу, якого часто очікують старі бізнес-додатки,
• 5:27
  коли один сервер має довіряти іншому.
• 5:28
  Також можна використовувати NTLM – ще один старіший метод входу Windows, який все ще потрібен деяким додаткам.
• 5:34
  Керований домен також надає DNS, що допомагає системам знаходити потрібний сервер за іменем, а не за набором цифр.
• 5:39
  Крім того, він підтримує групові політики, тож ви можете застосовувати певні налаштування Windows до комп'ютерів і користувачів у цьому керованому домені.
• 5:44
  Я знаю, цей список звучить технічно складно.
• 5:46
  Натомість уявіть, це як бюро перекладів.
• 5:48
  Ваш додаток запитує старою мовою Windows, хто цей користувач,
• 5:52
  чи може цей сервер довіряти тому серверу, де знаходиться база даних, які налаштування має використовувати цей комп'ютер.
• 5:58
  Entra Domain Service зрозуміє ці питання і дає відповіді, які очікує додаток, але не створює другий основний список співробітників.
• 6:04
  Головний запис ідентифікації залишається в Entra ID.
• 6:07
  Користувачі та групи з Entra ID копіюються в керований домен, щоб старіші додатки могли бачити та використовувати їх у зрозумілому форматі.
• 6:12
  Якщо у вашій компанії також є локальна Active Directory, ідентифікаційні дані можуть спочатку потрапляти звідти в Entra ID, перш ніж копіюватися в Domain Services.
• 6:19
  Тут важливий напрямок руху.
• 6:20
  Дані ідентифікації надходять до Entra Domain Services.
• 6:23
  Вони не повертаються назад.
• 6:24
  Тож, якщо користувач походить з Entra ID, ви керуєте цим користувачем в Entra ID.
• 6:28
  Якщо користувач спочатку походить з вашої локальної Active Directory, ви керуєте ним саме там.
• 6:32
  Не варто сприймати Domain Services як місце для редагування основного запису працівника.
• 6:37
  Це вберігає керований домен від перетворення на другу картотеку з різними версіями однієї особи.
• 6:41
  Є один момент, на якому багато хто спіткнувся під час налаштування – це паролі.
• 6:45
  Сучасний хмарний вхід і старіший вхід у Windows працюють з паролями не зовсім однаково.
• 6:49
  Щоб Kerberas і Ntlm працювали, Domain Services потребує захищеної форми парольних даних, яка підтримує ці старі методи.
• 6:55
  Microsoft ніколи не зберігає ваш пароль у вигляді звичайного тексту.
• 6:58
  Натомість службі потрібна правильна захищена інформація про пароль, перш ніж користувач зможе увійти у приєднану до домену віртуальну машину або старий додаток через керований домен.
• 7:06
  Для хмарних користувачів це часто означає, що їм потрібно змінити пароль після ввімкнення Domain Services.
• 7:12
  Ця зміна пароля створює захищену форму, необхідну для керованого домену.
• 7:15
  Доки це не станеться, користувач може успішно входити в Microsoft 365, але зазнавати невдачі при спробі використати домен старого зразка.
• 7:22
  Спочатку це може здаватися дивним.
• 7:24
  Користувач вже має обліковий запис, пароль працює, але за старілий додаток все одно не може його використати.
• 7:28
  Відсутній елемент – це не обліковий запис користувача.
• 7:31
  Це захищена форма пароля, необхідна для тих старих методів входу.
• 7:34
  Domain Services також має чіткі межі того, де він працює.
• 7:37
  Він працює всередині віртуальної мережі Azure, яку часто називають внет.
• 7:40
  Вашим віртуальним машинам Azure потрібен мережевий доступ до цієї внет,
• 7:43
  і вони повинні використовувати налаштування DNS керованого домену, щоб знайти його.
• 7:47
  Це не публічний каталог, до якого може звернутися будь-який пристрій в інтернеті.
• 7:50
  Це приватна доменна служба для робочих навантажень, підключених до відповідної мережі Azure.
• 7:54
  Отже, коли додатку потрібна стара поведінка Active Directory в Azure,
• 7:57
  Domain Services надає кероване місце, де можна знайти цю поведінку.
• 8:00
  Це підводить нас до наступного питання.
• 8:02
  Де це знаходиться поряд із EntraID та вашим існуючим доменом Active Directory?
• 8:06
  Назви звучать схожі, але їхні завдання дуже різні.
• 8:09
  EntraID, Active Directory та Domain Services.
• 8:12
  Різні завдання.
• 8:13
  Назви близькі, тому легко сприйняти їх як різні версії одного продукту.
• 8:17
  Це не так.
• 8:18
  Кожен із них відповідає за різну частину ідентифікації вашої компанії,
• 8:21
  і коли ви бачите завдання кожного з них, вибір стає набагато зрозумілішим.
• 8:24
  EntraID займається хмарною ідентифікацією.
• 8:26
  Коли ви відкриваєте Microsoft 365, Teams, SharePoint або сучасний бізнес-додаток,
• 8:31
  EntraID перевіряє ваш вхід і контролює доступ.
• 8:33
  Він також підтримує багатофекторну автентифікацію та правила доступу,
• 8:36
  наприклад, запит на сильнішу перевірку входу, коли ви працюєте з невідомого пристрою.
• 8:40
  Він створений для хмарних сервісів.
• 8:42
  Сучасному додатку не потрібно перебувати в тій самій мережі, що є EntraID,
• 8:45
  оскільки він використовує веб-методи входу.
• 8:47
  Ви входите через браузер або додаток EntraID підтверджує вашу особу
• 8:50
  і програма отримує доказ того, що вам дозволено доступ.
• 8:53
  Це стандартний шаблон для нових хмарних додатків.
• 8:55
  Служби доменів Active Directory, які часто скорочують до Active Directory, виконують іншу роботу.
• 9:00
  Це традиційний домен Windows, який багато компаній використовують у своїх офісах,
• 9:03
  центрах обробки даних або серверних кімнатах.
• 9:05
  Компанія володіє контролерами домену, вирішує, як їх налаштувати
• 9:08
  і керує всім доменом від початку до кінця.
• 9:10
  Він може керувати ПК з Windows, підтримувати локальні сервери
• 9:13
  та забезпечувати старі методи входу, яких очікують давно існуючі бізнес-додатки.
• 9:16
  Такий рівень контролю передбачає відповідальність.
• 9:19
  Ваша ІТ-команда керує доменом, стежить за серверами
• 9:21
  та вирішує, як каталог має працювати для компанії.
• 9:24
  EntraDomain сервіса зросташовується між цими двома світами.
• 9:27
  Він надає робочим навантаженням Azure керований домен Windows,
• 9:30
  коли їм потрібна стара поведінка Active Directory,
• 9:32
  Але Microsoft керує стороною контролера домену.
• 9:34
  Ви використовуєте домен для віртуальних машин Azure і старих програм,
• 9:37
  не беручи на себе повну роботу з керування традиційним доменом Active Directory.
• 9:40
  Уявіть це як систему картотеки.
• 9:42
  EntraID зберігає основні записи про співробітників для роботи в хмарі.
• 9:46
  Саме там компанія веде робочий реєстр,
• 9:47
  який використовується для Microsoft 365 і сучасних хмарних входів.
• 9:51
  Домайн сервіса знадає старим додаткам Azure сумісну копію записів, які їм потрібні.
• 9:55
  Ці додатки можуть відкрити звичний тип картотеки
• 9:57
  та знайти користувачів, групи та деталі входу у старому форматі, який вони розуміють.
• 10:01
  Вам не потрібно перебудовувати додаток лише тому, що він переїхав в Azure.
• 10:04
  Хмарна компанія також може використовувати це налаштування.
• 10:07
  Уявіть компанію, яка ніколи не мала локальних контролерів домену.
• 10:10
  Усі входять у Microsoft 365 через EntraID,
• 10:13
  і бізнес починає використовувати віртуальні машини Azure для старого додатку Windows.
• 10:16
  Такій компанії не потрібно створювати локальний домен Active Directory лише для цього додатку.
• 10:20
  Натомість вона може використовувати EntraDomain Services для віртуальних машин Azure,
• 10:23
  яким потрібна поведінка домену,
• 10:25
  тоді як решта компанії продовжує використовувати EntraID для звичайної хмарної роботи.
• 10:28
  Гібридна компанія має іншу відправну точку.
• 10:30
  Вона вже може використовувати Active Directory в офісі з користувачами та групами,
• 10:34
  які синхронізуються з EntraID.
• 10:35
  Ці люди потім можуть з'явитися в EntraDomain Services для робочих навантажень, що працюють в Azure.
• 10:39
  Потік виглядає так.
• 10:40
  Існуюча в компанії Active Directory надсилає деталі ідентифікації в EntraID,
• 10:45
  а EntraID надає сумісну копію для Domain Services.
• 10:48
  Це не означає, що Domain Services замінює оригінальний локальний домен.
• 10:52
  В вашому офісу все ще може бути потрібен власний домен Active Directory для локальних ПК,
• 10:56
  серверів, заводських систем або застосунків, що залишаються на місці.
• 10:59
  Domain Services обробляє лише ту частину Azure,
• 11:01
  де керована поведінка доменів старого зразка підходить для робочого навантаження.
• 11:04
  І це також не перетворює EntraID на повноцінний Active Directory.
• 11:07
  EntraID залишається хмарною службою ідентифікації.
• 11:10
  Domain Services додає керований домен для певних застарілих потреб,
• 11:13
  але не надає всіх можливостей і рівнів контролю,
• 11:15
  які ви маєте при самостійному керуванні Active Directory.
• 11:18
  Отже, уявіть три окремі завдання.
• 11:20
  EntraID відповідає за сучасні хмарні входи в систему.
• 11:23
  Active Directory відповідає за домен Windows, який ваша компанія обслуговує самостійно.
• 11:26
  Entra Domain Services обробляє застарілі робочі навантаження Azure,
• 11:29
  яким усе ще потрібен домен Windows, не вимагаючи від вас керування контролерами домену.
• 11:33
  Ви можете поставити набагато краще запитання.
• 11:36
  Коли Domain Services підходить для робочого навантаження,
• 11:38
  а коли варто обрати щось інше.
• 11:40
  Коли Domain Services підходить, а коли ні.
• 11:42
  Починайте з додатка, а не з назви продукту.
• 11:45
  Якщо старіший додаток використовує LDAP,
• 11:47
  це стара мова для перевірки імен користувачів і паролів,
• 11:49
  і ви переміщуєте його вежур, Domain Services може чудово підійти.
• 11:52
  Додаток продовжує використовувати те,
• 11:54
  що вже розуміє, без необхідності повного переписування.
• 11:56
  Це важливо, коли додаток ще працює, бізнесу він потрібен,
• 11:58
  а переписування коду входу забрало б за багато часу чи грошей.
• 12:01
  Інший поширений сценарій групі віртуальних машин Azure
• 12:04
  потрібно працювати як звичайним доменним комп'ютером.
• 12:06
  Співробітникам може знадобитися вхід у Windows
• 12:08
  за допомогою робочого облікового запису.
• 12:09
  Службі може знадобитися сервісний обліковий запис – це аккаунт,
• 12:12
  який додаток використовує для підключення до іншої системи,
• 12:14
  наприклад, бази даних.
• 12:14
  Можливо, вам знадобляться групові політики
• 12:16
  для застосування налаштувань компанії до цих віртуальних машин.
• 12:18
  У таких випадках Domain Services забезпечує машинам
• 12:20
  вежурту поведінку домену, якої вони очікують.
• 12:23
  Служби віддалених робочих столів також підходять сюди.
• 12:25
  Уявіть працівників, що підключаються до спільних робочих столів
• 12:28
  Windows або додатків вежур.
• 12:29
  Ці системи часто залежать від домену Windows
• 12:31
  для входу користувачів і керування комп'ютерами.
• 12:33
  Domain Services надає цей доменний рівень,
• 12:35
  щоб вашій команді не довелося створювати
• 12:37
  віртуальні машини контролерів домену з нуля.
• 12:39
  Застарілі додатки часто складаються з кількох частин.
• 12:41
  Може бути веб-сервер попереду,
• 12:43
  сервер додатків посередині та база даних позаду.
• 12:45
  Сервер додатків має підтвердити свою ідентичність,
• 12:48
  перш ніж база даних прийме з'єднання.
• 12:49
  Коли ця довіра покладається на сервісні облікові записи Windows,
• 12:52
  Domain Services підтримує роботу цих з'єднань після перенесення.
• 12:55
  Суть ось у чому.
• 12:56
  Ваша команда отримує застарілу доменну поведінку,
• 12:58
  необхідну для навантаження,
• 12:59
  тоді як Microsoft бере на себе роботу контролера домену,
• 13:02
  яка інакше лягла б на ваш список серверів.
• 13:04
  Але не оберайте домейн сервісу з лише тому,
• 13:06
  що ви використовуєте Azure.
• 13:07
  Новий хмарний додаток має виконувати вхід
• 13:09
  безпосередньо через EntraID.
• 13:10
  Якщо він підтримує сучасні методи входу,
• 13:12
  він перенаправляє користувачів до EntraID,
• 13:14
  отримує підтвердження входу
• 13:15
  та використовує переваги правил хмарного доступу
• 13:17
  і багатофакторної автентифікації.
• 13:18
  Це чистіший шлях для нового програмного забезпечення.
• 13:21
  Служби домену допомагають додатку,
• 13:22
  що використовує стару мову спілкування.
• 13:24
  Це не привід навчати нові додатки цій старій мові.
• 13:26
  Існують також суворі обмеження,
• 13:28
  які варто перевірити заздалегідь.
• 13:29
  Деякі додатки не просто считують дані з Active Directory,
• 13:32
  вони записують їх назад.
• 13:33
  Наприклад, додатку може знадобитися створювати
• 13:35
  або змінювати записи в каталозі під час своєї роботи.
• 13:37
  Служби домену не підходять,
• 13:39
  якщо додатку потрібен доступ для запису через LDAP.
• 13:42
  Те саме застереження стосується випадків,
• 13:43
  коли додатку потрібно змінити схему Active Directory,
• 13:45
  набір полів, що визначають, які дані може зберігати каталог.
• 13:48
  Деяке старе програмне забезпечення
• 13:49
  вимагає додавання власних полів перед запуском.
• 13:52
  Керований домен не дозволяє змінювати цю базову структуру.
• 13:54
  Вам також варто зупинитися,
• 13:55
  якщо ваша команда потребує повного контролю над самим доменом.
• 13:58
  Можливо, вам потрібен прямий доступ до контролерів домену.
• 14:00
  Можливо, вам потрібні права адміністратора домену,
• 14:03
  які надають дуже широкі повноваження.
• 14:04
  Або, можливо, вам потрібна складна структура каталогу,
• 14:06
  яку ви хочете побудувати й обслуговувати власноруч.
• 14:08
  Це вказує на необхідність керувати Active Directory
• 14:11
  самостійно або локально або на віртуальних машинах Vesur.
• 14:14
  Служби домену свідомо надають менше контролю,
• 14:16
  оскільки Microsoft керує основною службою домену.
• 14:18
  Тож задайте собі одне просте питання перед вибором шляху.
• 14:21
  Чи потребує це робоче навантаження старої мови Active Directory,
• 14:24
  чи воно може працювати з сучасною EntraID.
• 14:26
  Якщо воно може використовувати сучасну EntraID, почніть з цього.
• 14:28
  Якщо воно потребує старої поведінки домену,
• 14:30
  але не вимагає від вас володіння кожною частиною домену,
• 14:32
  служби домену можуть чудово підійти.
• 14:34
  А якщо додатку потрібно переписувати каталог,
• 14:36
  змінювати схему або надавати вашій команді повний контроль над доменом,
• 14:39
  йому потрібне інше місце.
• 14:40
  Вибір керованого домену означає прийняття компромісу.
• 14:43
  Microsoft бере на себе турботу про контролери домену,
• 14:45
  а ви відмовляєтеся від частини контролю,
• 14:46
  який отримуєте при самостійному керуванні.
• 14:48
  Компроміси керованої служби, про які вам слід знати.
• 14:50
  Такий керований підхід економить роботу,
• 14:52
  але змінює те, що може контролювати ваша IT-команда.
• 14:55
  Microsoft керує контролерами домену,
• 14:56
  підтримує їх синхронізацію,
• 14:58
  встановлює оновлення та забезпечує доступність залаштунками.
• 15:00
  Вам не потрібно планувати розміщення кожного контролера домену
• 15:03
  або відновлювати його після збою сервера.
• 15:05
  Саме тому багато команд обирають це рішення,
• 15:07
  але ви не можете підключитися до цих контролерів
• 15:08
  через віддалений робочий стіл,
• 15:10
  і ви не отримуєте прав адміністратора домену чи підприємства,
• 15:12
  оскільки вони надали б контроль над компонентами,
• 15:14
  якими керує Microsoft.
• 15:15
  Замість цього Microsoft надає групу під назвою
• 15:17
  Administratori Entra Domain Services.
• 15:19
  Додайте людей, яким потрібно керувати доменом,
• 15:21
  до цієї групи, а потім використовуйте віртуальну машину керування,
• 15:24
  приєднану до керованого домену.
• 15:25
  З цієї машини ви можете використовувати знайомі інструменти
• 15:27
  Active Directory для керування тим, що дозволяє Microsoft.
• 15:29
  Наприклад, ви можете створювати власні організаційні одиниці або OU.
• 15:33
  Сприймайте їх як папки для об'єктів домену,
• 15:34
  таких як комп'ютери або сервісні облікові записи.
• 15:37
  Ви можете керувати записами DNS,
• 15:38
  створювати та застосовувати групові політики для підтримуваних налаштувань.
• 15:41
  Ви також можете керувати комп'ютерами, які приєднуються до домену,
• 15:43
  що часто є головною причиною існування цієї служби.
• 15:45
  Ці обмеження встановлені навмисно.
• 15:47
  Ви не можете додавати більше контролерів домену,
• 15:49
  змінювати схему Active Directory
• 15:50
  або розглядати керований домен як місце,
• 15:52
  звідки зміни повертаються до EntraID.
• 15:54
  Тому здійснюйте керування користувачами та групами у вихідному каталозі.
• 15:57
  Для хмарної компанії таким джерелом є EntraID.
• 16:00
  Для гібридної компанії це локальна Active Directory,
• 16:02
  яка синхронізується з EntraID.
• 16:04
  Це правило запобігає помилці, яку ми часто спостерігаємо.
• 16:07
  Хтось бачить користувача в керованому домені та вносить зміни,
• 16:10
  припускаючи, що вони залишаться.
• 16:11
  Але ці зміни не стануть корпоративним записом в EntraID
• 16:14
  або локальний Active Directory.
• 16:16
  Зберігайте керований домен приватним у межах мережі Azure.
• 16:19
  Він має підтримувати лише ті робочі навантаження,
• 16:21
  які цього потребують, а не ставати загальним корпоративним каталогом.
• 16:23
  Обмежте мережевий доступ, захистіть машину керування
• 16:26
  та надайте адміністративний доступ лише тим, кому це потрібно.
• 16:28
  Ви обираєте службу з певними обмеженнями.
• 16:31
  Ці обмеження знімають частину роботи,
• 16:32
  водночас не дозволяючи змінювати ті частини, які належать Microsoft.
• 16:36
  Проста історія міграції в Azure.
• 16:38
  Уявіть фінансову компанію, яка використовує старий додаток на серверах у власному офісі.
• 16:42
  Цей додаток покладається на LDAP для пошуку співробітників.
• 16:44
  Він використовує Kerberas, коли користувачі входять у систему,
• 16:46
  а його сервер автентифікується за допомогою сервісного облікового запису
• 16:49
  для доступу до фінансової бази даних.
• 16:50
  Компанія хоче перенести і додаток, і базу даних на віртуальні машини Azure.
• 16:54
  Один із варіантів – залишити додаток підключеним до офісного домену через VPN,
• 16:57
  але тоді додаток Azure щодня залежатиме від цього мережевого з'єднання та локальних контролерів домену.
• 17:02
  Інший варіант – запуск нових віртуальних машин-контролерів домену в Azure.
• 17:05
  Це зберігає більшу частину трафіку в межах Azure, але додає сервери Windows,
• 17:08
  які і те команда має оновлювати, моніторити, резервувати та відновлювати.
• 17:11
  Команда обирає інший шлях.
• 17:13
  Їхні користувачі та групи вже синхронізовані з EntraID.
• 17:16
  Вони вмикають EntraDomain Services, підключають віртуальну мережу Azure.