VPN गेटवे र क्लाइन्ट भूमिकाका लागि AD CS टेम्प्लेट डिजाइन

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

टेम्प्लेट कन्सोल खोल्नुअघि भूमिका तालिका लेख्नुहोस्

दुई भूमिका, दुई उद्देश्य। गेटवेले सेवा पहिचान प्रमाणित गर्छ, त्यसैले त्यसको प्रमाणपत्रलाई Server Authentication (1.3.6.1.5.5.7.3.1), डिजिटल हस्ताक्षर र कुञ्जी इन्क्रिप्शनको कुञ्जी प्रयोग, र क्लाइन्टहरूले जोडिने होस्टनाम विषयको वैकल्पिक नाममा चाहिन्छ। प्रमाणपत्रद्वारा प्रमाणीकरण गर्ने क्लाइन्टलाई Client Authentication (1.3.6.1.5.5.7.3.2) र गेटवेले अर्को पक्षको जाँचमा अपेक्षा गर्ने पहिचानसँग मिल्ने पहिचान चाहिन्छ। प्रयोगकर्ता प्रमाणपत्र र कम्प्युटर प्रमाणपत्र परस्पर बदल्न मिल्दैन, किनभने ती फरक भण्डारमा बस्छन् र फरक प्रक्रियाले तिनलाई प्रयोग गर्छन्।

प्रत्येक भूमिकाका लागि चार स्तम्भ लेख्नुहोस्: देखिनुपर्ने पहिचान, उद्देश्य, कुञ्जीको उपभोक्ता, र कुञ्जीले मेसिन छोड्न सक्छ कि सक्दैन। त्यही तालिकाले पछि हरेक चेकबक्स निर्धारण गर्छ, र त्यही नै तपाईंले समीक्षकलाई दिनुहुन्छ। पासवर्डमा आधारित क्लाइन्ट प्रमाणीकरण छुट्टै शाखा हो: यदि गेटवेले प्रयोगकर्तालाई प्रमाणहरूद्वारा प्रमाणीकरण गर्छ भने, क्लाइन्ट प्रमाणपत्र वितरणले कुनै प्रमाण नथपी काम थप्छ।

साझा टेम्प्लेट सम्पादन गर्नुको सट्टा टेम्प्लेटको प्रतिलिपि गर्नुहोस्

उद्देश्य लगभग सही भएको टेम्प्लेटबाट सुरु गर्नुहोस्, जस्तै गेटवेका लागि RAS and IAS Server वा डोमेनमा जोडिएका यन्त्रका लागि Computer, त्यसपछि त्यसको प्रतिलिपि गर्नुहोस् र प्रतिलिपिलाई त्यो केका लागि हो भन्ने नाम दिनुहोस्। अरू सेवाले पहिले नै प्रयोग गरिरहेको टेम्प्लेट फराकिलो बनाउनु त्यस्तो परिवर्तन हो जसले छ हप्तापछि असम्बन्धित कुरा बिगार्छ। प्रतिलिपिमा अनुप्रयोग नीतिहरू भूमिका तालिकाको उद्देश्यमा सेट गर्नुहोस्, कुञ्जी प्रयोग त्यससँग मिलाउनुहोस्, तपाईंका गेटवेले स्वीकार गर्ने कुञ्जी एल्गोरिदम र लम्बाइ छान्नुहोस्, र यन्त्रले सार्नका लागि निर्यात गर्नु नपर्ने भए निजी कुञ्जीलाई निर्यात नहुने भनी चिन्ह लगाउनुहोस्।

वैधता र नवीकरण पनि टेम्प्लेटकै हुन्। छोटो आयु रद्द गर्न सजिलो र चलाउन गाह्रो हुन्छ; लामो आयुले दर्ताको काम घटाउँछ र चुहिएको कुञ्जीको जोखिम लम्ब्याउँछ। तपाईंले तर्क गर्न सक्ने संख्या छान्नुहोस्, र CA को आफ्नै वैधता र टेम्प्लेटको नवीकरण अवधिले नतिजा छोटो पार्न सक्छ भन्ने ध्यान दिनुहोस्।

विषय कहाँबाट आउँछ निर्धारण गर्नुहोस्

डोमेन कम्प्युटर वा प्रयोगकर्ताका लागि विषयलाई डाइरेक्टरी जानकारीबाट बनाउनुहोस् ताकि अनुरोधकर्ताले नाम टाइप गर्न नसकोस्। डोमेनमा नजोडिएको गेटवे, वा AD बाहिर पहिचान तोकिने यन्त्रका लागि टेम्प्लेटलाई त्यसको सट्टा नियन्त्रित अनुरोध मार्ग चाहिन्छ। अनुरोधकर्ताले दिने विषय र वैकल्पिक नामहरू सक्षम गर्नु वास्तविक निर्णय हो: यो हरेक दर्ता गर्नेले जुनसुकै नाम दाबी गर्न पाउने इजाजतपत्र होइन, र CA पक्षको नीतिले कसले माग्न सक्छ र के प्रमाण चाहिन्छ भन्ने अझै भन्नुपर्छ।

