VPN साइन-इन नाकारले: रजिस्ट्रीपूर्वी बिल्ड तपासा
रजिस्ट्रीतील गहाळ मूल्य अद्ययावतानंतर स्वतःचे डीफॉल्ट लागू करू शकते. आधी बिल्ड स्तर, प्रभावी धोरण आणि एक जुळणारी घटना वाचा.
जिथे कोणीही रजिस्ट्री संपादित केली नाही अशा मशीनवर साइन-इन नाकारले जाते, आणि फोरमचे उत्तर तिथे नसलेले मूल्य जोडायला सांगते। अनुपस्थिती हाच निष्कर्ष नाही। Windows डीफॉल्ट लागू करते, स्थापित अद्ययावतासह डीफॉल्ट बदलू शकतो, आणि म्हणून उपकरणावरील प्रभावी धोरण रजिस्ट्री जे सुचवते त्यापेक्षा कडक असू शकते।
क्लायंटने प्रत्यक्षात दाखवलेल्या त्रुटीपासून सुरुवात करा
दुसऱ्या हातून आलेला सारांश नाही, संदेश वाचा। लगेच परत येणारी विनंती, टनेल तयार झाल्यानंतरची वेळ संपुष्टात येणे, आणि कनेक्शनने लॉग-इन केलेले खाते पुन्हा वापरण्याचा प्रयत्न केल्यावरच दिसणारे अपयश — या तीन वेगळ्या परिस्थिती आहेत। फक्त तिसऱ्याचा सिंगल साइन-ऑनशी काही संबंध आहे, आणि या लेखातील कोणत्याही गोष्टीने पहिल्या दोन सुधारणार नाहीत।
निर्णय घेतलेला स्तर कोणता लॉग त्याला उत्तर देतो हे ठरवतो। ही चार निरीक्षणे चार वेगळ्या मालकांकडे निर्देश करतात:
| What you observe | Where the decision was made | Who owns the fix |
|---|---|---|
| The prompt returns before the tunnel forms | Local credential handling on the client | Device policy or the installed build |
| Authentication succeeds, no internal site loads | Routing or access control after login | The gateway or network owner |
| Fails only when the logged-on account is reused | SSO credential generation | The policy boundary this page covers |
| Every user on one build fails | Update level or vendor regression | Patch management |
टिकेटमध्ये नेमका मजकूर, मिनिट आणि खात्याचा संदर्भ लिहा। प्रयत्न संवादात्मक होता की स्वयंचलित हे ठरवते की Windowsचा कोणता घटक कॉल करत होता, आणि VPN बिघडले आहे असे सांगणारा अहवाल अनेकदा नाकारलेल्या ओळखपत्रांऐवजी गहाळ अंतर्गत साइटचे वर्णन करतो।
गहाळ मूल्य नाही, प्रभावी धोरण वाचा
आधी बिल्ड आणि अद्ययावत स्तर निश्चित करा, कारण NTLMv1वरून घेतलेल्या ओळखपत्रांच्या निर्मितीचे डीफॉल्ट सूचीबद्ध Windows 11 आणि Windows Server 2025 आवृत्त्यांमध्ये बदलले आहे। Credential Guard बंद आणि BlockNtlmv1SSO सेट नसल्यास, 13 ऑक्टोबर 2026 रोजी किंवा नंतर प्रकाशित अद्ययावत वर्तन ऑडिटमधून अंमलबजावणीत नेते, ते मूल्य कधीही न तयार करता। रजिस्ट्रीत काहीही दिसत नाही, आणि उपकरण शेवटच्या प्रशासकाने ठरवले त्यापेक्षा कडक होते। येथे रजिस्ट्री शोध इतके कमी का सिद्ध करते याचे हेच संपूर्ण कारण आहे।
आउटपुट वाचताना सीमा वेगळ्या ठेवा। LmCompatibilityLevel नेटवर्क प्रमाणीकरण प्रतिसाद स्तर आहे, जो मशीन सर्व्हरला कोणते आव्हान आणि प्रतिसाद पाठवेल हे ठरवतो; तो सिंगल साइन-ऑन ओळखपत्र निर्मिती नियंत्रित करणारा नियंत्रण नाही, म्हणून तो कमी केल्याने साइन-इन परत येत नाही। उपकरण NTLMv1 नेटवर्क प्रोटोकॉल म्हणून बोलेल की नाही ही तिसरी सीमा आहे, आणि सध्याच्या Windows 11 व Server 2025 आवृत्त्यांनी ते आधीच सोडले आहे। Credential Guard, चौथा, उपकरणावरील रहस्ये संरक्षित करतो।
एक प्रयत्न एका घटनेशी जोडा
अपयश एकदा पुन्हा तयार करा, मिनिट नोंदवा, आणि नंतर स्थानिक पुरावे एका सत्रात गोळा करा। तीन आदेश बिल्ड, प्रभावी मूल्य आणि प्रतिबंधित सिंगल साइन-ऑन ओळखपत्र निर्मिती नोंदवली जाणारी NTLM कार्यचालन लॉग व्यापतात:
Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, OsVersion
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 30 | Select-Object TimeCreated, Id, Message
अपयशाच्याच क्षणीची घटना पुरावा आहे। कालची, दुसऱ्या खात्याची, किंवा एकही नोंद नसलेला लॉग पुरावा नाही, आणि रिकाम्या प्रकरणाची अनुपस्थित पुरावा म्हणून नाही, रिकामा असा नोंद करणे योग्य आहे। NTLMv1 बदलांबद्दलचे Microsoft मार्गदर्शन प्रतिबंधित सिंगल साइन-ऑन ओळखपत्र निर्मितीसाठी घटना ओळखकर्ता नाव देते, म्हणून संदेशाच्या मजकुरातून अंदाज न करता Id त्याच्याशी तुलना करा।
क्लायंटचा स्वतःचा संदेश आणि त्याच प्रयत्नाबद्दल गेटवेची दृष्टी एकत्र ठेवा। स्थानिक ओळखपत्र निर्मितीवर प्रतिबंध, दूरस्थ खाते नकार आणि यशस्वी लॉग-इननंतर गहाळ खाजगी मार्ग — यांचे तीन वेगळे मालक असून Windows धोरणाचा प्रश्न फक्त पहिला आहे। संघ सोडण्यापूर्वी घटना स्वच्छ करा: टाइमस्टॅम्प आणि घटना Id सामान्यतः खात्याच्या तपशिलांशिवाय प्रश्नाचे उत्तर देतात।
सक्षम साइन-इन पद्धतीकडे जा
प्रभावी धोरण तोच प्रतिबंध असेल, तर उत्तर डीफॉल्टचे शांत उलथापालथ नाही तर सक्षम प्रमाणीकरण मार्ग आहे। जिथे तैनाती सक्षम करते तिथे प्रमाणपत्र-आधारित प्रमाणीकरण सामान्य गंतव्य आहे, आणि त्यासाठी नोंदणी, विश्वास वितरण आणि प्रमाणपत्रे स्वीकारणारा गेटवे लागतो। आगामी NTLMv1 बदलांबद्दल Microsoft मार्गदर्शन हा प्रकरणाच्या पुनरावलोकनाच्या वेळी उद्धृत करावयाचा दस्तऐवज आहे।
प्रयोग म्हणून Credential Guard बंद केल्यास पर्यायी लॉग-इन न देता संरक्षण काढून टाकले जाते, आणि पुनर्वापरयोग्य ओळखपत्रांवरील नोंदवलेले निर्बंध हेच कारण आहे की हा निदानाचा टप्पा नाही तर रचनात्मक निर्णय आहे। तात्पुरता अपवाद मंजूर झाल्यास त्याला व्याप्ती, मालक आणि समाप्ती तारीख द्या, आणि बदलामुळे तुम्हाला आवश्यक कनेक्शनपासून बाहेर ठेवले तर मशीनपर्यंत स्वतंत्र प्रशासकीय मार्ग ठेवा। स्वीकृती चाचणी म्हणजे अपेक्षित प्रमाणीकरण आणि त्यामागील संसाधन, स्थानिक त्रुटी संकेताचे अदृश्य होणे नाही।