Присъединяване на Azure VM към Entra Domain Services: първо решението

Три решения стоят пред VM с Windows Server, която трябва да използва управлявана директория, а командата за присъединяване е най-малкото от тях. Изберете грешен модел на директорията и присъединяването успява, докато приложението все още не може да се удостовери. Сбъркайте разрешаването на имена и отказът се появява на място, което изглежда като проблем с идентификационни данни.

Решете модела, разрешаването и акаунта, преди да докоснете сървъра, и след това командата се изпълнява веднъж.

Кое от трите присъединявания всъщност искате

Присъединяването на устройство регистрира машина в Microsoft Entra ID за условен достъп и еднократен вход и не дава на натоварването билет Kerberos към домейн в локален стил. Традиционното присъединяване към домейн свързва компютърен обект в директория и му дава машинен акаунт, групова политика и удостоверяване в домейна. Управляваният домейн предоставя този втори модел като услуга. Имената звучат подобно, а резултатите — не.

Само последните две включват контролер на домейн в обичайния смисъл и само управляваната опция премахва сървърите от списъка ви за пачове.

Решението обикновено зависи от приложението, а не от предпочитанията. Софтуер, който иска LDAP bind, сервизен акаунт с SPN или обекти на групова политика, принадлежи на модела с домейн. Софтуер, който само трябва да знае самоличността на потребителя на корпоративно устройство, обикновено не принадлежи.

Пътят на DNS решава дали присъединяването може да завърши

Присъединяването към домейн започва с търсене на локатор за записите на контролерите на домейна, така че разрешаването на имена трябва да работи преди проверката на каквито и да е идентификационни данни. Насочете VM към адресите на директорията на управлявания домейн — чрез DNS настройките на виртуалната мрежа или чрез условен препращач, който изпраща само това пространство от имена към тях. Препращач, ограничен до пространството от имена, обикновено е по-безопасният избор, защото оставя останалото разрешаване на VM непокътнато.

Тествайте локатора, а не голо име на хост. Ping към името на домейна не доказва почти нищо, докато 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

Заменете името на домейна и двата адреса със стойностите от конфигурацията на управлявания домейн; числата тук са примери. Ако заявката връща отговори от друга зона, VM използва резолвер, който не препраща управляваното пространство от имена, и никакво повторение на присъединяването няма да промени това.

Дръжте натоварването извън подмрежата, която управляваният домейн запазва за собствените си служебни ресурси, и дръжте портовете на директорията по частния път. Публичното излагане на тези портове не е пряк път; това е различен дизайн с различен профил на риска.

Правото на акаунта се проверява преди машината

Акаунтът, който извършва присъединяването, се нуждае от разрешение да създаде компютърен обект в целевия контейнер и трябва да може да се удостовери в управлявания домейн. Акаунт само в облака, създаден преди управляваният домейн да съществува, може да няма производния от парола материал, от който домейнът се нуждае, а смяната или нулирането на паролата го генерира наново. Тази подробност обяснява клас откази при присъединяване, които изглеждат като грешни пароли, когато паролата е вярна. Тествайте идентификационните данни срещу домейна преди отварянето на прозореца за поддръжка.

Синхронизираните хибридни акаунти имат свои предпоставки, които видим потребителски обект не удовлетворява сам по себе си. Да бъдеш изброен в директорията не е същото като да можеш да получиш билет от нея, затова тествайте акаунта преди прозореца за поддръжка, а не по време на него.

Делегирайте правото за присъединяване тясно. Даването на всеки бъдещ потребител на сървъра членство на администратор на домейна, за да се случи едно записване, е постоянно разрешение за временен проблем.

Самото присъединяване е една команда

С избран модел, отговарящ DNS и подходящ акаунт операцията е обичайната за Windows. Подканата държи паролата извън скриптове и история на обвивката:

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

Командата не рестартира машината сама в тази форма, така че рестартът се случва по плана за поддръжка и с все още наличен път за възстановяване. Сървър, вече присъединен към друг домейн, се нуждае от план за миграция, а не от второ присъединяване върху първото.

Запишете контейнера, в който е попаднал компютърният обект, и акаунта, който го е създал. И двете имат значение, когато машината трябва да бъде присъединена отново след преизграждане, и нито едно от тях не е очевидно от сървъра след това.

Какво не дава членството

Членството в домейн не прави никого локален администратор и не дава достъп до отдалечен работен плот или файлови споделяния. Тези права се конфигурират отделно и в управляван домейн остават в рамките на поддържания му административен обхват.

Мрежовият път е постоянна зависимост, а не стъпка при настройката. Ако частната връзка изчезне, сървърът продължава да работи с кеширани идентификационни данни, докато нещо се нуждае от директорията, и тогава отказът пристига в журнал на приложение, а не до конфигурацията, която се е променила.

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