SHAREPOINT 2013 : USE AD GROUPS ? YES, BUT…DON’T FORGET THE SECURITY TOKEN CACHING: LOGONTOKENCACHEEXPIRATIONWINDOW AND WINDOWSTOKENLIFETIME
06 de julio 2013 · por sergeluca · en SharePoint 2013 . ·
Una de las buenas prácticas en materia de seguridad de SharePoint es organizar los usuarios en grupos centralizados (como grupos de Active Directory) gestionados por el servicio de gestión de la identidad de la empresa y para anidar estos grupos en los grupos de seguridad de SharePoint. Este enfoque proporciona una gestión de seguridad fácil
Hay pros y los contras del uso de sólo los grupos de AD, pero básicamente el patrón habitual es:
- en intranet / extranet: utilizar grupos de anuncios y anidar en grupos de SharePoint
- en los sitios de colaboración: jugar más con los grupos de SharePoint y menos con grupos de AD (= más flexibilidad en la gestión de la seguridad)
Uno de mi anuncio usuario contoso \ annab era parte de un grupo de ADdenominada miembros de la intranet .
En mi SP2013 intranet tuve un grupo de miembros de la Intranet (con la edición de nivel de permisos predeterminado).
Todo funcionó a la perfección ... hasta que me quité contoso \ Annab del grupo miembro . Incluso si ella no era parte del grupo más, Annab todavía era capaz de aportar.
Y por lo que yo recordaba, SharePoint 2010 no se comportaba así.
La razón es que por defecto de SharePoint 2013 reclamaciones utilizar la autenticación basada. Así que tenemos que hacer frente a las reclamaciones.
Por defecto, cuando se crea una aplicación web de Administración central, su aplicación web se basa en las reivindicaciones. En mi caso, yo estaba usando notificaciones de Windows muestra-en; las informaciones del grupo AD se convierten en reclamos y empaquetados en token de seguridad emitido por el STS (Security Token Service)
La vida útil de los tokens emitidos a inicios de sesión que utilizan inicio de sesión basado en Windows se define en el WindowsTokenLifetime propiedad del SecurityTokenServiceConfig (el valor predeterminado es de 10 horas)
El LogonTokenCacheExpirationWindow propiedad (10 minutos por defecto) de la SecurityTokenServiceConfig controla cuando SharePoint considerará que el token de seguridad ha caducado y awill pedir al usuario que vuelva a autenticarse con el emisor y obtener un nuevo token. SharePoint comprueba si el token de seguridad ha expirado en el inicio de cada solicitud.
por ejemplo, si WindowsTokenLifetime = 10 minutos y LogonTokenCacheExpirationWindow = 2 minutos
-> Esto significa que después de 10 minutos, 2 minutos = 8 minutos, SharePoint decidirá que el token de seguridad ha caducado.
-> Si el usuario solicita una página de SharePoint nueve minutos después de iniciar sesión, SharePoint comprueba si la sesión está a punto de expirar durante el tiempo en minutos representados por LogonTokenCacheExpirationWindow: en este caso la respuesta es sí, porque nueve más dos es superior al diez .
Estos son los valores por defecto:
La siguiente secuencia de comandos PowerShell establece la vida útil de 2 minutos (en lugar de 10 horas) y los LogonTokenCacheExpirationWindows a 1 minuto:
- $mysts = Get-SPSecurityTokenServiceConfig
- $mysts.WindowsTokenLifetime = (New-TimeSpan -Minutes 2)
- $mysts.LogonTokenCacheExpirationWindow
- $mysts.Update()
Cuando la señal de seguridad expira, el usuario se supone que volver a autenticarse (En realidad no me di cuenta de que, probablemente hay un NTLM re-negociación bajo la cubierta)
Asegúrese de que el LogonTokenCacheExpirationWindow es pequeño que el WindowsTokenLifetTime, de lo contrario el código de autenticación volverá a AD para la autenticación de nuevo. Y así sucesivamente, de ida y vuelta.
Con el fin de asegurarse de que Annab será capaz de ver el sitio, le he añadido a la Intranet Visitantes:
Al hacer clic sobre los miembros de Intranet, se obtiene el siguiente grupo de anuncios:
En este grupo AG, encontrará Annab:
Cuando registro en el sitio e ir a una biblioteca de documentos, de hecho Annab tiene los permisos necesarios para agregar documentos:
Ahora, vamos a eliminar Annab del grupo AD:
Annab todavía puede contribuir:
Pero después de 4 o 5 minutos (¿por qué no? 2 minutos, no lo sé todavía) que sólo puede leer, que es lo que yo esperaba.
Así que en resumen, siempre debe probar su SharePoint intranet / extranet configuración de seguridad mediante la definición de uno o varios usuarios de prueba virtuales que se pueden mover a diferentes grupos de AD, pero no se olvide de cambiar el LogonTokenCacheExpirationWindow y la WindowsTokenLifetime . Y ser paciente, como de costumbre.
En la producción de los valores por defecto debería estar bien.
Más enlaces:
- http://technet.microsoft.com/en-us/library/ff607549.aspx
- http://technet.microsoft.com/en-us/library/ff607642.aspx
- http://msdn.microsoft.com/en-us/library/hh446526.aspx
- http://blog.petercarson.ca/Pages/SharePoint-2010-Session-Management.aspx
- http://www.slideshare.net/technetbelux/265-room5-danholme
Comentarios