कोणालाही VPN द्वारे फाइल शेअरपर्यंत पोहोचता येत नाही, तो वाचतो की LmCompatibilityLevel कमी केल्याने NTLM समस्या सुटतात, आणि सामायिक सर्व्हरवर ते बदलतो। पुढच्या सकाळी इतर अनुप्रयोग अपयशी होतात, आणि मूळ समस्या तशीच राहते। हा सेटिंग कधीही प्रति-टनेल स्विच नव्हता; ही या प्रणालीने कोणते प्रमाणीकरण प्रतिसाद पाठवायचे आणि स्वीकारायचे याबद्दल मशीन-व्यापी घोषणा आहे। एक लॉगिन दुरुस्त करण्यासाठी ते बदलल्यास मशीन करत असलेल्या प्रत्येक लॉगिनचे नियम पुन्हा लिहिले जातात।

दस्तऐवजीकृत स्तर वाचणे हा धोरण मूल्याला जादुई संख्या मानणे थांबवण्याचा सर्वात वेगवान मार्ग आहे।

तीन स्तर, तीन वेगवेगळी वचने

स्तर 1 क्लायंटला LM आणि NTLM प्रतिसाद पाठवायला भाग पाडतो, आणि वाटाघाटी परवानगी देत असल्यास NTLMv2 सत्र सुरक्षा वापरतो। स्तर 3 क्लायंटला फक्त NTLMv2 प्रतिसाद पाठवायला भाग पाडतो, जे प्राप्तकर्त्या बाजूस प्रत्येक जुन्या प्रतिसादाला नकार देण्यासारखे नाही। स्तर 5 क्लायंटला NTLMv2 वर ठेवतो आणि डोमेन कंट्रोलरचा दस्तऐवजीकृत LM व NTLMv1 नकार जोडतो। तीन संख्या, आणि त्यांच्यातील फरक हा प्राधान्य नसून धोरण-निर्णय आहे।

हे फरक स्पष्ट करतात की कार्यरत प्रकरणातून मूल्य कॉपी करणे विश्वासार्ह का नाही। चुकीच्या संरचनेचा क्लायंट 1 वरून मंजूर आधाररेषेवर नेणे योग्य असू शकते। केवळ फोरम थ्रेडमध्ये 3 चा उल्लेख होता म्हणून कठोर तैनाती 5 वरून 3 वर आणणे हे कोणीतरी जाणीवपूर्वक निवडलेली सीमा सैल करते, आणि मशीन ज्या प्रत्येक सेवेशी बोलते त्यासाठी ते करते।

प्रभावी धोरण वाचा, एक रजिस्ट्री मूल्य नाही

स्थानिक मूल्याकडे फक्त-वाचन नजर हा योग्य प्रारंभ बिंदू आहे: Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel। मूल्य नसणे म्हणजे प्रभावी धोरण शून्य आहे असे नाही, कारण डोमेन किंवा स्थानिक सुरक्षा धोरण ते दुसरीकडे सेट करू शकते, आणि मशीनची भूमिका या संख्येसह ते काय करते ते बदलते।

कोणताही निष्कर्ष काढण्यापूर्वी व्यवस्थापित धोरण, प्रणालीची भूमिका आणि प्रत्यक्ष बिल्ड तपासा। समान मूल्य असलेले वर्कस्टेशन आणि डोमेन कंट्रोलर वरच्या टोकावर वेगळे वागतात, आणि दोन मशीनची तुलना करताना लोक हाच भाग विसरतात।

प्रत्यक्षात कोणते प्रमाणीकरण अपयशी झाले ते ओळखा

Kerberos तिकिटाच्या समस्या, NTLM नकार आणि VPN प्रवेश अपयशांना वेगळे पुरावे लागतात। लक्ष्य सेवा, खाते आणि नेमकी त्रुटी एकाच टिपेत एकत्र ठेवा, नंतर क्लायंटला काय आवडते त्याऐवजी सेवेने काय मागितले ते पहा। तीच एक टीप सर्वात सामान्य चुकीची वळण टाळते, म्हणजे सर्व्हर-बाजूच्या नकाराला उत्तर देण्यासाठी क्लायंट-बाजूचे मूल्य बदलणे।

सामान्य लॉगिन त्रुटी नाहीशी होईपर्यंत धोरण वारंवार कमी करणे हे निदान नाही; तो असा बदल आहे जो पुरावा लपवतो। जर अनुप्रयोग Kerberos वापरत असेल, तर NTLM सुसंगतता स्तर हा संबंधित नियंत्रणही नाही, आणि तुम्ही एक सीमा वायफळ सैल केली आहे।

काही प्रोटोकॉल समर्थन पुन्हा मिळवता येत नाही

Windows 11 24H2 आणि Windows Server 2025 मध्ये आता NTLMv1 नेटवर्क प्रमाणीकरण अजिबात समाविष्ट नाही। बिल्ड आता अंमलात न आणणारा प्रोटोकॉल कोणतीही सुसंगतता-संख्या परत आणत नाही, म्हणून जुन्या आवृत्तीवर मदत करणारे डाउनग्रेड नव्या आवृत्तीवर फक्त अपयशी होईल। Microsoft ती काढणी धोरण-सेटिंगपासून वेगळी दस्तऐवजीकृत करते, आणि दोन्ही मिसळल्यास काम करू शकत नाही असा सल्ला तयार होतो।

संबंधित पण वेगळी मर्यादा MSCHAPv2-आधारित एकल साइन-इन वापरत असलेल्या NTLMv1-व्युत्पन्न क्रेडेन्शियल्सना लागू होते। हा व्युत्पन्न क्रेडेन्शियल्सचा प्रश्न आहे, नेटवर्क प्रोटोकॉलचा स्वतःचा नाही, आणि या एका रजिस्ट्री मूल्याचाही नाही। तिन्हींना एकच विषय मानणे हा तो मार्ग आहे ज्यावर संस्था एक नियंत्रण कमकुवत करतात आणि दुसरे दुरुस्त करण्याचा प्रयत्न करतात।

मालकामार्फत ते बदला, नंतर दोन्ही दिशा तपासा

जर खरोखर सुधारणा आवश्यक असेल, तर आधाररेषा सुसंगत राहावी यासाठी धोरण-मालकामार्फत करा, आणि का ते नोंदवा। नंतर नव्या सेटिंगअंतर्गत अधिकृत अनुप्रयोग आणि जाणीवपूर्वक प्रतिबंधित प्रमाणीकरण प्रकरण तपासा, कारण एक शेअर दुरुस्त करून दुसरीकडे जुन्या प्रतिसादांना गुपचूप परवानगी देणारा बदल यश नाही। कार्यरत VPN कनेक्शन प्रवेश यशस्वी झाल्याचे सिद्ध करते। ते मशीनचे प्रमाणीकरण धोरण सत्यापित करत नाही, आणि त्यामागील प्रत्येक सेवा अजूनही आराखड्यानुसार वागते हे निश्चितपणे दाखवत नाही।

अपयशी सेवा Kerberos-आधारित असेल, तर हे सेटिंग पाहणे पूर्णपणे थांबवा। जर ते खरोखर अधिक चांगले करू न शकणारे जुने उपकरण असेल, तर तो अपवाद दस्तऐवजीकृत करा आणि त्याची व्याप्ती ठरवा, कारण पर्याय म्हणजे कोणालाही मंजूर केल्याचे आठवत नसलेली गुपचूप कमकुवत केलेली आधाररेषा।

संबंधित लेख