Proiectarea șabloanelor AD CS pentru rolurile de gateway VPN și client

O CA de întreprindere poate emite fiecare certificat de care are nevoie un VPN fără să fie vreodată ea însăși gateway-ul. Munca de proiectare este să decideți ce trebuie să demonstreze fiecare parte, apoi care șablon poate emite o acreditare care demonstrează exact asta. Încep cu un tabel de roluri, duplic un șablon potrivit în loc să editez unul la locul lui, fixez sursa subiectului pentru fiecare rol, public rezultatul pe CA-ul emitent și înregistrez un pilot înainte ca cineva să automatizeze asta. Fiecare pas de mai jos este un loc unde o CA funcțională produce totuși un certificat pe care VPN-ul îl va respinge.

Scrieți tabelul de roluri înainte de a deschide consola de șabloane

Două roluri, două scopuri. Gateway-ul demonstrează o identitate de serviciu, așa că certificatul său are nevoie de Server Authentication (1.3.6.1.5.5.7.3.1), de o utilizare a cheii pentru semnătură digitală și criptare a cheii, și de numele de gazdă la care se conectează clienții într-un nume alternativ al subiectului. Clienții care se autentifică cu certificate au nevoie de Client Authentication (1.3.6.1.5.5.7.3.2) și de o identitate care corespunde cu ceea ce așteaptă gateway-ul în verificarea celeilalte părți. Un certificat de utilizator și un certificat de computer nu sunt interschimbabile, pentru că trăiesc în magazine diferite și sunt folosite de procese diferite.

Scrieți patru coloane pentru fiecare rol: identitatea care trebuie să apară, scopul, consumatorul cheii și dacă cheia poate părăsi mașina. Acel tabel decide mai târziu fiecare casetă de selectare și este și ceea ce dați unui recenzent. Autentificarea clienților cu parolă este o ramură separată: dacă gateway-ul autentifică utilizatorii cu acreditări, distribuirea certificatelor de client adaugă muncă fără a adăuga dovezi.

Duplicați un șablon în loc să editați unul partajat

Porniți de la un șablon cu scopul aproximativ corect, cum ar fi RAS and IAS Server pentru gateway sau Computer pentru dispozitivele în domeniu, apoi duplicați-l și dați copiei un nume care spune la ce folosește. Extinderea unui șablon pe care alte servicii îl folosesc deja este schimbarea care strică ceva nelegat șase săptămâni mai târziu. Pe copie, setați politicile de aplicare la scopul din tabelul de roluri, păstrați utilizarea cheii consecventă cu el, alegeți algoritmul și lungimea cheii acceptate de gateway-urile voastre și marcați cheia privată ca neexportabilă dacă un aparat nu trebuie să o exporte pentru a o muta.

Valabilitatea și reînnoirea aparțin și ele șablonului. O durată scurtă este mai ușor de revocat și mai greu de operat; una lungă reduce munca de înregistrare și prelungește expunerea unei chei scurse. Alegeți un număr pe care îl puteți apăra și rețineți că valabilitatea CA-ului însuși și perioada de reînnoire a șablonului pot scurta rezultatul.

Decideți de unde vine subiectul

Pentru un computer sau utilizator de domeniu, construiți subiectul din informațiile din director, astfel încât numele să nu poată fi scris de solicitant. Pentru un gateway care nu este în domeniu, sau un dispozitiv a cărui identitate este atribuită în afara AD, șablonul are nevoie în schimb de o cale de solicitare controlată. Activarea subiectului și a numelor alternative furnizate de solicitant este o decizie reală: nu este o licență pentru fiecare înregistrat să pretindă orice nume, iar politica de pe partea CA trebuie încă să spună cine poate cere și ce dovadă este necesară.

Windows IKEv2 este strict aici. Certificatul gateway-ului este comparat cu numele configurat de client, așa că numele DNS trebuie să fie prezent acolo unde îl caută clientul, de obicei o intrare dNSName în numele alternativ al subiectului. Dezactivarea verificării numelui sau a scopului pentru a face să funcționeze un certificat care nu se potrivește elimină verificarea care ar fi prins nepotrivirea în producție.

Publicați șablonul, apoi restrângeți permisiunile

Crearea obiectului de șablon în AD DS și publicarea lui pe CA-ul emitent sunt operațiuni separate, făcute în console diferite. Publicați copia din consola Certification Authority la Certificate Templates, apoi verificați din linia de comandă că CA-ul îl oferă acum:

certutil -CATemplates
certutil -TCAInfo

Permisiunile vin în continuare. Acordați Read și Enroll grupurilor care ar trebui să îl ceară și nimic mai mult, păstrați intact accesul de citire al CA-ului însuși și acordați Autoenroll doar acolo unde înregistrarea automată este intenționată și susținută de politica de implementare care o face să funcționeze. O casetă din șablon nu înregistrează nimic de la sine, iar un șablon publicat fără permisiune de înregistrare produce un portal care listează certificatul și apoi refuză cererea.

Înregistrați un pilot la consumatorul real

Cereți certificatul în contextul care îl va folosi, apoi examinați ce a revenit în loc să aveți încredere în numele fișierului. Un certificat de utilizator ajunge în magazinul utilizatorului curent, iar unul de computer în magazinul computerului local, și MMC le arată pe amândouă, de aceea o înregistrare care „a funcționat” poate rămâne invizibilă pentru serviciul VPN.

certlm.msc
certutil -dump vpn-gateway.cer

Citiți dump-ul pentru subiect, numele alternative, utilizarea extinsă a cheii și lanț. Pentru un gateway care nu este Windows, trimiteți cererea prin fluxul de lucru acceptat în loc să presupuneți că înregistrarea automată a domeniului ajunge la el, și confirmați că formatul exportat este unul pe care consumatorul îl importă împreună cu cheia sa privată corespunzătoare. În final, țineți încrederea și autorizarea separate: VPN-ul trebuie încă să decidă ce utilizatori sau dispozitive ajung la ce resurse, iar revocarea retrage accesul doar dacă gateway-ul verifică revocarea. Ghidul Microsoft pentru gestionarea șabloanelor de certificate acoperă consola de șabloane, permisiunile și pasul separat de publicare.