proveedor de credenciales samf de Adfs

Question

proveedor de credenciales samf de Adfs

Navega tus respuestas

#1 de Steve (1 votos)

2

¿Quería ver si lo siguiente es factible o hay una salida?

Mi situación, las computadoras siempre tienen acceso a Internet (suposición)
Quiero escribir un proveedor de credenciales con un navegador incrustado y hablar con un identificador externo de saml shib
Después de que el token de saml sea publicado por shib Idp, quiero enviarlo a AD
Aquí es donde estoy en un dilema: ¿AD puede liberar SID y otra información al proveedor de credenciales para abrir las ventanas del escritorio (es decir, en la lista de la contraseña de usuario tradicional de inicio de sesión enviada a AD a través del inicio de sesión de Windows)? Si es así, ¿qué versión y qué cambios de configuración necesito hacer?

¿Alguna documentación que pueda señalarme?

Aprecia cualquier entrada de tu final

authentication windows saml adfs

pregunta tech_geek 23.11.2016 - 10:42

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication windows saml adfs

Dotdotpwn - Diferentes patrones de texto Generación de lista de contraseñas, permutaciones y contraseñas largas

score 1 · Answer 1

No, en realidad no. O sorta, supongo, pero no es utilizable.

Puedes simularlo creando un token local, que eventualmente creará una sesión y llegará al escritorio, pero estás paralizado porque Windows no tiene un ticket AD. Como tal, no puede alcanzar nada en el dominio, y cualquier cosa que requiera Kerberos o autenticación NTLM fallará de manera espectacular.

Además, no puede obtener un boleto (de manera segura, de todos modos) de AD para un usuario, y no puede hacer que uno, sin la autenticación propiamente dicha de AD. El token SAML emitido no tiene relación con el ticket, por lo que AD no sabría qué hacer con él.

Una cosa que podría considerar es crear un paquete SSPI tanto en el cliente como en el DC, que intercambiaría un token SAML por un boleto Kerberos, en virtud del hecho de que AD tiene los permisos necesarios para hacer lo que quiera. Sin embargo, el problema es que todos necesitan el paquete, y todos deben entender cómo usar el paquete.

Además de todo eso, abrir una sesión del navegador en el contexto del Proveedor de credenciales es francamente aterrador porque se ejecuta como SISTEMA.