MSIS7055: Not all SAML session participants logged out properly

Estuve trabajando con algunas aplicaciones SharePoint 2010, todas hosteadas en un mismo farm, pero en diferentes web applications.

Ambas aplicaciones están configuradas para usar ADFS como trusted issuer. Hay dos ADFS atendiendo los requests, y un proxy delante de ellos.

Cuando me autentico en una aplicación y luego, en otra instancia del navegador, abro otra aplicación, gracias al Single Sign-On en la segunda aplicación  no me pide credenciales.

Ahora cuando cierro una de las aplicaciones, mientras la otra está abierta en otro navegador, haciendo click en logout,  ADFS me muestra el siguiente error.

ADFS Error

Mirando el event viewer del proxy de ADFS, descubrí que la exception que generaba era:

Encountered error during federation passive sign-out. 
MSIS7055: Not all SAML session participants logged out properly

Si bien ADFS intenta deslogearse y borrar todas las cookies, no puede, porque hay otro navegador que esta usando la cookie.

Para arreglar este problema simplemente tenemos que ir a la carpeta de IIS de ADFS (En general se encuentra en C:\inetpub\wwwroot\adfs\ls) y editar el archivo error.aspx.cs. Al final de la función Page_Load agregamos la siguiente linea:

if (Exception.Message == "MSIS7055: Not all SAML session participants logged out properly. It is recommended to close your browser.")
{
Response.Redirect(System.Web.Configuration.WebConfigurationManager.AppSettings["signoutredirect"]);
}

view raw
SingleLogout-ADFS2.0
hosted with ❤ by GitHub

 

 

[Fix] SharePoint 2010 – Estilos en el calendario

 

Hace un tiempo, en el trabajo, tuvimos que hacer una presentación de una aplicación a nuestros clientes, no solo a ellos sino a gente que iba a usar la aplicación, a mi jefe y muchos más.

Como siempre el tiempo antes de la Demo se aprovecha para poner a punto todo y revisar que nada esté fallando, y tambien en ese tiempo es donde se encuentra siempre algun bug.

Mientras cargabamos un campo de fecha, al desplegar el calendario nos dimos cuenta que no tenia estilos, se veía como este:

calendar

Lo primero que hicimos fue ver cual era el archivo de estilos del calendario:

.../styles/Themable/datepickerv4.css

Como esto estaba bien, decidimos buscar alguna diferencia entre un calendario que andaba y este que no andaba.

Teniamos acceso a una de nuestrar maquinas donde el calendario andaba bien y pudimos comparar la forma de la url del iFrame.

Lo que descubrimos fue que:

En el iFrame de los calendarios que el estilo estaba bien la URL era:

https://server/subsitio/_layouts/iframe.aspx?...

En el iFrame de los calendarion que el estilo no estaba bien la URL era:

https://server/_layouts/iframe.aspx?...

La diferencia esta en la URL, que el segundo calendario le falta el sub-site, ya que el calendario estaba funcionando en el mismo nivel que el calendario que andaba.

Probamos de modificar como se estaba llamando el iFrame agregandole el sub-sitio a la URL y los estilos comenzaron a andar bien.

Luego buscando en MSDN descubrimos que el DatePicker tiene una propiedad DatePickerFrameURL.

Esta propiedad nos permite especificar la URL del iFrame, por lo que, fuimos a nuestro control de Date Picker y agregamos la siguiente linea:

MyDatePicker.DatePickerFrameUrl = SPContext.Current.Web.ServerRelativeUrl + "/_layouts/iframe.aspx";

Con esta linea lo que hicimos fue decirle al DatePicker, que cada vez que se utilize saque su url del contexto en el que está.

Esta solución arregló nuestro problema en el sistema y tuvimos una feliz Demo.

Nos leemos!

Más información: El blog de Brian Farnhill 

 

Deshabilitar Loopback Check usando Powershell

Cuando queremos acceder a un sitio SharePoint 2010 utilizando el FQDN o  el alias CNAME desde el mismo servidor donde tenemos instalado SharePoint nos puede dar un error de Access Denied.

