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 मार्गदर्शिका टेम्पलेट कन्सोल, परवानग्या आणि स्वतंत्र प्रकाशन पायरी समाविष्ट करते.