Azure VM-ը Entra Domain Services-ին միացնելը՝ սկզբում որոշեք
Միացումից առաջ երեք որոշում կա՝ աշխատանքային բեռին անհրաժեշտ գրացուցակի մոդելը, տիրույթը լուծող մասնավոր DNS-ը և նույնականացում կատարել կարող հաշիվը։
Windows Server VM-ի առջև կանգնած են երեք որոշում, որին պետք է օգտագործել կառավարվող գրացուցակ, և միացման հրամանը դրանցից ամենափոքրն է։ Ընտրեք սխալ գրացուցակի մոդել, և միացումը կհաջողվի, մինչդեռ հավելվածը դեռ չի կարող նույնականացնել։ Սխալվեք անունների լուծման մեջ, և խափանումը կհայտնվի մի կետում, որը նման է հավատարմագրերի խնդրի։
Որոշեք մոդելը, լուծումը և հաշիվը նախքան սերվերին դիպչելը, ապա հրամանը կաշխատի մեկ անգամ։
Երեք միացումներից որն եք իրականում ուզում
Սարքի միացումը գրանցում է մեքենան Microsoft Entra ID-ում պայմանական հասանելիության և միասնական մուտքի համար և աշխատանքային բեռին Kerberos տոմս չի տալիս տեղական ոճի տիրույթին։ Ավանդական տիրույթի միացումը կապում է համակարգչային օբյեկտը գրացուցակում և տալիս նրան մեքենայի հաշիվ, խմբի քաղաքականություն և տիրույթի նույնականացում։ Կառավարվող տիրույթը տրամադրում է այդ երկրորդ մոդելը որպես ծառայություն։ Անունները հնչում են նման, իսկ արդյունքները՝ ոչ։
Միայն վերջին երկուսն են ներառում տիրույթի կառավարիչ սովորական իմաստով, և միայն կառավարվող տարբերակն է հանում սերվերները ձեր կարկատան ցանկից։
Որոշումը սովորաբար կախված է հավելվածից, ոչ թե նախապատվությունից։ Ծրագրաշարը, որն ուզում է LDAP կապ, SPN-ով ծառայության հաշիվ կամ խմբի քաղաքականության օբյեկտներ, պատկանում է տիրույթի մոդելին։ Ծրագրաշարը, որին պարզապես պետք է իմանալ օգտատիրոջ ինքնությունը կորպորատիվ սարքում, սովորաբար չի պատկանում։
| 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 |
DNS ուղին է որոշում՝ միացումը կարող է ավարտվել, թե ոչ
Տիրույթի միացումը սկսվում է տիրույթի կառավարչի գրառումների տեղորոշիչի որոնմամբ, ուստի անունների լուծումը պետք է աշխատի նախքան որևէ հավատարմագիր ստուգելը։ Ուղղեք VM-ը կառավարվող տիրույթի գրացուցակի հասցեներին՝ կա՛մ վիրտուալ ցանցի DNS կարգավորումների միջոցով, կա՛մ պայմանական փոխանցիչի միջոցով, որը միայն այդ անվանատարածքն է ուղարկում այնտեղ։ Անվանատարածքով սահմանափակված փոխանցիչը սովորաբար ավելի անվտանգ ընտրություն է, որովհետև թողնում է VM-ի մնացած լուծումը անփոփոխ։
Փորձարկեք տեղորոշիչը, ոչ թե մերկ հոսթի անուն, քանի որ տիրույթի անվանը ping-ը գրեթե ոչինչ չի ապացուցում, մինչդեռ կառավարչի գրառումների SRV հարցումը կա՛մ վերադարձնում է սպասված թիրախները, կա՛մ անմիջապես ձախողվում է։
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Փոխարինեք տիրույթի անունը և երկու հասցեները ձեր կառավարվող տիրույթի կազմաձևի արժեքներով․ այստեղի թվերը օրինակներ են։ Եթե հարցումը վերադարձնում է այլ գոտու պատասխաններ, VM-ն օգտագործում է լուծիչ, որը չի փոխանցում կառավարվող անվանատարածքը, և միացման կրկնությունների քանակը դա չի փոխի։
Աշխատանքային բեռը պահեք այն ենթացանցից դուրս, որը կառավարվող տիրույթը վերապահում է իր իսկ ծառայության ռեսուրսներին, և գրացուցակի պորտերը պահեք մասնավոր ուղու վրա։ Այդ պորտերի հրապարակային բացումը կարճ ճանապարհ չէ․ դա այլ ռիսկի պրոֆիլով այլ ձևավորում է։
Հաշվի պիտանիությունը ստուգվում է մեքենայից առաջ
Միացումը կատարող հաշիվը թույլտվություն է պահանջում թիրախ բեռնարկղում համակարգչային օբյեկտ ստեղծելու համար, և պետք է կարողանա նույնականացնել կառավարվող տիրույթի նկատմամբ։ Միայն ամպային հաշիվը, որը ստեղծվել է նախքան կառավարվող տիրույթի գոյությունը, կարող է չունենալ տիրույթին անհրաժեշտ գաղտնաբառից ստացված նյութը, և գաղտնաբառի փոփոխությունը կամ վերակայումը այն նորից ստեղծում է։ Այդ մանրամասը բացատրում է միացման խափանումների դաս, որոնք սխալ գաղտնաբառերի են նման, երբ գաղտնաբառը ճիշտ է։ Փորձարկեք հավատարմագիրը տիրույթի նկատմամբ նախքան սպասարկման պատուհանի բացվելը։
Համաժամեցված հիբրիդային հաշիվներն ունեն իրենց նախապայմանները, որոնք տեսանելի օգտատիրոջ օբյեկտը միայնակ չի բավարարում։ Գրացուցակում ցանկված լինելը նույնը չէ, ինչ դրանից տոմս ստանալ կարողանալը, ուստի փորձարկեք հաշիվը սպասարկման պատուհանից առաջ, ոչ թե ընթացքում։
Պատվիրակեք միացման իրավունքը նեղ ձևով։ Յուրաքանչյուր ապագա սերվերի օգտատիրոջ տիրույթի ադմինիստրատորի անդամակցություն տալը, որպեսզի մեկ գրանցում տեղի ունենա, մշտական թույլտվություն է ժամանակավոր խնդրի համար։
Միացումն ինքը մեկ հրաման է
Երբ մոդելն ընտրված է, DNS-ը պատասխանում է, և հաշիվը պիտանի է, գործողությունը սովորական Windows գործողությունն է։ Հուշումը գաղտնաբառը դուրս է պահում սկրիպտներից և shell-ի պատմությունից:
Add-Computer -DomainName "ds.corp.example" -Credential (Get-Credential) -PassThruՀրամանն այս ձևով ինքնուրույն չի վերագործարկում մեքենան, ուստի վերագործարկումը տեղի է ունենում սպասարկման պլանի համաձայն և վերականգնման ուղին դեռ հասանելի վիճակում։ Այլ տիրույթին արդեն միացված սերվերին անհրաժեշտ է միգրացիայի պլան, ոչ թե երկրորդ միացում առաջինի վրա։
Գրանցեք բեռնարկղը, որտեղ վայրէջք կատարեց համակարգչային օբյեկտը, և այն հաշիվը, որը ստեղծեց այն։ Երկուսն էլ կարևոր են, երբ մեքենան պետք է նորից միացվի վերակառուցումից հետո, և ոչ մեկը հետագայում սերվերից ակնհայտ չէ։
Ինչ չի տալիս անդամակցությունը
Տիրույթի անդամակցությունը ոչ մեկին տեղական ադմինիստրատոր չի դարձնում և հասանելիություն չի տալիս հեռավոր աշխատասեղանին կամ ֆայլերի համօգտագործմանը։ Այդ իրավունքները կազմաձևվում են առանձին, և կառավարվող տիրույթում դրանք մնում են նրա աջակցվող վարչական շրջանակում։
Ցանցային ուղին շարունակական կախվածություն է, ոչ թե տեղադրման քայլ։ Եթե մասնավոր կապը անհետանում է, սերվերը շարունակում է աշխատել պահված հավատարմագրերով, մինչև ինչ-որ բանի գրացուցակ պետք գա, և այդ ժամանակ խափանումը գալիս է հավելվածի մատյանում, ոչ թե փոխված կազմաձևի կողքին։
Microsoft-ի ուղեցույցը Windows Server-ի միացման վերաբերյալ թվարկում է կառավարվող տիրույթի աշխատահոսքի աջակցվող նախապայմանները։ Կարդացեք այն վերևի երեք որոշումների համեմատ և ցանկացած անհամապատասխանություն համարեք կանգ առնելու պատճառ, ոչ թե շրջանցվող մանրամաս։