कोण डायल-इन करू शकतो? 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 लेखा घटना तपासा।

शेवटी, प्रत्येक रिमोट-प्रवेश सेवेसाठी कोणती यंत्रणा निर्णयाची मालक आहे ते लिहा। धोरण वापरकर्त्याची डायल-इन गुणधर्म दुर्लक्षित करत असेल, तर गट अटच अधिकृत आहे आणि गुणवैशिष्ट्य फक्त त्या सेवेसाठी सल्लागार आहे। एकाच डोमेनमधील दोन सेवा कायदेशीरपणे वेगळे उत्तर देऊ शकतात, आणि पुनरावलोकन नोंदीने ते प्रत्येक सेवेसाठी एका ओळीत सांगावे।

ऑडिटमध्ये टिकणारा निष्कर्ष संक्षिप्त आहे: कोण जोडू शकतो, कोणत्या यंत्रणेने, कधी पुनरावलोकन झाले, कोणी केले। डायल-इन फ्लॅग पहिली दोन उत्तरे देतो; उर्वरित फक्त धोरणाचे पुनरावलोकन देते।