Azure VM ni Entra Domain Services ga ulash: avval qaror qiling

Boshqariladigan katalogdan foydalanishi kerak bo'lgan Windows Server VM oldida uchta qaror turadi, va ulash buyrug'i ularning eng kichigi. Noto'g'ri katalog modelini tanlang va ulash muvaffaqiyatli bo'ladi, ammo ilova hali ham autentifikatsiya qila olmaydi. Nomlarni hal qilishda xato qilsangiz, nosozlik ishonch ma'lumotlari muammosiga o'xshab ko'rinadigan joyda paydo bo'ladi.

Serverga tegishdan oldin model, hal qilish va hisobni belgilang, keyin buyruq bir marta ishlaydi.

Uchta ulashdan qaysi birini haqiqatan xohlaysiz

Qurilmani ulash mashinani shartli kirish va yagona kirish uchun Microsoft Entra ID da ro'yxatdan o'tkazadi va ish yukiga mahalliy uslubdagi domenga Kerberos chiptasini bermaydi. An'anaviy domen ulash kompyuter obyektini katalogga bog'laydi va unga mashina hisobi, guruh siyosati va domen autentifikatsiyasini beradi. Boshqariladigan domen o'sha ikkinchi modelni xizmat sifatida taqdim etadi. Nomlar bir xil eshitiladi, natijalar esa yo'q.

Oddiy ma'noda domen kontrolleri faqat oxirgi ikkitasida bo'ladi, va faqat boshqariladigan variant serverlarni yamoqlar ro'yxatingizdan olib tashlaydi.

Qaror odatda afzallikka emas, ilovaga bog'liq. LDAP bog'lanishi, SPN li xizmat hisobi yoki guruh siyosati obyektlarini xohlaydigan dasturiy ta'minot domen modeliga tegishli. Korporativ qurilmada foydalanuvchining kimligini bilish kifoya bo'lgan dasturiy ta'minot odatda tegishli emas.

Ulash tugay oladimi yoki yo'qmi, buni DNS yo'li hal qiladi

Domen ulash domenning kontroller yozuvlari uchun lokator qidiruvidan boshlanadi, shuning uchun nomlarni hal qilish har qanday ishonch ma'lumotini tekshirishdan oldin ishlashi kerak. VM ni boshqariladigan domenning katalog manzillariga yo'naltiring, yo virtual tarmoqning DNS sozlamalari orqali, yo faqat shu nom maydonini u yerga yuboradigan shartli yo'naltiruvchi orqali. Nom maydoni bilan cheklangan yo'naltiruvchi odatda xavfsizroq tanlov, chunki VM ning qolgan hal qilishiga tegmaydi.

Yalang'och xost nomini emas, lokatorni sinab ko'ring. Domen nomiga ping deyarli hech narsani isbotlamaydi, domen kontrolleri yozuvlari uchun SRV so'rovi esa kutilgan nishonlarni qaytaradi yoki darhol muvaffaqiyatsiz bo'ladi:

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

Domen nomi va ikkita manzilni boshqariladigan domen konfiguratsiyangizdagi qiymatlar bilan almashtiring; bu yerdagi raqamlar misol. Agar so'rov boshqa zonaning javoblarini qaytarsa, VM boshqariladigan nom maydonini yo'naltirmaydigan hal qiluvchidan foydalanmoqda, va ulashni necha marta takrorlasangiz ham bu o'zgarmaydi.

Ish yukini boshqariladigan domen o'z xizmat resurslari uchun ajratgan quyi tarmoqdan tashqarida saqlang va katalog portlarini xususiy yo'lda saqlang. Bu portlarni ommaviy ochish qisqa yo'l emas; bu boshqa xavf profili bo'lgan boshqa dizayn.

Hisobning yaroqliligi mashinadan oldin tekshiriladi

Ulashni amalga oshiruvchi hisobga maqsadli konteynerda kompyuter obyekti yaratish ruxsati kerak, va u boshqariladigan domenga autentifikatsiya qila olishi kerak. Boshqariladigan domen paydo bo'lishidan oldin yaratilgan faqat bulutli hisobda domen uchun kerak bo'ladigan paroldan olingan material bo'lmasligi mumkin, va parolni o'zgartirish yoki tiklash uni qayta hosil qiladi. Bu tafsilot parol to'g'ri bo'lganda ham noto'g'ri parolga o'xshab ko'rinadigan ulash nosozliklarining bir sinfini tushuntiradi. Xizmat ko'rsatish oynasi ochilishidan oldin ishonch ma'lumotlarini domenga qarshi sinab ko'ring.

Sinxronlashtirilgan gibrid hisoblarning ko'rinadigan foydalanuvchi obyekti yolg'iz o'zi qondira olmaydigan o'z shartlari bor. Katalogda ro'yxatga olingan bo'lish undan chipta olish imkoniyati bilan bir xil emas, shuning uchun hisobni xizmat ko'rsatish oynasi davomida emas, undan oldin sinab ko'ring.

Ulash huquqini tor doirada topshiring. Bitta ro'yxatga olish amalga oshishi uchun har bir kelgusi server foydalanuvchisiga domen administratori a'zoligini berish vaqtinchalik muammo uchun doimiy ruxsatdir.

Ulashning o'zi bitta buyruqdir

Model tanlangan, DNS javob berayotgan va hisob yaroqli bo'lsa, operatsiya odatiy Windows operatsiyasi. So'rov parolni skriptlar va qobiq tarixidan tashqarida saqlaydi:

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

Bu shaklda buyruq mashinani o'zi qayta ishga tushirmaydi, shuning uchun qayta ishga tushirish xizmat ko'rsatish rejasi bo'yicha va tiklash yo'li hali mavjud bo'lganda sodir bo'ladi. Boshqa domenga allaqachon ulangan serverga ko'chirish rejasi kerak, birinchisining ustiga ikkinchi ulash emas.

Kompyuter obyekti qaysi konteynerga tushganini va uni qaysi hisob yaratganini yozib qo'ying. Qayta qurishdan keyin mashinani qayta ulash kerak bo'lganda ikkalasi ham muhim, va keyinchalik serverdan hech biri aniq emas.

A'zolik nima bermaydi

Domen a'zoligi hech kimni mahalliy administrator qilmaydi, va masofaviy ish stoli yoki fayl almashishga kirish bermaydi. Bu huquqlar alohida sozlanadi, va boshqariladigan domenda ular uning qo'llab-quvvatlanadigan ma'muriy doirasida qoladi.

Tarmoq yo'li sozlash bosqichi emas, doimiy bog'liqlikdir. Agar xususiy ulanish yo'qolsa, server keshlangan ishonch ma'lumotlari bilan ishlashda davom etadi, toki biror narsaga katalog kerak bo'lmaguncha, va keyin nosozlik o'zgargan konfiguratsiya yonida emas, ilova jurnalida keladi.

Microsoft ning Windows Server ulash bo'yicha qo'llanmasi boshqariladigan domen ish oqimi uchun qo'llab-quvvatlanadigan shartlarni sanab o'tadi. Uni yuqoridagi uchta qarorga qarshi o'qing, va har qanday nomuvofiqlikni chetlab o'tiladigan tafsilot emas, to'xtash sababi deb biling.