Continuando con la serie para reír o llorar, esta semana nos hemos encontrado con un problema bastante divertido en el proyecto en el que estoy trabajando en el momento.
Como ya vamos entrando en la fase final del asunto, hemos comenzado a hacer pruebas de rendimiento, para poder determinar con más precisión en donde hemos metido las de andar. En una de las pruebas, en la que hemos introducido latencia («Latency», la demora que ocurre en la conexión entre un pedido del computador cliente y la respuesta del servidor) nos hemos encontrado con un problema interesante: sin latencia, es decir, teniendo el cliente y el servidor uno al lado del otro teníamos tiempos de respuesta no muy malos, pero cuando introducíamos latencia para simular tráfico entre Europa y Asia, por ejemplo, los tiempos de respuesta se nos crecían de forma muy poco decente.
Para tratar de ver porque era el problema, en las pruebas hemos introducido traceadores para ver qué ocurriría en la «conversación» entre el cliente y el servidor. Para nuestra sorpresa nos hemos encontrado con cantidades de errores 401, es decir acceso denegado; inclusive usando cuentas de administrador de la granja, con todos los permisos del mundo, los 401 seguían apareciendo.
Haga la prueba siguiente: un servidor recién instalado de MOSS, con un sitio de publicación completamente por defecto. Llame la pagina inicial por unas cuantas veces para establecer una conexión estable con el servidor. Limpie el cache del navegador y llame la pagina inicial de nuevo. Ahora revise los logs de IIS: no encontrara ningún error 401. Refresque la pagina inicial (con F5, por ejemplo). Revise los logs de nuevo: encontrara entre 16 y 20 errores 401. Explicación? Ninguna. Es reproducible? Completamente y tantas veces como desee.
Entre otras cosas, para hacer pruebas de este tipo puede utilizar herramientas como HttpWatch (no gratis) o Fiddler (gratis). Ah, y otra cosa, 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. Para ver más información sobre Kerberos, revise el articulo en http://www.gavd.net/servers/sharepoint/sps_item.aspx?top=0&itm=292 y para ver como cambiar la autorización en SharePoint de NTML a Kerberos el articulo http://www.gavd.net/servers/sharepointv3/spsv3_item.aspx?top=4&itm=397. 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.
En cualquier caso, si lo que necesita es hacer que los tiempos de respuesta disminuyan rápidamente sin gran esfuerzo, cambie de NTML a Kerberos, y vera incrementos inmediatos (dependiendo, por supuesto de la latencia… y contra la latencia no podemos hacer nada, es simplemente un hecho físico: que tan rápido puede viajar una señal entre dos puntos). El problema de Kerberos es, por supuesto, que necesita tener un servidor para mantener las claves, pero eso se puede solucionar fácilmente.
Y sobre todo, continúe sonriendo… esta vez no de una de esas «características no documentadas» SharePoint, sino de algo muy particular de IIS…
Gustavo – http://www.gavd.net/servers/
Escriba un Comentario que me haga reir…
Que cosas tiene la vida… este mismo problema me ha mordido a mí en un proyecto de TFS. Las credenciales NTLM no son capaces de fluir desde el Sharpoint hasta el Reporting Services y no se muestran los informes… la solución como bien dices es Kerberos pero si tienes el AD en modo Mixto, no puedes usar Kerberos y te encuentras en un callejón sin salida.
Espero que hoy hayas aprovechado para darles caña a los del equipo de producto de Sharpoint jajjajaja…
¡Un saludo!
El protocolo NTLM funciona así desde hace mucho tiempo, no es nada nuevo y no es algo que tenga que ver con el diseño de Sharepoint.
NTLM tampoco tiene capacidad de delegación, por eso tienes que utilizar Kerberos con Reporting Services, Performance Point, etc…
En general se recomienda utilizar Kerberos en vez de NTLM con Sharepoint, solo que la configuración por defecto es NTLM porque para Kerberos hay que hacer configuración manual adicional.
http://en.wikipedia.org/wiki/NTLM
Saludos.