Windows IKEv2 यहाँ कडा छ। गेटवे प्रमाणपत्र क्लाइन्टले कन्फिगर गरेको नामसँग मिलाइन्छ, त्यसैले DNS नाम क्लाइन्टले खोज्ने ठाउँमा, सामान्यतया विषयको वैकल्पिक नाममा dNSName प्रविष्टिका रूपमा हुनुपर्छ। नमिल्ने प्रमाणपत्र चलाउन नाम जाँच वा उद्देश्य जाँच बन्द गर्नु उत्पादनमा नमिलेको कुरा समात्ने जाँच हटाउनु हो।

टेम्प्लेट प्रकाशित गर्नुहोस्, त्यसपछि अनुमति साँघुरो बनाउनुहोस्

AD DS मा टेम्प्लेट वस्तु बनाउनु र त्यसलाई जारी गर्ने CA मा प्रकाशित गर्नु फरक कन्सोलमा गरिने छुट्टाछुट्टै कार्य हुन्। प्रतिलिपिलाई Certification Authority कन्सोलबाट Certificate Templates अन्तर्गत प्रकाशित गर्नुहोस्, त्यसपछि कमाण्ड लाइनबाट CA ले अब त्यो दिन्छ भनी प्रमाणित गर्नुहोस्:

certutil -CATemplates
certutil -TCAInfo

अनुमतिहरू त्यसपछि आउँछन्। जो समूहले त्यो माग्नुपर्छ तिनलाई Read र Enroll दिनुहोस् र त्यसभन्दा बढी केही दिनुहोस्, CA को आफ्नै पढ्ने पहुँच अक्षुण्ण राख्नुहोस्, र Autoenroll त्यहीँ मात्र दिनुहोस् जहाँ स्वचालित दर्ता इरादा गरिएको छ र त्यसलाई काम गराउने तैनाथी नीतिले समर्थन गर्छ। टेम्प्लेटको चेकबक्सले आफैँ केही दर्ता गर्दैन, र दर्ता अनुमति बिना प्रकाशित टेम्प्लेटले प्रमाणपत्र सूचीबद्ध गरेर अनुरोध अस्वीकार गर्ने पोर्टल बनाउँछ।

वास्तविक उपभोक्तामा एउटा पाइलट दर्ता गर्नुहोस्

प्रमाणपत्र त्यसै सन्दर्भमा माग्नुहोस् जसले यसलाई प्रयोग गर्नेछ, त्यसपछि फाइलको नाममा भरोसा गर्नुको सट्टा फर्केर आएको कुरा जाँच्नुहोस्। प्रयोगकर्ता प्रमाणपत्र हालको प्रयोगकर्ताको भण्डारमा र कम्प्युटर प्रमाणपत्र स्थानीय कम्प्युटरको भण्डारमा पुग्छ, र MMC ले दुवै देखाउँछ, त्यसैले “काम गरेको” दर्ता पनि VPN सेवालाई अदृश्य रहन सक्छ।

certlm.msc
certutil -dump vpn-gateway.cer

डम्पलाई विषय, वैकल्पिक नाम, विस्तारित कुञ्जी प्रयोग र श्रृंखलाका लागि पढ्नुहोस्। Windows नभएको गेटवेका लागि, डोमेन स्वचालित दर्ता त्यहाँ पुग्छ भनी मान्नुको सट्टा समर्थित कार्यप्रवाहबाट अनुरोध पेस गर्नुहोस्, र निर्यात गरिएको ढाँचा उपभोक्ताले आफ्नो मिल्ने निजी कुञ्जीसँगै आयात गर्ने ढाँचा हो भनी पुष्टि गर्नुहोस्। अन्तमा, विश्वास र अधिकारलाई छुट्टाछुट्टै राख्नुहोस्: VPN ले कुन प्रयोगकर्ता वा यन्त्रले कुन स्रोतमा पुग्छ भनी अझै निर्णय गर्नुपर्छ, र रद्दीकरणले पहुँच हटाउँछ तर मात्र यदि गेटवेले रद्दीकरण जाँच गर्छ भने। प्रमाणपत्र टेम्प्लेट व्यवस्थापन गर्ने Microsoft मार्गदर्शिका ले टेम्प्लेट कन्सोल, अनुमति र छुट्टै प्रकाशन चरण समेट्छ।