Bir oy oflayn bo‘lgandan keyin domen ishonchi buzildimi? Avval tekshiring
A’zo ish stansiyasi mashina parol oralig‘idan uzoqroq oflayn qolsa ham ishonchni yo‘qotmasligi mumkin. Hisobni tiklashdan oldin xavfsiz kanalni isbotlang.
Noutbuk olti hafta VPN tashqarisida qoladi, qaytadi va foydalanuvchi domen hisobi bilan kira olmaydi. Xato ishonch munosabatini eslatadi, shuning uchun kimdir kompyuter hisobini tiklaydi yoki foydalanuvchini to‘liq tunnelga majbur qiladi, muammo esa yo‘qolgandek ko‘rinadi. Ikkala harakat ham nima buzilganini isbotlamadi. Windows a’zosi odatdagi mashina parol oralig‘idan ancha uzoq oflayn qolishi va ishonchni avtomatik yo‘qotmasligi mumkin, shuning uchun birinchi vazifa yetib borish xatosini haqiqiy sir nomuvofiqligidan ajratishdir.
Xato ishonchga o‘xshaydi, lekin uch holat bir-biriga o‘xshaydi
Foydalanuvchi keshlangan domen ma’lumotlari bilan kira oladi, ish stansiyasi domen kontrollerini topa olmasligi mumkin, yoki a’zo va domen kompyuter hisobi borasida haqiqatan kelisha olmasligi mumkin. Qat’iy ma’noda buzilgan ishonch munosabati faqat uchinchisidir.
AD replikatsiyasi salomatligi to‘rtinchi kuzatuv bo‘lib, u bu ish stansiyasiga umuman aloqador emas. U domen kontrollerlari o‘rtasidagi kelishuvni tavsiflaydi va sog‘lom replikatsiya paneli bu mashinaning mahalliy siri uning kompyuter hisobiga mos kelishini isbotlamaydi.
Tanish 30 kunlik standart o‘zgartirish siyosatidir, oflayn tugash muddati emas. Microsoftning mashina hisobi paroli haqidagi tushuntirishi muvofiqlashtirilgan o‘zgartirish jarayonini tavsiflaydi va tashkilot boshqa oraliqni sozlashi mumkin.
VPN belgisi xavfsiz kanal haqida hech narsani isbotlamaydi
Har qanday sinov mazmunli bo‘lishidan oldin ulanish domen xizmatlariga yetib borish uchun yetarlicha yaxshi bo‘lishi kerak. Bu mo‘ljallangan domen DNS hal qiluvchisi, topiladigan kontroller, yetib boriladigan autentifikatsiya xizmatlari va Kerberos uchun yetarlicha yaqin soat demakdir.
To‘liq tunnel bu yerda mutlaqo to‘g‘ri dizayn bo‘lishi mumkin. Bo‘lingan tunnelga o‘tish sog‘lom domen munosabati uchun shart emas va uni shunday deb hisoblash diagnostikani arxitektura o‘zgarishiga aylantiradi. Ish stansiyasi aslida qaysi kontrollerni tanlashini tekshiring va bu nomni xato bilan birga saqlang.
nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -VerboseDNS serverini, hal qilingan kontrollerni va xatoning aniq matnini yozib oling. Ulanganligini bildirgan VPN mijozi tunnel borligini aytadi, domen yo‘li ishlayotganini emas. Kerberos portida javob berib, katalog portida javob bermaydigan kontroller xavfsizlik devori topilmasi, ishonch topilmasi emas.
A’zoni tuzatishdan oldin sinab ko‘ring
Vakolatli Windows domen a’zosida Test-ComputerSecureChannel -Verbose mashina va domen o‘rtasidagi kanalni faqat o‘qish uchun tekshirishdir. Uni siz tekshirayotgan mashina kontekstida ishga tushiring, domen kontrolleridan emas, chunki uning roli va tiklanish qoidalari boshqacha. O‘tgan yoki o‘tmagan so‘zi o‘rniga chiqish va chiqish holatini yozib oling. Agar o‘sha buildda cmdlet bo‘lmasa, modul alohida muammo.
Natija hali ham kontekstga muhtoj. Agar mashina tanlangan kontrollerga yetib bora olmasa yoki u yerda autentifikatsiya qila olmasa, muvaffaqiyatsiz sinov oflayn parol muddati tugaganining mustaqil isboti emas. Haqiqiy xatoni va ishlatilgan kontrollerni saqlang, yo‘l ma’lum yaxshi bo‘lgach sinovni takrorlang.
Hodisa atrofida a’zodagi va tegishli kontrollerdagi Netlogon hodisalarini bog‘lang. Mashina nomini, manba manzilini, vaqtni va hisob o‘zgarishining har qanday isbotini saqlang. Boshqa foydalanuvchining muvaffaqiyatli kirishi yoki sog‘lom kontroller paneli bu mashinaning almashinuvini almashtira olmaydi.
Faqat isbotlagan munosabatni tuzating
Ulanish barqaror bo‘lgach va administrator tuzatish o‘rinli ekanini tasdiqlagach, cmdletning vakolatli hisob ma’lumotlari bilan -Repair rejimi a’zo ish stansiyasi uchun qo‘llab-quvvatlanadigan bir operatsiyadir. U munosabatni o‘zgartiradi va bu yana bir faqat o‘qish sinovi emas.
O‘zgartirishdan oldin tasdiqlangan mahalliy tiklash hisobi va boshqaruv yo‘lini tayyor holda saqlang. Domen kontrollerlarining tiklanish roli boshqacha va bu tartib ularga oddiy ish stansiyalari sifatida qaramasligi kerak. Bir nechta tiklash vositasini ketma-ket ishga tushirib, ulardan biri to‘g‘ri bo‘ladi deb umid qilish o‘rniga tashkilotning tiklash ish oqimidan foydalaning.
Tuzatishdan keyin yangi xavfsiz kanal sinovi va asl domen operatsiyasini tekshiring. Foydalanuvchi profillari va ilova holatini saqlang, olib tashlash-va-qayta-qo‘shishni birinchi izohsiz harakatga aylantirmang.
Muvaffaqiyatsizlik qaytganda nimalarni tekshirish kerak
Agar muvaffaqiyatsizlik qaytsa, o‘sha hisobni yana tiklash o‘rniga orqaga qaytarish, ikki tomonlama identifikatsiya va hisob o‘zgarishlari vaqtini ko‘ring. Tuzatilgan obraz, oniy nusxa, klonlangan mashina identifikatsiyasi yoki boshqa joyda bajarilgan kompyuter hisobini tiklash — barchasi tekshirishga arziydi.
Vaqtinchalik muvaffaqiyatli tiklash foydali tiklanish isboti, lekin uzilishli VPN asl nomuvofiqlikka sabab bo‘lganining isboti emas. Sabab umuman bartaraf etilganmi yoki yo‘qmi, keyingi hodisa aytadi.
Kontrollerni, DNS serverini va sinov chiqishini biletdagi yozing. Aynan shu yozuv haqiqiy ishonch nosozligini domenni topa olmagan noutbukdan ajratadi.