Pag-uugnay ng VM ng Azure sa Entra Domain Services: magpasya muna
Tatlong desisyon ang nauuna sa pag-uugnay: ang modelo ng direktoryo na kailangan ng workload, pribadong DNS na lumulutas ng domain, at account na makapagpapatotoo.
Tatlong desisyon ang nakatayo sa harap ng VM ng Windows Server na kailangang gumamit ng pinamamahalaang direktoryo, at ang utos ng pag-uugnay ang pinakamaliit sa kanila. Pumili ng maling modelo ng direktoryo at magtatagumpay ang pag-uugnay habang hindi pa rin makapagpapatotoo ang aplikasyon. Magkamali sa resolusyon ng pangalan at lalabas ang pagkabigo sa puntong mukhang problema sa kredensyal.
Ayusin ang modelo, ang resolusyon at ang account bago hawakan ang server, pagkatapos ay tatakbo ang utos nang isang beses.
Alin sa tatlong pag-uugnay ang talagang gusto mo
Ang pag-uugnay ng aparato ay nagrerehistro ng makina sa Microsoft Entra ID para sa kondisyonal na pag-access at iisang pag-sign in, at hindi ito nagbibigay sa workload ng anumang tiket ng Kerberos patungo sa domain na lokal ang estilo. Ang tradisyonal na pag-uugnay ng domain ay nagbibigkis ng object ng computer sa isang direktoryo at nagbibigay dito ng account ng makina, patakaran ng grupo at pagpapatotoo ng domain. Ang pinamamahalaang domain ay nag-aalok ng pangalawang modelong iyon bilang serbisyo. Magkatulad ang tunog ng mga pangalan at hindi ang mga resulta.
Ang huling dalawa lamang ang may kinalaman sa controller ng domain sa karaniwang kahulugan, at ang pinamamahalaang opsyon lamang ang nag-aalis ng mga server sa iyong listahan ng patch.
Ang desisyon ay karaniwang nakasalalay sa aplikasyon at hindi sa kagustuhan. Ang software na gustong ng LDAP bind, account ng serbisyo na may SPN, o mga object ng patakaran ng grupo ay kabilang sa modelo ng domain. Ang software na kailangan lamang malaman ang pagkakakilanlan ng gumagamit sa isang aparato ng kumpanya ay karaniwang hindi kabilang.
| Model | What the server gets | Where it appears |
|---|---|---|
| Entra device join | Device identity and conditional access signals | Microsoft Entra ID |
| Managed domain join | Machine account, Kerberos, group policy | The managed directory |
| Self-hosted AD DS | The same, plus every controller you operate | Your own forest |
Ang landas ng DNS ang nagpapasya kung matatapos ang pag-uugnay
Ang pag-uugnay ng domain ay nagsisimula sa paghahanap ng locator para sa mga record ng controller ng domain, kaya kailangang gumana ang resolusyon ng pangalan bago suriin ang anumang kredensyal. Ituro ang VM sa mga address ng direktoryo ng pinamamahalaang domain, sa pamamagitan ng mga setting ng DNS ng virtual network o ng kondisyonal na forwarder na nagpapadala lamang ng namespace na iyon doon. Ang forwarder na limitado sa namespace ay karaniwang ang mas ligtas na pagpipilian, dahil iniiwan nitong tahimik ang natitirang resolusyon ng VM.
Subukan ang locator at hindi isang hubad na pangalan ng host. Ang ping sa pangalan ng domain ay halos walang pinapatunayan, samantalang ang SRV query para sa mga record ng controller ng domain ay ibinabalik ang inaasahang target o agad na nabigo:
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
Palitan ang pangalan ng domain at ang dalawang address ng mga halaga mula sa configuration ng iyong pinamamahalaang domain; ang mga numero rito ay halimbawa. Kung ang query ay nagbabalik ng mga sagot mula sa ibang zone, gumagamit ang VM ng resolver na hindi nagpapasa ng pinamamahalaang namespace, at hindi iyon mababago gaano man karaming ulit na gawin ang pag-uugnay.
Ilayo ang workload sa subnet na inilalaan ng pinamamahalaang domain para sa sarili nitong mga resource ng serbisyo, at panatilihin ang mga port ng direktoryo sa pribadong landas. Ang pampublikong paglantad ng mga port na iyon ay hindi shortcut; ito ay ibang disenyo na may ibang profile ng panganib.
Ang pagiging karapat-dapat ng account ay sinusuri bago ang makina
Ang account na gumagawa ng pag-uugnay ay nangangailangan ng pahintulot na lumikha ng object ng computer sa target na container, at kailangan nitong makapagpapatotoo sa pinamamahalaang domain. Ang account na cloud lamang na ginawa bago umiral ang pinamamahalaang domain ay maaaring kulang sa materyal na nagmula sa password na kailangan ng domain, at ang pagbabago o pag-reset ng password ay muling lumilikha nito. Ipinapaliwanag ng detalyeng iyon ang isang uri ng pagkabigo sa pag-uugnay na mukhang maling password kapag tama ang password. Subukan ang kredensyal sa domain bago magbukas ang window ng maintenance.
Ang mga naka-sync na hybrid na account ay may sariling mga paunang kundisyon na hindi natutugunan ng nakikitang object ng gumagamit nang mag-isa. Ang maitala sa direktoryo ay hindi kapareho ng makakuha ng tiket mula rito, kaya subukan ang account bago ang window ng maintenance at hindi habang ito ay bukas.
Itakda ang karapatan sa pag-uugnay nang makitid. Ang bigyan ang bawat hinaharap na gumagamit ng server ng pagiging miyembro ng administrator ng domain upang maganap ang isang enrollment ay isang permanenteng pagbibigay para sa pansamantalang problema.
Ang pag-uugnay mismo ay isang utos lamang
Kapag napili ang modelo, sumasagot ang DNS at karapat-dapat ang account, ang operasyon ay ang karaniwang operasyon sa Windows. Pinapanatili ng prompt ang password sa labas ng mga script at ng kasaysayan ng shell:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru
Ang utos sa anyong ito ay hindi kusang nagre-restart ng makina, kaya ang restart ay nangyayari sa ilalim ng plano ng maintenance at may landas pa ng pagbawi. Ang server na nakaugnay na sa ibang domain ay nangangailangan ng plano ng paglilipat, hindi ng pangalawang pag-uugnay sa ibabaw ng una.
Itala ang container kung saan lumapag ang object ng computer at ang account na lumikha nito. Mahalaga ang dalawa kapag kailangang muling iugnay ang makina pagkatapos ng muling pagtatayo, at wala sa kanila ang halata mula sa server pagkatapos.
Ang hindi ibinibigay ng pagiging miyembro
Ang pagiging miyembro ng domain ay hindi gumagawang lokal na administrator sa sinuman, at hindi nagbibigay ng access sa remote desktop o file sharing. Ang mga karapatang iyon ay naka-configure nang hiwalay, at sa pinamamahalaang domain ay nananatili sila sa loob ng sinusuportahang saklaw ng administratibo nito.
Ang landas ng network ay patuloy na dependency at hindi hakbang sa setup. Kung mawala ang pribadong koneksyon, patuloy na tumatakbo ang server na may naka-cache na kredensyal hanggang may kailangan ng direktoryo, at pagkatapos ay dumarating ang pagkabigo sa log ng aplikasyon at hindi sa tabi ng configuration na nagbago.
Ang gabay ng Microsoft para sa pag-uugnay ng Windows Server ay naglilista ng mga sinusuportahang paunang kundisyon para sa workflow ng pinamamahalaang domain. Basahin ito laban sa tatlong desisyon sa itaas, at ituring ang anumang pagkakaiba bilang dahilan upang huminto at hindi bilang detalyeng dapat iwasan.