Disseny de plantilles d'AD CS per als rols de passarel·la VPN i client

Una CA d'empresa pot emetre tots els certificats que necessita una VPN sense ser mai la passarel·la. La feina de disseny és decidir què ha de demostrar cada extrem i, després, quina plantilla pot emetre una credencial que demostri exactament això. Començo amb una taula de rols, duplico una plantilla adequada en lloc d'editar-ne una al seu lloc, fixo l'origen del subjecte per rol, publico el resultat a la CA emissora i inscric un pilot abans que ningú ho automatitzi. Cada pas de sota és un punt on una CA que funciona encara produeix un certificat que la VPN rebutjarà.

Escriviu la taula de rols abans d'obrir la consola de plantilles

Dos rols, dos propòsits. La passarel·la demostra una identitat de servei, així que el seu certificat necessita Server Authentication (1.3.6.1.5.5.7.3.1), un ús de clau de signatura digital i xifratge de clau, i el nom d'amfitrió al qual es connecten els clients dins d'un nom alternatiu del subjecte. Els clients que s'autentiquen amb certificats necessiten Client Authentication (1.3.6.1.5.5.7.3.2) i una identitat que coincideixi amb el que la passarel·la espera a la seva comprovació de l'altre extrem. Un certificat d'usuari i un certificat d'ordinador no són intercanviables, perquè viuen en magatzems diferents i els fan servir processos diferents.

Anoteu quatre columnes per a cada rol: la identitat que hi ha d'aparèixer, el propòsit, el consumidor de la clau i si la clau pot sortir de la màquina. Aquesta taula decideix cada casella més endavant i també és el que lliureu a un revisor. L'autenticació de clients amb contrasenya és una branca a part: si la passarel·la autentica usuaris amb credencials, distribuir certificats de client afegeix feina sense afegir cap prova.

Dupliqueu una plantilla en lloc d'editar-ne una de compartida

Partiu d'una plantilla amb un propòsit aproximadament correcte, com ara RAS and IAS Server per a la passarel·la o Computer per a dispositius units al domini, després dupliqueu-la i doneu a la còpia un nom que digui per a què serveix. Ampliar una plantilla que altres serveis ja utilitzen és el canvi que trenca una cosa no relacionada sis setmanes més tard. A la còpia, fixeu les polítiques d'aplicació al propòsit de la taula de rols, manteniu l'ús de clau coherent amb ell, trieu l'algorisme i la longitud de clau que accepten les vostres passarel·les i marqueu la clau privada com a no exportable tret que un aparell necessiti exportar-la per moure-la.

La validesa i la renovació també pertanyen a la plantilla. Una vida curta és més fàcil de revocar i més difícil d'operar; una de llarga redueix la feina d'inscripció i allarga l'exposició d'una clau filtrada. Trieu un número que pugueu defensar i tingueu present que la validesa pròpia de la CA i el període de renovació de la plantilla poden escurçar el resultat.

Decidiu d'on ve el subjecte

Per a un ordinador o usuari de domini, construïu el subjecte a partir de la informació del directori perquè el sol·licitant no pugui escriure el nom. Per a una passarel·la que no està unida al domini, o un dispositiu la identitat del qual s'assigna fora de l'AD, la plantilla necessita en canvi un camí de sol·licitud controlat. Habilitar el subjecte i els noms alternatius proporcionats pel sol·licitant és una decisió real: no és una llicència perquè cada inscrit reclami qualsevol nom, i la política del costat de la CA encara ha de dir qui pot demanar i quina evidència cal.

Windows IKEv2 és estricte aquí. El certificat de la passarel·la es compara amb el nom que el client ha configurat, així que el nom DNS ha de ser present on el client el busca, normalment una entrada dNSName al nom alternatiu del subjecte. Desactivar la comprovació de nom o de propòsit per fer funcionar un certificat que no coincideix elimina la comprovació que hauria detectat la discrepància en producció.

Publiqueu la plantilla i després limiteu els permisos

Crear l'objecte de plantilla a l'AD DS i publicar-lo a la CA emissora són operacions separades, fetes amb consoles diferents. Publiqueu la còpia des de la consola Certification Authority a Certificate Templates i després verifiqueu des de la línia d'ordres que la CA ja l'ofereix:

certutil -CATemplates
certutil -TCAInfo

Els permisos vénen després. Concediu Read i Enroll als grups que l'han de sol·licitar i res més, manteniu intacte l'accés de lectura propi de la CA i concediu Autoenroll només on la inscripció automàtica és volguda i està recolzada per la política de desplegament que la fa funcionar. Una casella de la plantilla no inscriu res per si sola, i una plantilla publicada sense permís d'inscripció produeix un portal que llista el certificat i després rebutja la sol·licitud.

Inscriviu un pilot al consumidor real

Sol·liciteu el certificat en el context que el farà servir i després examineu què ha tornat en lloc de confiar en el nom del fitxer. Un certificat d'usuari acaba al magatzem de l'usuari actual i un d'ordinador al magatzem de l'ordinador local, i MMC mostra tots dos, per això una inscripció que “ha funcionat” pot continuar sent invisible per al servei VPN.

certlm.msc
certutil -dump vpn-gateway.cer

Llegiu l'abocament pel que fa al subjecte, els noms alternatius, l'ús de clau millorat i la cadena. Per a una passarel·la que no és Windows, envieu la sol·licitud pel flux de treball admès en lloc de suposar que la inscripció automàtica del domini hi arriba, i confirmeu que el format exportat és un que el consumidor importa juntament amb la seva clau privada corresponent. Finalment, manteniu la confiança i l'autorització separades: la VPN encara ha de decidir quins usuaris o dispositius arriben a quins recursos, i la revocació només treu accés si la passarel·la comprova la revocació. La guia de Microsoft per gestionar plantilles de certificats cobreix la consola de plantilles, els permisos i el pas de publicació separat.