Om ’n Azure-VM by Entra Domain Services aan te sluit: besluit eers
Drie besluite kom voor die aansluiting: die gidsmodel wat die werklading nodig het, private DNS wat die domein oplos, en ’n rekening wat kan verifieer.
Drie besluite staan voor ’n Windows Server-VM wat ’n bestuurde gids moet gebruik, en die aansluitbevel is die kleinste daarvan. Kies die verkeerde gidsmodel en die aansluiting slaag terwyl die toepassing steeds nie kan verifieer nie. Kry naamresolusie verkeerd en die fout verskyn op ’n punt wat soos ’n geloofwaardigheidsprobleem lyk.
Beslis die model, die resolusie en die rekening voordat jy aan die bediener raak, dan loop die bevel een keer.
Watter van die drie aansluitings jy eintlik wil hê
’n Toestelaansluiting registreer ’n masjien by Microsoft Entra ID vir voorwaardelike toegang en enkelmeldingsaanmelding, en dit gee die werklading geen Kerberos-kaartjie na ’n gids in die plaaslike styl nie. ’n Tradisionele domeinaansluiting bind ’n rekenaarobjek in ’n gids en gee dit ’n masjienrekening, groepbeleid en domeinverifikasie. ’n Bestuurde domein bied daardie tweede model as ’n diens. Die name klink soortgelyk en die uitkomste nie.
Net die laaste twee behels ’n domeinbeheerder in die gewone sin, en net die bestuurde opsie verwyder die bedieners van jou pleisterlys.
Die besluit hang gewoonlik aan die toepassing eerder as aan voorkeur. Sagteware wat ’n LDAP-bind, ’n diensrekening met ’n SPN of groepbeleidsobjekte wil hê, hoort in die domeinmodel. Sagteware wat net die gebruiker se identiteit op ’n korporatiewe toestel hoef te ken, hoort gewoonlik nie.
| 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 |
Die DNS-pad bepaal of die aansluiting kan klaarmaak
’n Domeinaansluiting begin met ’n opsoek na die gids se beheerderrekords, so naamresolusie moet werk voordat enige geloofsbrief nagegaan word. Wys die VM na die bestuurde domein se gidsadresse, hetsy deur die virtuele netwerk se DNS-instellings of deur ’n voorwaardelike aanstuurder wat net daardie naamruimte daarheen stuur. ’n Aanstuurder wat tot die naamruimte beperk is, is gewoonlik die veiliger keuse, want dit laat die res van die VM se resolusie alleen.
Toets die opsoeker eerder as ’n blote gasheernaam. ’n Ping na die domeinnaam bewys byna niks, terwyl ’n SRV-navraag vir die domeinbeheerderrekords óf die verwagte teikens teruggee óf onmiddellik misluk:
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 53Vervang die domeinnaam en die twee adresse met die waardes uit jou bestuurde domeinkonfigurasie; die nommers hier is voorbeelde. As die navraag ’n ander sone se antwoorde teruggee, gebruik die VM ’n oplosser wat nie die bestuurde naamruimte aanstuur nie, en geen hoeveelheid herprobeer van die aansluiting sal dit verander nie.
Hou die werklading uit die subnet wat die bestuurde domein vir sy eie diensbronne reserveer, en hou die gidspoorte op die private pad. Openbare blootstelling van daardie poorte is nie ’n kortpad nie; dit is ’n ander ontwerp met ’n ander risikoprofiel.
Rekeninggeskiktheid word voor die masjien nagegaan
Die rekening wat die aansluiting doen, het toestemming nodig om ’n rekenaarobjek in die teikenhouer te skep, en dit moet teen die bestuurde domein kan verifieer. ’n Slegs-wolk-rekening wat geskep is voordat die bestuurde domein bestaan het, het dalk nie die wagwoordafgeleide materiaal wat die domein nodig het nie, en ’n wagwoordverandering of herstel genereer dit weer. Daardie detail verduidelik ’n klas aansluitfoute wat soos verkeerde wagwoorde lyk wanneer die wagwoord korrek is. Toets die geloofsbrief teen die domein voordat die onderhoudsvenster oopgaan.
Gesinkroniseerde hibriede rekeninge het hul eie voorvereistes wat ’n sigbare gebruikerobjek nie op sy eie bevredig nie. Om in die gids gelys te wees is nie dieselfde as om ’n kaartjie daaruit te kan kry nie, so toets die rekening voor die onderhoudsvenster eerder as tydens dit.
Delegeer die aansluitreg nou. Om elke toekomstige bedienergebruiker domeinbeheerderlidmaatskap te gee sodat een inskrywing kan gebeur, is ’n permanente toekenning vir ’n tydelike probleem.
Die aansluiting self is een bevel
Met die model gekies, DNS wat antwoord en die rekening geskik, is die bewerking die gewone Windows-een. Die opdrag hou die wagwoord uit skrifte en dopgeskiedenis:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThruDie bevel herbegin nie die masjien op sy eie in hierdie vorm nie, so die herbegin gebeur onder die onderhoudsplan en met die herstelpad steeds beskikbaar. ’n Bediener wat reeds by ’n ander domein aangesluit is, het ’n migrasieplan nodig, nie ’n tweede aansluiting bo-op die eerste nie.
Teken die houer aan waarin die rekenaarobjek beland het en die rekening wat dit geskep het. Beide maak saak wanneer die masjien ná ’n herbouing weer aangesluit moet word, en nie een is agterna van die bediener af duidelik nie.
Wat lidmaatskap nie gee nie
Domeinlidmaatskap maak nie iemand ’n plaaslike administrateur nie, en dit gee nie toegang tot afstandrekenaar of lêerdeling nie. Daardie regte word afsonderlik opgestel, en op ’n bestuurde domein bly hulle binne sy ondersteunde administratiewe omvang.
Die netwerkpad is ’n voortdurende afhanklikheid eerder as ’n opstelstap. As die private verbinding verdwyn, hou die bediener aan loop met gekaste geloofsbriewe totdat iets die gids nodig het, en dan kom die fout in ’n toepassingslogboek eerder as langs die konfigurasie wat verander het.
Microsoft se leiding vir Windows Server-aansluiting lys die ondersteunde voorvereistes vir die bestuurde-domein-werkvloei. Lees dit teen die drie besluite hierbo, en beskou enige wanverhouding as ’n rede om te stop eerder as ’n detail om te omseil.