Приєднання віртуальної машини Azure до Entra Domain Services: спершу вирішіть

Перед віртуальною машиною Windows Server, якій потрібен керований каталог, стоять три рішення, і команда приєднання — найменше з них. Виберіть неправильну модель каталогу, і приєднання вдасться, а застосунок усе одно не зможе пройти автентифікацію. Помиліться в розв'язанні імен, і збій з'явиться там, де він виглядає як проблема з обліковими даними.

Визначте модель, розв'язання та обліковий запис до того, як торкнутися сервера, тоді команда виконається один раз.

Яке з трьох приєднань вам справді потрібне

Приєднання пристрою реєструє машину в Microsoft Entra ID для умовного доступу та єдиного входу і не дає робочому навантаженню квитка Kerberos до домену локального зразка. Традиційне приєднання до домену прив'язує об'єкт комп'ютера до каталогу й дає йому обліковий запис машини, групову політику та автентифікацію домену. Керований домен надає цю другу модель як послугу. Назви звучать схоже, а результати — ні.

Лише останні два варіанти включають контролер домену у звичайному розумінні, і лише керований варіант прибирає сервери з вашого списку виправлень.

Рішення зазвичай залежить від застосунку, а не від уподобання. Програмне забезпечення, якому потрібне прив'язування LDAP, обліковий запис служби з SPN або об'єкти групової політики, належить до моделі домену. Програмне забезпечення, якому треба лише знати особу користувача на корпоративному пристрої, зазвичай не належить.

Шлях DNS вирішує, чи зможе приєднання завершитися

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

Перевіряйте локатор, а не голе ім'я хоста. Пінг за ім'ям домену майже нічого не доводить, тоді як SRV-запит записів контролера домену або повертає очікувані цілі, або одразу не вдається:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.ds.corp.example" -Type SRV -Server 10.20.0.4
Test-NetConnection -ComputerName 10.20.0.4 -Port 53

Замініть ім'я домену та дві адреси значеннями з конфігурації керованого домену; числа тут наведено як приклади. Якщо запит повертає відповіді іншої зони, машина використовує розв'язувач, який не переспрямовує керований простір імен, і жодна кількість повторів приєднання цього не змінить.

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

Придатність облікового запису перевіряється раніше за машину

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

Синхронізовані гібридні облікові записи мають власні передумови, яких видимий об'єкт користувача сам не задовольняє. Бути в списку каталогу — не те саме, що мати змогу отримати з нього квиток, тож перевіряйте обліковий запис до вікна обслуговування, а не під час нього.

Делегуйте право приєднання вузько. Дати кожному майбутньому користувачеві сервера членство в адміністраторах домену заради однієї реєстрації — це постійний дозвіл заради тимчасової проблеми.

Саме приєднання — це одна команда

Коли модель вибрано, DNS відповідає, а обліковий запис придатний, операція є звичайною операцією Windows. Запрошення тримає пароль поза сценаріями та історією оболонки:

Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru

Команда в такій формі сама не перезавантажує машину, тож перезавантаження відбувається за планом обслуговування і з досі доступним шляхом відновлення. Серверу, вже приєднаному до іншого домену, потрібен план міграції, а не друге приєднання поверх першого.

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

Чого членство не дає

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

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

Настанова Microsoft щодо приєднання Windows Server перелічує підтримувані передумови для сценарію з керованим доменом. Читайте її з огляду на три рішення вище і будь-яку розбіжність вважайте причиною зупинитися, а не деталлю, яку слід обійти.