%20en%20certificados%20de%20cliente%20SSL%2FTLS.png)
Estoy usando certificados de cliente X.509 para autenticar un conjunto de clientes de Windows mediante TLS mutuo. ¿Qué clientes forman parte de este conjunto?deberíaadministrarse de alguna manera en AD, por ejemplo, a través de membresía de grupo o unidad organizativa principal.
Nota: La pregunta se aplica a los certificados de computadora, no a los certificados de usuario. Es decir, cualquier usuario debería poder utilizar este certificado al iniciar una solicitud HTTPS desde dicha computadora. (Esto se suma a cualquier método de inicio de sesión de usuario, que no forma parte del esquema de autenticación mTLS).
Los servidores deberían poder decir que la computadora cliente de autenticación es miembro de este conjunto. Los servidores son contenedores basados en Linux y no forman parte del dominio/AD, por lo que todo lo que tenemos es la información en el certificado X.509.
¿Las plantillas de certificados de Windows proporcionan algún método para transmitir dicha afirmación como parte del certificado X.509? Parece que puedo limitar el conjunto de computadoras que pueden obtener dicho certificado, pero no encuentro una manera de marcar estos certificados de una manera que permita al servidor identificarlos.
- El certificado X.509 no contiene el nombre de la plantilla administrativa ni el ID, por lo que tampoco puedo configurar el servidor para que lo verifique.
- Parece haber una flexibilidad limitada en la configuración de temas, específicamente ningún método para asignar información de AD al campo de tema. Sería ideal. ¿Me estoy perdiendo algo aquí?
- Estaba pensando en utilizar una CA intermedia específica para estas plantillas, pero parece demasiado complicado para requisitos tan básicos.
¿Quizás haya otro aspecto del certificado X.509 que se pueda configurar a través de la plantilla? ¿O puedo utilizar un reclamo diferente al de grupo/OU?
Respuesta1
La respuesta es no. La pertenencia a un grupo es una propiedad bastante dinámica, no estática y no forma parte de la identidad del titular del certificado. Como resultado, no puede incluir la pertenencia a un grupo en un certificado porque esta información no pertenece a la identidad. Y cada vez que se cambia la membresía del grupo, debe volver a emitir el certificado. Los certificados son válidos por un período bastante largo. Esta es una solución muy defectuosa.
Es decir, cualquier usuario debería poder utilizar este certificado al iniciar una solicitud HTTPS desde dicha computadora.
esto funcionará solo cuando la solicitud TLS se envíe desde una aplicación que se ejecuta en el sistema local o en una cuenta de servicio de red. Si desea utilizar dichos certificados, debe configurar explícitamente el cliente TLS para utilizar un certificado de cliente no predeterminado a través del código fuente, por ejemplo.
Los servidores son contenedores basados en Linux y no forman parte del AD/dominio
Interesante, ¿cómo se supone que los servidores basados en Linux validan la membresía real del grupo?
El certificado de cliente en TLS mutuo es un método de autenticación. Los campos del certificado están asignados a la información de la cuenta a la que se deben conectar los servidores.
Dado que sus servidores Linux no forman parte de ningún AD, no pueden vincular el certificado del cliente a la cuenta de usuario de AD ni validar la membresía del grupo. Los servidores ni siquiera pueden decir si ese grupo realmente existe. Debe haber una base de datos de identidad separada disponible para los servidores Linux y los servidores Linux deben vincular de alguna manera el certificado del cliente a la identidad en esa base de datos de identidad separada. Y solo se utilizará la información disponible en esta base de datos de identidad separada para la autorización del cliente.
Esto significa que sus requisitos:
La membresía de grupo para computadoras debe administrarse en AD.
y
Los servidores son contenedores basados en Linux y no forman parte del AD/dominio
son mutuamente excluyentes y no pueden usarse juntos. Haga que el servidor Linux sea compatible con AD o incluya en los certificados información sobre la identidad que está disponible para los servidores Linux. Y evitaría enfáticamente la inclusión de membresía de grupo en los certificados. La membresía de grupo debe usarse en tokens de corta duración, no en certificados de larga duración.