¿Por qué kerberos está por defecto en NTLM en WCF?

Tengo una aplicación de demostración WCF simple que tiene dos proyectos de consola: host y cliente. Ambos se ejecutan en mi máquina (cuadro de ganar 7). Estoy usando netTcpBinding, que usa la autenticación de Windows.¿Por qué kerberos está por defecto en NTLM en WCF?

El problema es que la autenticación se está degradando a NTLM desde kerberos, y no puedo entender por qué.

Si uso

<clientCredentials> 
    <windows allowNtlm="true" /> 
</clientCredentials>

en el lado del cliente, todo es fresco. Pero si cambio que a false, me sale el siguiente excepción:

SecurityNegotiationException: El servidor remoto no cumplía el requisito de autenticación mutua .

Esto sugiere que kerberos está fallando y dado que el cliente no permitirá NTLM, la llamada genera una excepción.

¿Es este un problema con el proyecto, o es un problema externo causado por la configuración de mi máquina de desarrollo?

Solución:

Al parecer, tengo que especificar la identidad del servidor dentro de la configuración del cliente. En mi caso, el servidor se ejecuta en mi identidad, por lo que modificar el cliente de esta manera:

<client> 
    <endpoint address="net.tcp://dev7.HurrDurr.com:12345/MyService" 
      binding="netTcpBinding" 
      bindingConfiguration="MyBindingConfigurationLol" 
      behaviorConfiguration="HurrDurrServiceEndpoint" 
      contract="ShaolinCore.ICommunicationService"> 
    <!-- start changes here --> 
    <identity> 
     <userPrincipalName value="[email protected]"/> 
    </identity> 
    <!-- end changes here --> 
    </endpoint> 
</client>

No estoy seguro de por qué esto soluciona el problema. De acuerdo, ahora en el lado del cliente confío totalmente en el servidor (hey, ¡lo conozco!). Pero dado que NTLM es menos seguro que kerberos, ¿por qué no es al revés? Si no confío plenamente en el servidor, uso kerberos, de lo contrario ntlm está bien.

O, OTOH, si no confío plenamente en el servidor, ¿por qué funciona en absoluto? "SecurityException: la identidad del punto final no está establecida. WCF no puede confiar en la identidad del servidor y no transmitirá la identidad del cliente".

Fuente

2010-02-23 Will

Parece una pregunta para serverfault.com. – phkahler

solución listada: Kerberos es más seguro por esta razón: el servidor es una fuente confiable y conocida con una identidad garantizada tanto en términos de direcciones ** como ** que se ejecutan en esa dirección. Una cuenta de servicio que se ejecuta como un usuario diferente no podrá procesar su solicitud. – Hogan

@hogan Creo que curb/ntlm es más acerca de la autenticación que de la autorización. Permítanme autenticarme con cualquier servidor que use el bordillo; una vez que sé quién es el servicio, puedo decidir si quiero tratar con ellos. Si me autentico con el bordillo, tengo la identidad del servicio proporcionado por un tercero de confianza (AD). Si el servicio está siendo falsificado, puedo decir por esa identidad y lanzar una excepción si no se espera. En WCF, parece que un servidor falso fallará el bordillo y luego pasará con ntlm. Eso no me parece seguro. Autenticémonos con cualquiera, tira si no son lo que esperaba. – Will

¡Cuando trabajé en los equipos de desarrollo IIS4, 5 y 6 nos encontramos con esto mucho!Para encintado para trabajar, necesita las siguientes condiciones para ser verdad:

1) Ambas partes apoyan acera (todas las versiones compatibles de encintado de soporte de Windows hoy)

2) Máquinas de autenticación de Active Directory

3) Nombres principales de servicio (SPN) registrados para el punto final del servidor. En los "buenos viejos tiempos", tenía que hacer esto a mano usando SetSPN.exe. Un SPN es solo un punto final al que se conectará Curb; necesita esta información para soportar Authn mutua. La mayoría de las aplicaciones se llaman a la API approp a este trabajo para usted (DsWriteAccountSpn)

