Dizajn AD CS predložaka za uloge VPN pristupnika i klijenata

Poslovni CA može izdati svaki certifikat koji VPN treba, a da nikada ne bude pristupnik. Dizajnerski posao je odlučiti šta svaka strana mora dokazati, a zatim koji predložak može izdati vjerodajnicu koja dokazuje upravo to. Počinjem tablicom uloga, kopiram odgovarajući predložak umjesto da uređujem postojeći na licu mjesta, fiksiram izvor subjekta po ulozi, objavim rezultat na CA koji izdaje i upišem jednog pilot-klijenta prije nego što to iko automatizuje. Svaki korak ispod je mjesto gdje ispravan CA ipak proizvede certifikat koji će VPN odbiti.

Napišite tablicu uloga prije otvaranja konzole predložaka

Dvije uloge, dvije namjene. Pristupnik dokazuje identitet usluge, pa njegov certifikat treba Server Authentication (1.3.6.1.5.5.7.3.1), korištenje ključa za digitalni potpis i šifriranje ključa, te ime hosta na koje se klijenti spajaju u alternativnom imenu subjekta. Klijenti koji se autentificiraju certifikatima trebaju Client Authentication (1.3.6.1.5.5.7.3.2) i identitet koji odgovara onome što pristupnik očekuje u provjeri druge strane. Korisnički i računarski certifikat nisu zamjenjivi jer žive u različitim spremištima i koriste ih različiti procesi.

Zapišite četiri kolone za svaku ulogu: identitet koji se mora pojaviti, namjenu, potrošača ključa i smije li ključ napustiti računalo. Ta tablica kasnije odlučuje o svakom kvadratiću i ona je ono što dajete recenzentu. Autentifikacija klijenata lozinkom je zasebna grana: ako pristupnik autentificira korisnike vjerodajnicama, distribucija klijentskih certifikata dodaje posao bez dodavanja dokaza.

Kopirajte predložak umjesto uređivanja zajedničkog

Pođite od predloška s približno pravom namjenom, poput RAS and IAS Server za pristupnik ili Computer za uređaje pridružene domeni, zatim ga kopirajte i dajte kopiji ime koje kaže čemu služi. Proširivanje predloška koji druge usluge već koriste je promjena koja šest sedmica kasnije pokvari nešto nepovezano. Na kopiji postavite pravila primjene na namjenu iz tablice uloga, održite korištenje ključa usklađenim s njom, odaberite algoritam i dužinu ključa koje vaši pristupnici prihvataju i označite privatni ključ kao neizvoziv osim ako ga uređaj mora izvesti da bi ga premjestio.

Valjanost i obnova također pripadaju predlošku. Kratak rok je lakše opozvati i teže održavati; dug rok smanjuje rad na upisu i produžava izloženost procurjelog ključa. Odaberite broj koji možete braniti i imajte na umu da vlastita valjanost CA i period obnove predloška mogu skratiti rezultat.

Odlučite odakle dolazi subjekt

Za računalo ili korisnika u domeni gradite subjekt iz podataka imenika kako podnosilac zahtjeva ne bi mogao upisati ime. Za pristupnik koji nije pridružen domeni, ili uređaj čiji se identitet dodjeljuje izvan AD-a, predlošku treba umjesto toga kontrolirani put zahtjeva. Omogućavanje subjekta i alternativnih imena koje daje podnosilac zahtjeva prava je odluka: to nije licenca da svaki upisani traži bilo koje ime, a pravilo na strani CA još mora reći ko smije tražiti i kakav je dokaz potreban.

Windows IKEv2 je ovdje strog. Certifikat pristupnika upoređuje se s imenom koje je klijent konfigurisao, pa DNS ime mora biti prisutno tamo gdje ga klijent traži, obično kao unos dNSName u alternativnom imenu subjekta. Isključivanje provjere imena ili namjene da bi neusklađeni certifikat proradio uklanja provjeru koja bi neusklađenost uhvatila u produkciji.

Objavite predložak, zatim suzite dozvole

Stvaranje objekta predloška u AD DS-u i njegovo objavljivanje na CA koji izdaje su odvojene radnje koje se rade u različitim konzolama. Objavite kopiju iz konzole Certification Authority pod Certificate Templates, zatim s komandne linije provjerite da je CA sada nudi:

certutil -CATemplates
certutil -TCAInfo

Dozvole su sljedeće. Dajte Read i Enroll grupama koje ga trebaju tražiti i ništa više, sačuvajte vlastiti pristup čitanju CA-a i dajte Autoenroll samo tamo gdje je automatski upis namjeran i potkrijepljen pravilom implementacije koje ga čini funkcionalnim. Kvadratić u predlošku sam po sebi ništa ne upisuje, a objavljen predložak bez dozvole upisa stvara portal koji navede certifikat i zatim odbije zahtjev.

Upišite jedan pilot kod stvarnog potrošača

Zatražite certifikat u kontekstu koji će ga koristiti, zatim pregledajte šta je vraćeno umjesto da vjerujete imenu datoteke. Korisnički certifikat završava u spremištu trenutnog korisnika a računarski u spremištu lokalnog računala, i MMC prikazuje oba, zbog čega upis koji je “uspio” može ostati nevidljiv VPN usluzi.

certlm.msc
certutil -dump vpn-gateway.cer

Pročitajte ispis za subjekt, alternativna imena, prošireno korištenje ključa i lanac. Za pristupnik koji nije Windows, podnesite zahtjev kroz podržani tok rada umjesto da pretpostavljate da ga automatski upis domene doseže, i potvrdite da je izvezeni format onaj koji potrošač uvozi zajedno sa svojim odgovarajućim privatnim ključem. Na kraju, držite povjerenje i autorizaciju odvojeno: VPN još mora odlučiti koji korisnici ili uređaji dosežu koje resurse, a opoziv uklanja pristup samo ako pristupnik uopće provjerava opoziv. Microsoftov vodič za upravljanje predlošcima certifikata pokriva konzolu predložaka, dozvole i odvojeni korak objavljivanja.