Es posible que experimente lentitud mientras usa notificaciones de SAML con SharePoint 2010

  • Article

Artículo original publicado el jueves, 14 de julio de 2011

Hola a todos, nuestro buen amigo Adam C. de soporte técnico de SharePoint hace poco nos alertó sobre una queja que estamos viendo que los clientes que usan notificaciones de SAML presentan con más frecuencia. Empieza como un retraso muy prolongado para iniciar sesión en un sitio con autenticación de SAML. Si supervisa las solicitudes mediante una herramienta como Fiddler, puede ver que la mayor parte del tiempo se invierte en el servidor de SharePoint, muy posiblemente en el subdirectorio /_trust. Si experimenta este comportamiento y encuentra que su solicitud pasa la mayor parte del tiempo en el servidor de SharePoint, es posible que su conjunto de servidores no tenga acceso a Internet. Posiblemente vea esto si activa el registro CAPI2 en los servidores de SharePoint. Adam explica cómo hacerlo aquí:

CAPI2 es la nueva API de criptografía disponible en Vista/2008. El diagnóstico de CAPI2 mejora en gran medida el diagnóstico de PKI disponible en 2000/XP/2003. La información de diagnóstico de CAPI2 se registra en el registro operativo de CAPI2, que se encuentra en Registros de aplicaciones y servicios\Microsoft\Windows\CAPI2\Operativo en Visor de eventos. Puede usar registros de CAPI2 para solucionar los problemas de la mayoría de operaciones de PKI en Vista/2008.

El registro de CAPI2 no está habilitado de forma predeterminada. Para habilitarlo, haga clic con el botón secundario en el registro operativo de CAPI2 en Visor de eventos y seleccione Habilitar registro. También puede habilitarlo con Wevtutil:

wevtutil.exe sl Microsoft-Windows-CAPI2/Operativo /e:true

Para deshabilitarlo con Wevtutil, la sintaxis es:

wevtutil.exe sl Microsoft-Windows-CAPI2/Operativo /e:false

Para obtener más información, consulte Solucionar problemas de PKI en Windows Vista

Una vez que haya habilitado el registro de CAPI2, deberá autenticar nuevamente SharePoint, y ver en el Visor de eventos. Si ve los códigos de evento 11 (BuildChain) y 53 (Recuperar objeto desde la red), debe observar el evento 53 más de cerca y ver si está intentando hacer una solicitud a https://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab. Si ve esto y su conjunto de servidores no tiene acceso a Internet, tendrá que soportar todo tipo de pesados tiempos de espera mientras intenta llegar allí. Por ahora, puede solucionar alternativamente este problema de dos maneras:

  1. Exporte el certificado “SharePoint Root Authority” desde SharePoint e importe al almacenamiento Entidades emisoras raíz de confianza. Vaya a MMC Certificados y exporte el certificado SharePoint Root Authority, y luego impórtelo en las Entidades emisoras raíz. Encontrará estas dos cosas en el almacenamiento Certificado de equipo, y encontrará el certificado SharePoint root authority en el nodo de SharePoint en MMC.
  2. Deshabilite la recuperación de certificados de raíz de terceros desde la red mediante la directiva de grupo. Para hacer esto, vaya a su GPO y desglose Configuración del equipo, Configuración de Windows, Configuración de seguridad, Directivas de clave pública. Busque allí una directiva llamada Configuración de validación de rutas de certificados, ábrala y haga clic en la ficha Recuperación de red. Marque la casilla que dice “Definir esta configuración de directiva” y luego asegúrese de desmarcar la casilla que dice “Actualizar certificados automáticamente en el Programa de certificados raíz de Microsoft (recomendado)”.

Una vez que haya realizado estos cambios, podrá notar que los tiempos de inicio de sesión mejoran considerablemente. Gracias de nuevo a Adam por compartir esta información.

 

Esta entrada de blog es una traducción. Puede consultar el artículo original en You May Experience Slowness When Using SAML Claims with SharePoint 2010