कसले डायल इन गर्न सक्छ? 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 लेखा घटना जाँच्नुहोस्।

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

लेखापरीक्षणमा टिक्ने नतिजा छोटो छ: कसले जोडिन सक्छ, कुन संयन्त्रबाट, कहिले समीक्षा भयो, कसले। डायल-इन झन्डाले पहिला दुई उत्तर दिन्छ; बाँकी नीतिको समीक्षाले मात्र दिन्छ।