Oblikovanje predlog AD CS za vloge prehoda VPN in odjemalca

Podjetniška CA lahko izda vsak certifikat, ki ga VPN potrebuje, ne da bi bila kdaj sama prehod. Oblikovalsko delo je odločiti, kaj mora dokazati vsaka stran, in nato, katera predloga lahko izda pooblastilo, ki dokazuje prav to. Začnem s tabelo vlog, podvojim ustrezno predlogo, namesto da bi obstoječo urejal na mestu, določim vir subjekta za vsako vlogo, objavim rezultat na izdajateljski CA in registriram enega pilota, preden kdo to avtomatizira. Vsak korak spodaj je mesto, kjer delujoča CA še vedno ustvari certifikat, ki ga bo VPN zavrnil.

Napišite tabelo vlog, preden odprete konzolo predlog

Dve vlogi, dva namena. Prehod dokazuje identiteto storitve, zato njegov certifikat potrebuje Server Authentication (1.3.6.1.5.5.7.3.1), uporabo ključa za digitalni podpis in šifriranje ključa ter ime gostitelja, na katerega se povezujejo odjemalci, v alternativnem imenu subjekta. Odjemalci, ki se overjajo s certifikati, potrebujejo Client Authentication (1.3.6.1.5.5.7.3.2) in identiteto, ki ustreza temu, kar prehod pričakuje pri preverjanju druge strani. Uporabniški in računalniški certifikat nista zamenljiva, ker živita v različnih hrambah in ju uporabljajo različni procesi.

Zapišite štiri stolpce za vsako vlogo: identiteto, ki se mora pojaviti, namen, porabnika ključa in ali ključ sme zapustiti stroj. Ta tabela pozneje odloča o vsakem potrditvenem polju in je tudi tisto, kar predate recenzentu. Preverjanje odjemalcev z geslom je ločena veja: če prehod overja uporabnike s poverilnicami, distribucija odjemalskih certifikatov doda delo, ne da bi dodala dokaz.

Podvojite predlogo, namesto da urejate skupno

Začnite s predlogo s približno pravim namenom, na primer RAS and IAS Server za prehod ali Computer za naprave, pridružene domeni, nato jo podvojite in kopiji dajte ime, ki pove, čemu je namenjena. Razširjanje predloge, ki jo že uporabljajo druge storitve, je sprememba, ki šest tednov pozneje pokvari nekaj nepovezanega. Na kopiji nastavite pravilnike uporabe na namen iz tabele vlog, ohranite uporabo ključa skladno z njim, izberite algoritem in dolžino ključa, ki ju sprejemajo vaši prehodi, in označite zasebni ključ kot neizvozljiv, razen če ga naprava mora izvoziti za premik.

Veljavnost in obnavljanje pripadata predlogi. Kratka življenjska doba je lažja za preklic in težja za upravljanje; dolga zmanjša delo z vpisom in podaljša izpostavljenost uhajanega ključa. Izberite število, ki ga lahko zagovarjate, in upoštevajte, da lahko veljavnost same CA in obdobje obnavljanja predloge skrajšata rezultat.

Odločite, od kod prihaja subjekt

Za domenski računalnik ali uporabnika zgradite subjekt iz informacij imenika, da prosilec ne more vnesti imena. Za prehod, ki ni pridružen domeni, ali napravo, katere identiteta se dodeljuje zunaj AD, predloga potrebuje namesto tega nadzorovano pot zahteve. Omogočanje subjekta in alternativnih imen, ki jih zagotovi prosilec, je resnična odločitev: ni dovoljenje, da bi vsak vpisan zahteval katero koli ime, in pravilnik na strani CA mora še vedno povedati, kdo sme vprašati in kateri dokaz je potreben.

Windows IKEv2 je tu strog. Certifikat prehoda se primerja z imenom, ki ga je konfiguriral odjemalec, zato mora biti ime DNS prisotno tam, kjer ga odjemalec išče, običajno kot vnos dNSName v alternativnem imenu subjekta. Izklop preverjanja imena ali namena, da bi neustrezni certifikat deloval, odstrani preverjanje, ki bi neskladje ujelo v proizvodnji.

Objavite predlogo in nato zožite dovoljenja

Ustvarjanje objekta predloge v AD DS in njegova objava na izdajateljski CA sta ločeni operaciji, izvedeni v različnih konzolah. Objavite kopijo iz konzole Certification Authority pod Certificate Templates in nato v ukazni vrstici preverite, da jo CA zdaj ponuja:

certutil -CATemplates
certutil -TCAInfo

Dovoljenja pridejo nato. Dajte Read in Enroll skupinam, ki naj bi jo zahtevale, in nič več, ohranite lastni dostop CA za branje in dodelite Autoenroll le tam, kjer je samodejni vpis nameravan in podprt s pravilnikom uvajanja, ki ga omogoča. Potrditveno polje v predlogi samo po sebi ničesar ne vpiše, objavljena predloga brez dovoljenja za vpis pa ustvari portal, ki certifikat navede in nato zahtevo zavrne.

Registrirajte enega pilota pri resničnem porabniku

Zahtevajte certifikat v kontekstu, ki ga bo uporabljal, in nato preglejte, kaj se je vrnilo, namesto da bi zaupali imenu datoteke. Uporabniški certifikat pristane v hrambi trenutnega uporabnika, računalniški pa v hrambi lokalnega računalnika, in MMC prikaže oba, zato je lahko vpis, ki “je uspel“, za storitev VPN še vedno neviden.

certlm.msc
certutil -dump vpn-gateway.cer

Preberite izpis glede subjekta, alternativnih imen, razširjene uporabe ključa in verige. Za prehod, ki ni Windows, oddajte zahtevo po podprtem delovnem toku, namesto da bi predpostavljali, da ga samodejni vpis domene doseže, in potrdite, da je izvožena oblika tista, ki jo porabnik uvozi skupaj s svojim ustreznim zasebnim ključem. Nazadnje imejte zaupanje in avtorizacijo ločena: VPN mora še vedno odločiti, kateri uporabniki ali naprave dosežejo katere vire, preklic pa odvzame dostop le, če prehod preklic sploh preverja. Microsoftov vodnik za upravljanje predlog certifikatov pokriva konzolo predlog, dovoljenja in ločen korak objave.