Kunligi Azure VM al Entra Domain Services: unue decidu
Tri decidoj antaŭas la kunligon: la dosieruja modelo, kiun la laborŝarĝo bezonas, privata DNS, kiu solvas la domajnon, kaj konto kapabla aŭtentikigi.
Tri decidoj staras antaŭ Windows Server VM, kiu devas uzi administritan dosierujon, kaj la kunliga komando estas la plej malgranda el ili. Elektu la malĝustan dosierujan modelon kaj la kunligo sukcesas, dum la aplikaĵo ankoraŭ ne povas aŭtentikigi. Eraru pri nomrezolucio kaj la fiasko aperas en punkto, kiu aspektas kiel problemo pri akreditaĵoj.
Decidu la modelon, la rezolucion kaj la konton antaŭ ol tuŝi la servilon, tiam la komando ruliĝas unufoje.
Kiun el la tri kunligoj vi vere volas
Aparata kunligo registras maŝinon ĉe Microsoft Entra ID por kondiĉa aliro kaj unuopa ensaluto, kaj ĝi donas al la laborŝarĝo neniun Kerberos-bileton al domajno laŭloka stilo. Tradicia domajna kunligo ligas komputilan objekton en dosierujon kaj donas al ĝi maŝinan konton, grupajn politikojn kaj domajnan aŭtentikigon. Administrita domajno provizas tiun duan modelon kiel servon. La nomoj sonas similaj kaj la rezultoj ne.
Nur la lastaj du implikas domajnan regilon laŭ la ordinara senco, kaj nur la administrita opcio forigas la servilojn de via flika listo.
La decido kutime dependas de la aplikaĵo, ne de prefero. Programaro, kiu volas LDAP-ligon, servan konton kun SPN aŭ grupajn politikajn objektojn, apartenas al la domajna modelo. Programaro, kiu nur bezonas scii la identecon de la uzanto sur kompania aparato, kutime ne apartenas.
| 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 |
La DNS-vojo decidas, ĉu la kunligo povas finiĝi
Domajna kunligo komenciĝas per lokizita serĉo de la regilaj rikordoj de la domajno, do nomrezolucio devas funkcii antaŭ ol iu ajn akreditaĵo estas kontrolita. Direktu la VM al la dosierujaj adresoj de la administrita domajno, jen per la DNS-agordoj de la virtuala reto, jen per kondiĉa plusendilo, kiu sendas nur tiun nomspacon tien. Plusendilo limigita al la nomspaco estas kutime la pli sekura elekto, ĉar ĝi lasas la reston de la rezolucio de la VM trankvila.
Testu la lokizilon, ne nudan gastigantan nomon. Ping al la domajna nomo pruvas preskaŭ nenion, dum SRV-demando pri la regilaj rikordoj aŭ redonas la atenditajn celojn aŭ tuj fiaskas:
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 53Anstataŭigu la domajnan nomon kaj la du adresojn per la valoroj el via administrita domajna agordo; la nombroj ĉi tie estas ekzemploj. Se la demando redonas respondojn de alia zono, la VM uzas solvilon, kiu ne plusendas la administritan nomspacon, kaj neniu kvanto da ripeto de la kunligo tion ŝanĝos.
Tenu la laborŝarĝon ekster la subreto, kiun la administrita domajno rezervas por siaj propraj servaj rimedoj, kaj tenu la dosierujajn pordojn sur la privata vojo. Publika elmontro de tiuj pordoj ne estas fuŝrimedo; ĝi estas alia dizajno kun alia riskprofio.
Konta taŭgeco estas kontrolita antaŭ la maŝino
La konto, kiu plenumas la kunligon, bezonas permeson krei komputilan objekton en la celujo, kaj ĝi devas povi aŭtentikigi kontraŭ la administrita domajno. Nura nuba konto kreita antaŭ ol la administrita domajno ekzistis eble mankas la pasvortderivitan materialon, kiun la domajno bezonas, kaj pasvorta ŝanĝo aŭ restarigo ĝin regeneras. Tiu detalo klarigas klason de kunligaj fiaskoj, kiuj aspektas kiel malĝustaj pasvortoj kiam la pasvorto estas ĝusta. Testu la akreditaĵon kontraŭ la domajno antaŭ ol malfermiĝos la prizorga fenestro.
Sinkronigitaj hibridaj kontoj havas proprajn antaŭkondiĉojn, kiujn videbla uzanta objekto ne plenumas sola. Esti listigita en la dosierujo ne samas kiel povi ricevi bileton el ĝi, do testu la konton antaŭ la prizorga fenestro, ne dum ĝi.
Delegu la kunligan rajton mallarĝe. Diri al ĉiu estonta servila uzanto membrecon de domajna administranto nur por ke okazu unu registriĝo estas konstanta permeso por provizora problemo.
La kunligo mem estas unu komando
Kun la modelo elektita, DNS respondanta kaj la konto taŭga, la operacio estas la ordinara Windows-operacio. La invito tenas la pasvorton ekster skriptoj kaj ŝela historio:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThruLa komando ne restartigas la maŝinon mem en ĉi tiu formo, do la restartigo okazas laŭ la prizorga plano kaj kun la reakira vojo ankoraŭ disponebla. Servilo jam kunligita al alia domajno bezonas migran planon, ne duan kunligon sur la unua.
Notu la ujon, en kiun alteriĝis la komputila objekto, kaj la konton, kiu kreis ĝin. Ambaŭ gravas kiam la maŝino devas esti rekunligita post rekonstruo, kaj neniu el ili estas evidenta de la servilo poste.
Kion membreco ne donas
Domajna membreco ne faras iun lokan administranton, kaj ĝi ne donas aliron al fora labortablo aŭ dosierkomunigoj. Tiuj rajtoj estas agorditaj aparte, kaj en administrita domajno ili restas ene de ĝia subtenata administra amplekso.
La reta vojo estas daŭra dependeco, ne agorda paŝo. Se la privata konekto malaperas, la servilo daŭre funkcias kun kaŝmemoraj akreditaĵoj ĝis io bezonas la dosierujon, kaj tiam la fiasko alvenas en aplikaĵa protokolo, ne apud la agordo, kiu ŝanĝiĝis.
La gvidilo de Microsoft pri kunligo de Windows Server listigas la subtenatajn antaŭkondiĉojn por la laborfluo de administrita domajno. Legu ĝin kontraŭ la tri decidoj supre, kaj traktu ajnan malkongruon kiel kialon halti, ne kiel detalon por ĉirkaŭiri.