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 ഗൈഡ് ടെംപ്ലേറ്റ് കൺസോൾ, അനുമതികൾ, വേറിട്ട പ്രസിദ്ധീകരണ ഘട്ടം എന്നിവ ഉൾക്കൊള്ളുന്നു.