Cómo implementar sso con Windows
1. Integración del inicio de sesión del dominio de Windows y el servidor SSO
1.1 Análisis: el proceso de inicio de sesión del dominio de Windows utiliza el protocolo Kerberose v5 para iniciar sesión. El proceso es muy complicado y la identidad. La autenticación y los derechos de dominio durante el inicio de sesión son
Integración limitada. Es muy difícil eliminar la autenticación y los permisos. Para integrar servidores SSO existentes, puede considerar usar un controlador de dominio de Windows para administrar los usuarios de manera uniforme. El servidor SSO usa la información del usuario en Active Directory del controlador de dominio. Inicio de sesión en estación de trabajo Windows (como winxp)
Durante el proceso de dominio, mantenga el proceso de inicio de sesión del dominio original y agregue el proceso de inicio de sesión del servidor SSO.
1.2 Implementación: al modificar el módulo GINA, durante el proceso de iniciar sesión en el dominio en una estación de trabajo Windows (como winxp), winlogon llama al módulo de grupo GINA para transmitir la cuenta y la contraseña proporcionadas por el usuario
a GINA, GINA es responsable de verificar la validez de la cuenta y la contraseña en el controlador de dominio y el servidor SSO, y luego enviar los resultados de la verificación al programa Winlogon solo al controlador de dominio y al. El servidor SSO se autentica exitosamente al mismo tiempo.
Se desarrolla otro programa DLL, llamado temporalmente módulo SSOLogin. Después de iniciar sesión exitosamente, GINA pasa la información de inicio de sesión SSO al módulo SSOLogin. Cuando se inicia la estación de trabajo, la energía
llama por primera vez. El módulo SSOLogin determina el usuario que inició sesión y luego, al acceder a otras aplicaciones a través de la estación de trabajo eléctrica, se puede realizar el inicio de sesión único a través del servidor SSO.
1.3 Puntos técnicos:
(1) Realice el inicio de sesión del dominio del servidor SSO en Active Directory a través de jCIFS.
(2) Utilice el marco de desarrollo WFC para modificar GINA.dll y registrarlo en el registro.
1.4 Riesgos y dificultades: (1) Análisis y transformación del proceso de inicio de sesión del dominio de Windows . (2) Dado que las aplicaciones de Windows no son de código abierto, el análisis del código será más difícil.
1.5 Otros: ¿Sigues considerando el proceso de agregar el sistema operativo Linux al dominio de Windows?
1.6 El proceso de inicio de sesión en el dominio winxp es el siguiente:
(1). El usuario primero presiona la combinación de teclas Ctrl Alt Del.
(2).Winlogon detecta que el usuario presiona la tecla SAS y llama a GINA, que muestra el cuadro de diálogo de inicio de sesión para que el usuario ingrese su número de cuenta y contraseña.
(3) El usuario selecciona el dominio para iniciar sesión y completa el número de cuenta y la contraseña. Después de la confirmación, GINA envía la información
ingresada por el usuario a LSA para su verificación. .
(4). Cuando el usuario inicia sesión en la máquina local, LSA envía la solicitud al paquete de autenticación Kerberos.
Genera una clave basada en la información del usuario a través de un algoritmo hash y almacena la clave en la caché del certificado.
(5).El programa de autenticación Kerberos envía una solicitud de servicio de autenticación que contiene información de identidad del usuario y datos de preprocesamiento de autenticación al KDC (Centro de distribución de claves)
, que contiene el certificado del usuario
y un sello del tiempo de cifrado del algoritmo hash.
(6) Después de que KDC recibe los datos, utiliza su propia clave para descifrar la marca de tiempo en la solicitud. Se puede juzgar por
si la marca de tiempo descifrada es correcta. . Si el usuario es válido.
(7) Si el usuario es válido, KDC enviará un TGT (Boleto de concesión de boletos--
Ticket de concesión de boletos) al usuario. El TGT (AS_REP) descifra la clave del usuario, que contiene la clave de sesión,
el nombre de usuario al que apunta la clave de sesión, la vida útil máxima del ticket y otros números que puedan ser necesarios
p>
Datos y configuraciones, etc. El ticket solicitado por el usuario se cifra en la clave del KDC y se adjunta a AS_REP.
La parte de datos de autorización del TGT contiene el SID de la cuenta de usuario y el
SID del grupo global y grupo universal al que pertenece el usuario. Tenga en cuenta que el SID devuelto al LSA contiene el token de acceso del usuario. La vida útil máxima de un ticket está determinada por la política del dominio
. Si un ticket caduca durante una sesión activa, el usuario deberá solicitar un nuevo ticket.
(8). Cuando un usuario intenta acceder a un recurso, el sistema cliente utiliza TGT para solicitar un ticket de servicio (TGS_REQ) de Kerberos en el controlador de dominio
TGS. Luego, TGS envía el ticket de servicio (TGS_REP) al cliente. El ticket de servicio se cifra mediante la clave del servidor. Al mismo tiempo, el servicio Kerberos copia el SID del TGT a todos los tickets de servicio de subsecuencia contenidos en el servicio Kerberos.
(9) El cliente envía el ticket directamente al servicio de red al que necesita acceder, y el ticket de servicio puede probar
la identificación del usuario y los permisos para el servicio, como así también. así como la correspondencia del servicio La identificación del usuario.