In Azure VM oanslute by Entra Domain Services: beslute earst
Trije besluten komme foar it oansluten: it mapmodel dat de wurklêst nedich hat, privee DNS dat it domein oplost, en in akkount dat ferifiearje kin.
Trije besluten steane foar in Windows Server VM dy't in beheard map brûke moat, en it oanslútkommando is de lytste fan har. Kies it ferkearde mapmodel en it oansluten slagget wylst de applikaasje noch altyd net ferifiearje kin. Krijst de namme-oplossing ferkeard en de flater ferskynt op in punt dat as in probleem mei oanmeldgegevens liket.
Beslute it model, de oplossing en it akkount foar't jo de tsjinner oanreitsje, dan rint it kommando ien kear.
Hokker fan de trije oanslutingen jo eins wolle
In apparaat-oansluting registrearret in masine by Microsoft Entra ID foar betingstjochtagong en ienige oanmelding, en it jout de wurklêst gjin Kerberos-ticket nei in domein yn pleatslike styl. In tradisjonele domein-oansluting bynt in kompjûterobjekt yn in map en jout it in masine-akkount, groepsbelied en domeinferifikaasje. In beheard domein biedt dat twadde model as tsjinst. De nammen klinke itselde en de útkomsten net.
Allinnich de lêste twa belûke in domeinbehearder yn 'e gewoane sin, en allinnich de behearde opsje hellet de tsjinners fan jo patchlist.
It beslút hinget meast fan 'e applikaasje ôf en net fan foarkar. Software dy't in LDAP-bining, in tsjinstakkount mei in SPN of groepsbeliedsobjekten wol, heart yn it domeinmodel. Software dy't allinnich de identiteit fan 'e brûker op in bedriuwsapparaat witte moat, heart der meast net yn.
| 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 |
It DNS-paad beslút oft it oansluten klear komme kin
In domein-oansluting begjint mei in lokator-syktocht nei de behearderrecords fan it domein, dus namme-oplossing moat wurkje foar't hokker oanmeldgegevens dan ek kontrolearre wurde. Rjochtsje de VM op 'e mapadressen fan it behearde domein, itsij fia de DNS-ynstellingen fan it firtuele netwurk, itsij fia in betingst trochstjoerder dy't allinnich dy nammeromte dêrhinne stjoert. In trochstjoerder beheind ta de nammeromte is meast de feiliger kar, want it lit de rest fan 'e oplossing fan 'e VM gewurde.
Test de lokator en net in keale hostnamme. In ping nei de domeinnamme bewiist hast neat, wylst in SRV-fraach nei de behearderrecords fan it domein itsij de ferwachte doelen jout, itsij daliks mislearret:
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
Ferfang de domeinnamme en de twa adressen troch de wearden út jo konfiguraasje fan it behearde domein; de sifers hjir binne foarbylden. As de fraach antwurden fan in oare sône jout, brûkt de VM in oplosser dy't de behearde nammeromte net trochstjoert, en gjin hoefolle it oansluten ek werhelle wurdt, dat feroaret dat net.
Hâld de wurklêst bûten it subnet dat it behearde domein foar syn eigen tsjinstboarnen reservearret, en hâld de mappoarten op it priveepaad. It iepenbier bleatstellen fan dy poarten is gjin fluchwei; it is in oar ûntwerp mei in oar risikoprofyl.
De geskiktheid fan it akkount wurdt foar de masine kontrolearre
It akkount dat it oansluten docht hat tastimming nedich om in kompjûterobjekt yn 'e doelcontainer te meitsjen, en it moat him by it behearde domein ferifiearje kinne. In allinnich-wolk-akkount dat makke is foar't it behearde domein bestie, hat miskien net it fan wachtwurd ôflate materiaal dat it domein nedich hat, en in wachtwurdferoaring of -reset makket it op 'e nij. Dat detail ferklearret in klasse oanslútflaters dy't as ferkearde wachtwurden lykje as it wachtwurd goed is. Test de oanmeldgegevens by it domein foar't it ûnderhâldsraam iepengiet.
Syngronisearre hybride akkounts hawwe har eigen betingsten dy't in sichtber brûkersobjekt allinnich net ferfollet. Yn 'e map neamd wêze is net itselde as in ticket dêrút helje kinne, dus test it akkount foar it ûnderhâldsraam en net derûnder.
Delegearje it rjocht fan oansluten smel. Eltse takomstige tsjinnerbrûker domeinbehearder-lidmaatskip jaan sadat ien ynskriuwing barre kin, is in bliuwende tastimming foar in tydlik probleem.
It oansluten sels is ien kommando
Mei it model keazen, DNS dat antwurdet en it akkount geskikt, is de operaasje de gewoane Windows-operaasje. De opdracht hâldt it wachtwurd bûten skripts en shell-skiednis:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThru
It kommando start de masine yn dizze foarm net fansels opnij, dus de werstart bart ûnder it ûnderhâldsplan en mei it herstelpaad noch beskikber. In tsjinner dy't al by in oar domein oansletten is, hat in migraasjeplan nedich, net in twadde oansluting oer de earste hinne.
Skriuw de container op dêr't it kompjûterobjekt yn bedarre en it akkount dat it makke hat. Beide binne fan belang as de masine nei in werbou op 'e nij oansletten wurde moat, en gjin fan beide is efterôf fan 'e tsjinner ôf dúdlik.
Wat lidmaatskip net jout
Domeinlidmaatskip makket nimmen pleatslik behearder, en it jout gjin tagong ta ôfstânburoblêd of bestânsdieling. Dy rjochten wurde apart konfigurearre, en op in beheard domein bliuwe se binnen syn stipe bestjoerlike berik.
It netwurkpaad is in oanhâldende ôfhinklikens en net in ynstappestap. As de priveeferbining ferdwynt, bliuwt de tsjinner draaien mei bewarre oanmeldgegevens oant eat de map nedich hat, en dan komt de flater yn in applikaasjelog en net njonken de konfiguraasje dy't feroare is.
Microsoft syn hânlieding foar Windows Server-oansluting neamt de stipe betingsten foar de wurkstream fan it behearde domein. Lês it tsjin de trije besluten hjirboppe oan, en behannelje elke ôfwiking as in reden om te stopjen en net as in detail om om te rinnen.