Si alguno de los pasos anteriores no son verdaderas, Windows por lo general por defecto en NTLM, lo que se agradece le da sólo la autenticación de cliente.

Espero que ayude! - Michael

Fuente

2010-02-23 22:16:27

He leído un libro o dos acerca de la seguridad de Windows, y todavía es confuso a veces. No entiendo cómo WCF maneja la autenticación mutua también, por lo que es doblemente difícil. ¿Por qué debo proporcionar el servidor UPN/SPN/DNS para habilitar el bordillo en el cliente? Si no confío plenamente en el servidor, ¿por qué ntlm es mejor que el bordillo? ¿O el cliente necesita proporcionar la identidad del servicio a un tercero? ¿Por qué el servicio no puede proporcionarlo directamente? ¿Porque me duele la cabeza? – Will

Curb necesita autenticar al cliente y al servidor y me refiero a * computadoras *. Cuando su código de cliente (WCF) realiza una solicitud para conectarse a un servicio, necesita saber * exactamente * a qué se está conectando, por lo que un administrador necesita agregar el SPN para la aplicación de servidor a AD, en esencia lo que está diciendo es Curb. "Necesito conectarme a este SPN". En muchos casos, el lado del servidor de la ecuación * WILL * volverá a generar un SPN, pero solo si tiene la capacidad para hacerlo. NTLM no es mejor que Curb, NTLM autentica solo un cliente, por lo que el servidor sabe quién es usted, pero no tiene idea de a quién se está conectando. –

También: kerberos solo se puede usar cuando se invoca el servicio a través de un nombre DNS. Invocar el servicio a través de la dirección IP dará como resultado el uso de NTLM – bug

¿Cómo se configura el servidor? ¿Tiene <authentication mode="Windows"/> y <identity impersonate="true"/> en el archivo de configuración?

se establece el modo de autenticación a través de la etiqueta de autenticación en el fichero de configuración:

<configuration> 
    <system.web> 
    <authentication mode="Windows" /> 
    </system.web> 
</configuration>

Fuente

2010-02-23 14:58:07 Hogan

Creo que estos solo se aplican a enlaces HTTP. Estoy especificando que mi clientCredentialType es Windows, sin embargo. – Will

Nuevamente, funciona si el cliente permite ntlm, de lo contrario falla (es decir, creo que kerberos no está disponible). – Will

AFAIK no solo se aplican a http. – Hogan

Quizás esta página en MSDN - Debugging Windows Authentication Errors - ayuda a averiguar lo que está pasando - parece ser bastante complicado en cuanto a cuando NTLM contra Kerberos está siendo utilizado.

Fuente

2010-02-23 15:18:59

k ... usuario del dominio en ambos extremos, verifique. URL completamente calificada, actualizada, sin diferencias. Identidad añadida/UPN ... sin diferencias. Configurando la identidad de SPN en el cliente ... ¡BINGO! – Will

@Will: Genial, estaba a punto de sugerirle que verifique los SPN en el servidor y el cliente. – Hogan

Fyi a través de MSDN: netTcpBinding: El enlace predeterminado usa seguridad de transporte con autenticación negociada. Esta negociación intenta usar Kerberos, pero si eso no funciona, retrocederá y usará el protocolo NTLM anterior. Kerberos es una gran opción si estás en un entorno de dominio; para usarlo, necesitará que tanto su servicio como sus clientes se ejecuten en cuentas de dominio. También querrá configurar un nombre principal de servicio (SPN) para su servicio.

Fuente

2010-02-23 18:52:48 kd7

Entonces, en teoría, después de leer sus comentarios que no leí inicialmente, el comportamiento parece ser por diseño. – kd7

¿Por qué kerberos está por defecto en NTLM en WCF?

Respuesta

Cuestiones relacionadas