Esto se debe al Loopback Security Check, que está configurado por defecto a partir de Windows Server 2003 SP1. Para arreglar esto necesitamos agregar una clave al registro y luego reiniciar.

Lo podemos hacer de dos formas:

  1. Ir al registro y modificarlo artesanalmente siguiendo los pasos que están explicados en el sitio de soporte de Microsoft.
  2. Usando Powershell. Abrimos una consola de Powershell como administrador y ejecutamos:
New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -Value "1" -PropertyType dword

Luego de cualquiera de las dos soluciones, solo queda reiniciar la maquina.

Fuente: SharePoint Adam

 

Timer Job – Multiples Ejecuciones

Durante el proyecto que estamos llevando a cabo en la empresa para la que trabajo, tuvimos que hacer un Timer Job. La funcionalidad que este tiene es el de mandar un Newsletter a las personas que se suscribieron a ciertos sitios. Basicamente el Timer Job recorre todos los sitios creados en una web application, busca los usuarios subscriptos y manda las noticias. Después de terminar el desarrollo, lleve el timer job para deployarlo en una maquina que utilizamos como integración.

Cuando lo instalo y pruebo andaba, pero me mandaba muchísimos mails de más. Cuando voy a mirar el  history log aparecía como que se ejecutaba múltiples veces.

Me puse a investigar y leyendo un poco descubrí que en la creación del Timer Job, hay un parámetro que se llama SPJobLockType.

Este parametro puede estar entre los siguientes valores:

SPJobLockType.None: El Timer Job se ejecuta en todas las maquinas del farm donde el servicio se instaló. A no se que lo asocie para ejecutarse en un server especifico, en cuyo caso ejecuta solo en ese.

SPJobLockType.ContentDatabase – Se ejecuta una vez por cada content database asociada a la web application.

SPJobLockType.Job – Se ejecuta solo en una maquina del farm.

Como yo necesitaba que se ejecute solo un vez en todo el farm, utilicé SPJobLockType.Job y problema resuelto.

Espero les sirva para el desarrollo de sus Timer Jobs.

Nos leemos…

 

[SharePoint 2010] Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’

El otro día haciendo un deployment a un servidor SharePoint 2010, me encontré con un error poco común “Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON‘”. Este error aparecía en una webpart que habíamos desarrollado. Esto como siempre tiene dos partes, una mala y una buena. La mala es que perdí casi todo el día entendiendo que era lo que pasaba; la buena es que uno aprende bastante leyendo y entendiendo que es lo que pasa internamente en SharePoint 2010.

El Escenario

Tenemos una webpart que se conecta con una base de datos SQL Server 2008. La webpart hace consultas a la base y  también inserta un valor en una tabla.

Lo que  suponíamos es que la webpart impersonaría con el usuario que esta logueado SharePoint en ese momento.

Probandolo en nuestro ambiente de desarrollo todo funcionaba muy bien, le habíamos dado permiso de escritura y lectura en la base de datos al usuario Site Collection Administrator y siempre que probabamos con ese usuario andaba bien, el bien conocido “Works on my Machine“.

Cuando llevamos la solución a otro ambiente, dejó de andar y en los logs encontramos el error “Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON‘”

Tratando de entender un poco mas que pasaba llegamos a  entender que:

Teníamos un problema de “double hop“, es decir, si desarrollas una webpart en SharePoint que se comunica con una base de datos en otro server, el cual tiene permisos con las mismas credenciales del usuario que se encuentra logueado, Windows no puede pasarle las credenciales si se esta usando autenticacion NTLM.

La Solución

La técnica que utilizamos para resolver este problema fue, en la creación de la conexión a la base de datos utilizamos un bloque RunWithElevatedPerivileges. El código en este bloque corre con las credenciales del usuario del application pool. Esto elimina el error de “Double Hop“, pero aun se necesita agregar el usuario que corre el application pool de tu aplicación SharePoint a la base de datos, para que pueda leer y escribir.