SharePoint – NTLM vs Kerberos

En todas las instalaciones hay un punto crítico, esa pregunta que no tenemos muy clara  y que en ocasiones va acompañada de un texto recomendando una de las opciones, por si no sabemos muy bien qué es lo que estamos haciendo. MOSS no es una excepción.
La pregunta en cuestión llega cuando tenemos que decidir sobre la seguridad, la instalación de MOSS nos da a elegir entre sí usaremos NTLM ó Kerberos.
Como todos sabemos y Microsoft dice NTLM funciona para casi todo. De modo que suele ser la opción preferida de todos.  No hay que configurar nada y funciona.

Microsoft Windows Integrated Authentication supports the following two protocols that provide challenge/response authentication:

xa68twcb_impflow(en-us,VS_71)

NTLM

El protocolo NTLM es un protocolo seguro de que se basa en nombres de usuario y contraseñas cifradas, antes de enviar los nombres de usuario y contraseñas en la red. Se requiere autenticación NTLM en redes donde el servidor recibe solicitudes de los clientes que no admiten la autenticación de Kerberos.

Kerberos

Protocolo basado en tiquetes. Un usuario provee primero su nombre y clave al servidor de autenticación, el que genera un "tiquete" si las credenciales son aceptadas. El tiquete puede ser utilizado en la red para acceder recursos diferentes. Para usar este esquema, el cliente y el servidor deben tener una conexión de confianza con el servidor de dominio que mantiene el Key Distribution Center (KDC), y ambos deben estar conectados a un servicio de Directorio Activo (AD).

Kerberos por el contrario es un sistema de autentificación un poco más complejo, pero  también más seguro y más rápido (motivos por los cuales ya de por sí, debería ser la opción predilecta de todos).

Kerberos, es más rápido por que guarda en una cache (vales) la información del cliente después de que este se ha autentificado en el sistema, de modo que no tiene que estar comprobando las credenciales una y otra vez.
Otra de las características importantes de Kerberos es la Delegación, La delegación nos permite pasar las credenciales del cliente desde nuestro servidor front-end (SharePoint)  a nuestros servidores back-end (SQL Server etc..).
Cuando usamos NTLM, y deseamos acceder a recursos que están fuera de nuestro alcance, podemos suplantar al cliente (impersonate)  y usar la cuenta de suplantación para realizar las tareas necesarias.
¿Pero qué ocurre cuando tratamos de usar recursos que no están en la misma máquina que nuestro servidor web?, entonces la suplantación no es suficiente. Y se produce el efecto llamado Double-Hop

El double-hop mediante un token secundario se produce, por ejemplo, cuando el cliente del explorador se autentica a la página ASPX IIS utilizando la autenticación NTLM. En este ejemplo, el servidor IIS tiene una versión de hash de la contraseña como consecuencia del uso de NTLM. Si IIS gira en torno y pasa las credenciales a   Active Directory (AD), IIS está pasando una contraseña hash. AD no puede comprobar la contraseña y, en lugar de ello, se autentica mediante el LOGON NTAUTHORITY\ANONYMOUS.

Imaginemos que hemos realizado una solución para SharePoint que usa un servicio web o una conexión a un servidor SQL que se encuentra en una máquina distinta, y deseamos acceder usando la seguridad integrada (Integrated Security=SSPI) .

Al realizar la conexión nuestro servidor web debe ponerse en contacto con nuestro servidor SQL y este no es capaz de autentificar al usuario.
De modo que recibiremos un mensaje como:
Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.

Como mencionaba anteriormente, esto es debido a que la suplantación no es válida, necesitamos algo más; Delegación.
Y esa delegación aunque cueste un poquito más configurarla es la que nos ofrece Kerberos.

Observación : Al instalar Windows SharePoint Services y optar por utilizar la autenticación de Kerberos, pero no configura la cuenta de dominio de que Windows SharePoint Services se está ejecutando como con un SPN (Service Principal Name), los usuarios no podrán iniciar sesión en el sitio de SharePoint. Aquellos usuarios que no son los administradores del equipo servidor recibirán múltiples mensajes de autenticación y recibirá el siguiente error:
HTTP Error 401.1 – Unauthorized: Access is denied due to invalid

Este escenario se produce en multitud de instalaciones de MOSS en donde usamos servicios de Excel, para recuperar datos de los servicios de análisis de SQL.

Un Post interesante sobre: NTLM con SharePoint:

La cual explica como se comporta el protocolo NTLM en su prueba de rendimiento (Latency).

la autorización es NTML. Yendo más adentro en el análisis, si intercepta los paquetes de comunicación entre el cliente y el servidor, vera que el handshake entre los dos ocurre más o menos de la siguiente forma:

1 – Cliente envía al servidor: GET (y otras cosas)
2 – Servidor devuelve al cliente: 401 Unauthorized, utilice NTLM
3 – Cliente envía al servidor: GET (otras cosas), Authorization: NTLM (mensaje 1)
4 – Servidor devuelve al cliente: 401 Unauthorized, utilice NTLM (mensaje 2)
5 – Cliente envía al servidor: GET (otras cosas), Authorization: NTLM (mensaje 3)
6 – Servidor devuelve al cliente: 200 Ok
Mensaje 1 contiene el nombre del host y el nombre del dominio NT del cliente
Mensaje 2 contiene el "desafío" ("Challenge") del servidor
Mensaje 3 contiene el nombre del usuario, del host, del dominio y dos "respuestas" al "desafío"

Y esto ocurre para cada elemento en la pagina que necesita autorización. O sea que se podrá imaginar, cada ida y venida, para cada elemento y todo multiplicado por 300 milisegundos de latencia, los tiempos de respuesta son de todo menos bonitos.

Es posible de evitar este fenómeno? Probablemente no, es algo que está enterrado profundamente en el protocolo del handshake. Lo único que se puede hacer es utilizar Kerberos.

Es algo de lo que tiene que preocuparse?

No, de ninguna manera si sus usuarios están al lado de los servidores de SharePoint en una intranet local;

SI, con toda seguridad si los usuarios están repartidos por todo el mundo y los servidores están regados por tres continentes. (Por así decirlo)

El problema de Kerberos es, por supuesto, que necesita tener un servidor para mantener las claves, pero eso se puede solucionar fácilmente.

Nota: La mayoría de las veces se puede utilizar NTLM; si no hay una necesidad especifica de usar Kerberos o si no puede configurar el Nombre de Servicio Principal (SPN), elija NTLM. Si utiliza Kerberos y no puede configurar el SPN, solamente los administradores del servidor podrán ser autenticados en SharePoint.

About justindeveloper

I am MCP (Microsoft Certified Professional). MCTS (Microsoft Certified Technology Specialist) and MCPD (Microsoft Certified Professional Developer), also I am SAP Business One Certified!! Desarrollando desde el IDE de Visual Studio NET 2003 hasta ahora con el Visual Studio NET 2010. Desde Microsoft SQL Server 2000 hasta ahora con el Microsoft SQL Server 2008 R2 y tambien con SharePoint, desde WSS 3.0 y MOSS 2007 y ahora familirizandome con el Sharepoint Foundation 2010 & Sharepoint Server 2010. The software development will follow being every time more wonderful!
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s