कौन डायल-इन कर सकता है? VPN पहुँच से पहले msNPAllowDialin का ऑडिट

पासवर्ड सही है, खाता VPN समूह में है, और फिर भी कनेक्शन ऐसे संदेश के साथ अस्वीकार हो रहा है जिसमें किसी नीति का उल्लेख ही नहीं है। जब ऐसा Windows रिमोट-एक्सेस सर्वर पर होता है, तो मैं सबसे पहले जो देखता हूँ वह NPS नियम नहीं, बल्कि Active Directory की एक विशेषता है जिसे कोई नहीं खोलता: msNPAllowDialin, यानी Dial-in टैब के पीछे का मान। इसकी तीन अवस्थाएँ हैं, और तीसरी चुपचाप निर्णय कहीं और सौंप देती है। ज़्यादातर लोगों ने इसे जानबूझकर नहीं बदला: खाता किसी टेम्पलेट से क्लोन किया गया था, या ऐसी स्क्रिप्ट ने बनाया था जिसने सालों पहले स्पष्ट निषेध लिखा और फिर कभी समीक्षा नहीं हुई।

नीति पढ़े जाने से पहले ही इनकार हो सकता है

Windows अनुमोदन निर्णय बनाते समय खाते की डायल-इन अनुमति जाँचता है, इसलिए स्पष्ट निषेध बातचीत जल्दी समाप्त कर देता है। क्लाइंट पर जो दिखता है वह एक सामान्य प्रमाणीकरण विफलता है, कभी-कभी प्रमाणपत्रों के आदान-प्रदान के बाद, और इसीलिए लोग दोपहर ऐसे क्रेडेंशियल जाँचने में लगा देते हैं जो कभी समस्या ही नहीं थे।

उलटा मामला भी उतना ही भ्रमित करने वाला है। जिस खाते पर कभी फ़्लैग सेट नहीं हुआ वह सफलतापूर्वक जुड़ सकता है क्योंकि नीति ने अनुमति दी थी, और फिर वही खाता जुड़ना बंद कर देता है जब कोई असंबंधित कारण से NPS नियम संपादित करता है। दोनों में से कोई भी घटना बाहर से डायल-इन अनुमति के बदलाव जैसी नहीं दिखती।

तीन अवस्थाएँ, और तीसरी अदृश्य है

TRUE डायल-इन की अनुमति देता है, FALSE उसे अस्वीकार करता है, और NULL मान का अर्थ है कि खाता अपना उत्तर रिमोट एक्सेस नीति या NPS अनुमोदन से विरासत में लेता है। GUI उस तीसरी अवस्था को "Control access through NPS Network Policy" के रूप में दिखाता है, और वह निर्णय की बजाय बिना चिह्नित चेकबॉक्स जैसी पढ़ी जाती है।

इसीलिए कंसोल से अनुमत उपयोगकर्ताओं की गिनती लगभग कुछ नहीं बताती। विरासत में मिला खाता आज अनुमत और कल अस्वीकृत हो सकता है, बिना खाते को छुए, और FALSE खाता उस सर्वर पर भी जुड़ सकता है जिसकी नीति उपयोगकर्ता के डायल-इन गुणों को नज़रअंदाज़ करने के लिए तैयार है। विशेषता और नीति साथ पढ़ें, वरना आप आधे निर्णय का ऑडिट कर रहे हैं।

विरासत वाले खातों को खोए बिना फ़्लैग निर्यात करें

निर्यात डोमेन नियंत्रक से, या Active Directory मॉड्यूल वाले वर्कस्टेशन से चलाएँ, और सारांश दोबारा टाइप करने के बजाय कच्ची फ़ाइल साक्ष्य के रूप में रखें:

Get-ADUser -Filter * -Properties msNPAllowDialin, LastLogonDate |
  Select-Object SamAccountName, Enabled, msNPAllowDialin, LastLogonDate |
  Sort-Object SamAccountName |
  Export-Csv -NoTypeInformation .\dialin.csv

एक अकेला LDAP फ़िल्टर परिवर्तन रिकॉर्ड में चिपकाना आसान है। यह केवल स्पष्ट अनुमतियाँ लौटाता है:

