Conectarea unui VM Azure la Entra Domain Services: decideți mai întâi

Trei decizii stau în fața unui VM Windows Server care trebuie să folosească un director administrat, iar comanda de conectare este cea mai mică dintre ele. Alegeți modelul de director greșit și conectarea reușește în timp ce aplicația tot nu se poate autentifica. Greșiți rezolvarea numelor și defecțiunea apare într-un punct care pare o problemă de acreditări.

Stabiliți modelul, rezolvarea și contul înainte de a atinge serverul, apoi comanda rulează o dată.

Care dintre cele trei conectări o doriți de fapt

Conectarea dispozitivului înregistrează o mașină în Microsoft Entra ID pentru acces condiționat și autentificare unică și nu oferă încărcării de lucru niciun bilet Kerberos către un domeniu în stil local. Conectarea tradițională la domeniu leagă un obiect de computer într-un director și îi dă un cont de mașină, politică de grup și autentificare de domeniu. Un domeniu administrat oferă acel al doilea model ca serviciu. Numele sună similar, iar rezultatele nu.

Doar ultimele două implică un controler de domeniu în sensul obișnuit, iar doar opțiunea administrată scoate serverele de pe lista dumneavoastră de patch-uri.

Decizia depinde de obicei de aplicație, nu de preferință. Software-ul care vrea o legare LDAP, un cont de serviciu cu un SPN sau obiecte de politică de grup aparține modelului de domeniu. Software-ul care trebuie doar să cunoască identitatea utilizatorului pe un dispozitiv corporate de obicei nu aparține.

Calea DNS decide dacă conectarea se poate încheia

O conectare la domeniu începe cu o căutare a localizatorului pentru înregistrările controlerului domeniului, așa că rezolvarea numelor trebuie să funcționeze înainte de verificarea oricărei acreditări. Îndreptați VM-ul către adresele de director ale domeniului administrat, fie prin setările DNS ale rețelei virtuale, fie printr-un redirector condiționat care trimite acolo doar acel spațiu de nume. Un redirector limitat la spațiul de nume este de obicei alegerea mai sigură, pentru că lasă restul rezolvării VM-ului în pace.

Testați localizatorul, nu un nume de gazdă gol. Un ping către numele domeniului nu demonstrează aproape nimic, în timp ce o interogare SRV pentru înregistrările controlerului domeniului fie returnează țintele așteptate, fie eșuează imediat:

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

Înlocuiți numele domeniului și cele două adrese cu valorile din configurația domeniului administrat; numerele de aici sunt exemple. Dacă interogarea returnează răspunsuri din altă zonă, VM-ul folosește un rezolvator care nu redirecționează spațiul de nume administrat, iar niciun număr de repetări ale conectării nu va schimba asta.

Țineți încărcarea de lucru în afara subrețelei pe care domeniul administrat o rezervă pentru propriile resurse de serviciu și țineți porturile directorului pe calea privată. Expunerea publică a acestor porturi nu este o scurtătură; este un design diferit cu un profil de risc diferit.

Eligibilitatea contului este verificată înaintea mașinii

Contul care efectuează conectarea are nevoie de permisiunea de a crea un obiect de computer în containerul țintă și trebuie să se poată autentifica față de domeniul administrat. Un cont doar în cloud creat înainte de existența domeniului administrat poate să nu aibă materialul derivat din parolă de care domeniul are nevoie, iar o schimbare sau resetare a parolei îl regenerează. Acest detaliu explică o clasă de eșecuri de conectare care arată ca parole greșite atunci când parola este corectă. Testați acreditarea față de domeniu înainte de deschiderea ferestrei de mentenanță.

Conturile hibride sincronizate au propriile condiții prealabile pe care un obiect de utilizator vizibil nu le îndeplinește singur. A fi listat în director nu este același lucru cu a putea obține un bilet din el, așa că testați contul înainte de fereastra de mentenanță, nu în timpul ei.

Delegați dreptul de conectare îngust. A da fiecărui viitor utilizator de server calitatea de membru al administratorilor de domeniu pentru ca o singură înscriere să aibă loc este o acordare permanentă pentru o problemă temporară.

Conectarea în sine este o singură comandă

Cu modelul ales, DNS-ul răspunzând și contul eligibil, operațiunea este cea obișnuită din Windows. Promptul ține parola în afara scripturilor și a istoricului shell-ului:

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

Comanda nu repornește mașina de la sine în această formă, așa că repornirea are loc conform planului de mentenanță și cu calea de recuperare încă disponibilă. Un server deja conectat la alt domeniu are nevoie de un plan de migrare, nu de o a doua conectare peste prima.

Notați containerul în care a ajuns obiectul de computer și contul care l-a creat. Ambele contează când mașina trebuie reconectată după o reconstrucție, iar niciunul nu este evident din server ulterior.

Ce nu acordă calitatea de membru

Calitatea de membru al domeniului nu face pe nimeni administrator local și nu acordă acces la desktop la distanță sau la partajări de fișiere. Acele drepturi se configurează separat, iar într-un domeniu administrat rămân în aria sa administrativă acceptată.

Calea de rețea este o dependență continuă, nu un pas de configurare. Dacă conexiunea privată dispare, serverul continuă să funcționeze cu acreditări din cache până când ceva are nevoie de director, iar atunci defecțiunea apare într-un jurnal de aplicație, nu lângă configurația care s-a schimbat.

Ghidul Microsoft pentru conectarea Windows Server enumeră condițiile prealabile acceptate pentru fluxul de lucru cu domeniu administrat. Citiți-l față de cele trei decizii de mai sus și tratați orice nepotrivire ca motiv de oprire, nu ca detaliu de ocolit.