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 बन्द गर्दा वैकल्पिक लगइन नदिई सुरक्षा हट्छ, र पुनः प्रयोगयोग्य प्रमाणहरूमा अभिलेखित प्रतिबन्धहरू नै यो निदानको चरण होइन, डिजाइन निर्णय हो भन्ने कारण हुन्। यदि अस्थायी अपवाद अधिकृत भयो भने यसलाई क्षेत्र, मालिक र अन्त्य मिति दिनुहोस्, र परिवर्तनले तपाईंलाई आवश्यक जडानबाट बाहिर राख्छ भने मेसिनसम्म स्वतन्त्र प्रशासन मार्ग राख्नुहोस्। स्वीकृति परीक्षण भनेको अभिप्रेत प्रमाणीकरण र त्यसपछाडिको स्रोत हो, स्थानीय त्रुटि कोड हराउनु होइन।