dsquery * -Filter "(&(objectCategory=person)(objectClass=user)(msNPAllowDialin=TRUE))" -Attr sAMAccountName

फिर डायल-इन क्लॉज़ के बिना दोबारा क्वेरी करें और ऐसे खाते खोजें जिनका मान अनुपस्थित है। वही विरासत वाले खाते हैं, आमतौर पर डोमेन का सबसे बड़ा समूह, और उन्हें छोड़ देने से ऑडिट उन गिने-चुने लोगों की सूची बन जाता है जिन्हें किसी ने हाथ से सेट करना याद रखा था।

फ़्लैग को समूह पहुँच और खाते के स्वास्थ्य से अलग करें

विशेषता एक प्रश्न का उत्तर देती है: क्या यह खाता डायल-इन कर सकता है। यह नहीं बताती कि व्यक्ति अब भी यहाँ काम करता है, खाता सक्षम है, या हेल्प-डेस्क के नोट में साझा पासवर्ड पड़ा है। निर्यात को सक्षम स्थिति, अंतिम लॉगिन तिथि और उस समूह-सदस्यता के साथ जोड़ें जो सर्वर तक पहुँच देती है।

आप जिन संयोजनों पर कार्य करते हैं वही मायने रखते हैं। अक्षम खाता TRUE के साथ केवल शोर है। सक्षम खाता TRUE के साथ एक वर्ष से लॉगिन नहीं हुआ तो वह हटाने का उम्मीदवार है। पर VPN समूह में विरासत वाला खाता जिसे कोई समझा नहीं सकता, वही असली निष्कर्ष है, क्योंकि कोई भी एकल सेटिंग यह दर्ज नहीं करती कि वह क्यों दिया गया।

इसे उस डोमेन नियंत्रक से पढ़ें जिसके विरुद्ध VPN सर्वर वास्तव में प्रमाणीकरण करता है। प्रतिकृति विलंब ऐसा मान दिखा सकता है जिसे सर्वर पहले ही बदल चुका है, और पुराने DC मान का हवाला देने वाला ऑडिट उसी क्षण चुनौती में पड़ेगा जब कोई फिर जाँचेगा।

एक खाता बदलें और सिद्ध करें कि परिवर्तन पहुँच गया

पहुँच हटाने के लिए विशेषता को FALSE पर सेट करें, उसे साफ़ करने के बजाय। साफ़ करने से खाता नीति-विरासत में लौट जाता है, जो अगले कनेक्शन पर उसे फिर अनुमति दे सकता है, और परिवर्तन सुधार जैसा दिखता है जबकि वास्तव में यह अलग निर्णय है:

dsmod user "CN=Jane Doe,OU=Staff,DC=corp,DC=example" -allowDialin no
Set-ADUser -Identity jdoe -Clear msNPAllowDialin

दूसरी पंक्ति विरासत का रीसेट है, जानबूझकर अलग रखी गई ताकि कोई दोनों क्रियाओं को न मिलाए। फिर दूसरे सत्र से पुष्टि करें, विशेषता दोबारा पढ़ें, और कंसोल के रीफ़्रेश पर भरोसा करने के बजाय इनकार के लिए NPS लेखा घटनाएँ देखें।

अंत में, लिखें कि प्रत्येक रिमोट-एक्सेस सेवा के लिए कौन-सा तंत्र निर्णय का स्वामी है। यदि नीति उपयोगकर्ता के डायल-इन गुणों को नज़रअंदाज़ करती है, तो समूह शर्त ही आधिकारिक है और विशेषता केवल उसी सेवा के लिए सलाहकारी है। एक ही डोमेन की दो सेवाएँ वैध रूप से अलग उत्तर दे सकती हैं, और समीक्षा रिकॉर्ड को प्रत्येक सेवा के लिए एक पंक्ति में यह कहना चाहिए।

ऑडिट में टिकने वाला परिणाम संक्षिप्त है: कौन जुड़ सकता है, किस तंत्र के अंतर्गत, कब समीक्षा हुई, किसने की। डायल-इन फ़्लैग पहले दो उत्तर देता है; बाकी केवल नीति की समीक्षा देती है।