Projektado de AD CS-ŝablonoj por roloj de VPN-pordego kaj kliento

Entreprena CA povas eldoni ĉiun atestilon, kiun VPN bezonas, sen iam esti la pordego mem. La projektlaboro estas decidi, kion ĉiu flanko devas pruvi, kaj poste, kiu ŝablono povas eldoni legitimilon, kiu pruvas ĝuste tion. Mi komencas per rola tabelo, duobligas taŭgan ŝablonon anstataŭ redakti unu surloke, fiksas la fonton de la subjekto por ĉiu rolo, publikigas la rezulton ĉe la eldonanta CA, kaj enskribas unu piloton antaŭ ol iu ajn aŭtomatigas ĝin. Ĉiu paŝo sube estas loko, kie funkcianta CA ankoraŭ produktas atestilon, kiun la VPN rifuzos.

Skribu la rolan tabelon antaŭ ol malfermi la ŝablonan konzolon

Du roloj, du celoj. La pordego pruvas servan identecon, do ĝia atestilo bezonas Server Authentication (1.3.6.1.5.5.7.3.1), ŝlosiluzon por cifereca subskribo kaj ŝlosila ĉifrado, kaj la gastigan nomon, kiun la klientoj alvokas, en alternativa subjekta nomo. Klientoj, kiuj aŭtentikigas per atestiloj, bezonas Client Authentication (1.3.6.1.5.5.7.3.2) kaj identecon, kiu kongruas kun tio, kion la pordego atendas en sia kontrolo de la alia flanko. Uzanta atestilo kaj komputila atestilo ne estas interŝanĝeblaj, ĉar ili loĝas en malsamaj konservejoj kaj estas uzataj de malsamaj procezoj.

Notu kvar kolumnojn por ĉiu rolo: la identecon, kiu devas aperi, la celon, la ŝlosiluzanton, kaj ĉu la ŝlosilo rajtas forlasi la maŝinon. Tiu tabelo decidas ĉiun markobuton poste, kaj ĝi ankaŭ estas tio, kion vi donas al recenzanto. Pasvortbazita klienta aŭtentikigo estas aparta branĉo: se la pordego aŭtentikigas uzantojn per akreditaĵoj, disdoni klientajn atestilojn aldonas laboron sen aldoni pruvon.

Duobligu ŝablonon anstataŭ redakti komunan

Komencu de ŝablono kun proksimume la ĝusta celo, ekzemple RAS and IAS Server por la pordego aŭ Computer por domajne aliĝintaj aparatoj, poste duobligu ĝin kaj donu al la kopio nomon, kiu diras por kio ĝi estas. Larĝigi ŝablonon, kiun aliaj servoj jam uzas, estas la ŝanĝo, kiu rompas ion nerilatan ses semajnojn poste. Sur la kopio, agordu la aplikajn politikojn al la celo el la rola tabelo, tenu la ŝlosiluzon konsekvenca kun ĝi, elektu la ŝlosilan algoritmon kaj longon, kiujn viaj pordegoj akceptas, kaj marku la privatan ŝlosilon kiel neeksporteblan, krom se aparato bezonas eksporti ĝin por transloki ĝin.

Valideco kaj renovigo ankaŭ apartenas al la ŝablono. Mallonga vivo estas pli facile revokebla kaj pli malfacile prizorgata; longa reduktas la enskriban laboron kaj plilongigas la eksponon de likinta ŝlosilo. Elektu nombron, kiun vi povas defendi, kaj notu, ke la propra valideco de la CA kaj la renoviga periodo de la ŝablono povas mallongigi la rezulton.

Decidu, de kie venas la subjekto

Por domajna komputilo aŭ uzanto, konstruu la subjekton el adresara informo, por ke la nomo ne povu esti tajpita de la petanto. Por pordego, kiu ne estas domajne aliĝinta, aŭ aparato, kies identeco estas asignita ekster AD, la ŝablono bezonas anstataŭe kontrolitan petan vojon. Ebligi petant-provizitan subjekton kaj alternativajn nomojn estas vera decido: ĝi ne estas permesilo por ĉiu enskribito postuli iun ajn nomon, kaj la politiko ĉe la CA-flanko ankoraŭ devas diri, kiu rajtas peti kaj kiu pruvo estas bezonata.

Windows IKEv2 estas strikta ĉi tie. Pordega atestilo estas komparata kun la nomo, kiun la kliento agordis, do la DNS-nomo devas ĉeesti tie, kie la kliento serĉas ĝin, kutime dNSName-ero en la alternativa subjekta nomo. Malŝalti nomkontrolon aŭ celkontrolon por igi malkongruan atestilon funkcii forigas la kontrolon, kiu kaptus la malkongruon en produkto.

Publikigu la ŝablonon, poste mallarĝigu la permesojn

Krei la ŝablonan objekton en AD DS kaj publikigi ĝin ĉe la eldonanta CA estas apartaj operacioj, farataj de malsamaj konzoloj. Publikigu la kopion el la Certification Authority-konzolo sub Certificate Templates, poste kontrolu el la komanda linio, ke la CA nun proponas ĝin:

certutil -CATemplates
certutil -TCAInfo

Permesoj venas poste. Donu Read kaj Enroll al la grupoj, kiuj devas peti ĝin, kaj nenion pli, tenu la propran legan aliron de la CA sendifekta, kaj donu Autoenroll nur tie, kie aŭtomata enskribo estas intencita kaj subtenata de la disfaldiga politiko, kiu igas ĝin funkcii. Markobutono en ŝablono mem enskribas nenion, kaj publikigita ŝablono sen enskriba permeso produktas portalon, kiu listigas la atestilon kaj poste rifuzas la peton.

Enskribu unu piloton ĉe la reala konsumanto

Petu la atestilon en la kunteksto, kiu uzos ĝin, poste ekzamenu, kio revenis, anstataŭ fidi la dosiernomon. Uzanta atestilo finiĝas en la konservejo de la nuna uzanto kaj komputila atestilo en la konservejo de la loka komputilo, kaj MMC montras ambaŭ, tial enskribo, kiu “funkciis”, povas resti nevidebla por la VPN-servo.

certlm.msc
certutil -dump vpn-gateway.cer

Legu la elprenaĵon pri la subjekto, la alternativaj nomoj, la plivastigita ŝlosiluzo kaj la ĉeno. Por pordego, kiu ne estas Windows, sendu la peton tra la subtenata laborfluo anstataŭ supozi, ke domajna aŭtomata enskribo atingas ĝin, kaj konfirmu, ke la eksportita formato estas tiu, kiun la konsumanto importas kune kun sia kongrua privata ŝlosilo. Fine, tenu fidon kaj rajtigon aparte: la VPN ankoraŭ devas decidi, kiuj uzantoj aŭ aparatoj atingas kiujn rimedojn, kaj revoko forigas aliron nur se la pordego entute kontrolas revokon. La gvidilo de Microsoft pri administrado de atestilaj ŝablonoj kovras la ŝablonan konzolon, permesojn kaj la apartan publikigan paŝon.