AD CS შაბლონების დიზაინი VPN კარიბჭისა და კლიენტის როლებისთვის

საწარმო 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-ის სახელმძღვანელო სერტიფიკატის შაბლონების მართვის შესახებ მოიცავს შაბლონების კონსოლს, ნებართვებს და გამოქვეყნების ცალკე ნაბიჯს.