Artículo original publicado el domingo, 3 de junio de 2012

En ocasiones, es posible que desees o necesites cambiar la identidad de una cuenta en SharePoint.  El mejor ejemplo es con las notificaciones de SAML.  En prácticamente todos mis ejemplos uso la dirección de correo electrónico como notificación de identidad para los usuarios.  Hago esto porque a) la mayoría de la gente tiene una dirección de correo electrónico y b) una dirección de correo electrónico es algo que la mayoría de los usuarios comprenden.  Sin embargo, a veces recibo objeciones sobre el empleo de direcciones de correo electrónico porque los usuarios pueden cambiarla.  Como es lógico, si cambias tu dirección de correo electrónico, todos los permisos que tengas dejarán de funcionar.  Honestamente, no creo que este caso se dé muy frecuentemente o, de lo contrario, no usaría direcciones de correo electrónico.  Sin embargo, reconozco que a veces pasa, así que ¿qué puedes hacer cuando todo tu sistema de SharePoint está protegido con direcciones de correo electrónico?

La clave para controlar esto se puede encontrar en una entrada de blog que publiqué anteriormente en la interfaz de IMigrateUserCallback:  http://blogs.msdn.com/b/sharepoint_sp/archive/2011/03/08/migraci-243-n-de-cuentas-de-usuario-de-notificaciones-de-windows-a-notificaciones-de-saml.aspx. En esa entrada, describo cómo migrar identidades con esta interfaz e incluyo un ejemplo de cómo convertir una identidad de notificaciones de Windows en una identidad de notificaciones de SAML.  Lo que decidí hacer es escribir una pequeña aplicación de Windows que te permitirá introducir las credenciales que desees cambiar y hará la modificación por ti.  Esta aplicación pretender ser una sencilla herramienta de uso único para realizar estos cambios. No obstante, puedes tomar fácilmente el código fuente (que incluyo en esta entrada) y modificarlo para hacer algo más creativo, como leer una lista de usuarios de un archivo o base de datos y realizar las comparaciones personalmente.

Otra cosa que está bien de esta herramienta es que se puede usar en diversas situaciones.  No solo se puede usar para convertir una dirección de correo electrónico en otra, también se puede utilizar para convertir un nombre de grupo en otro.  Este es otro caso en el que algunos compañeros operativos me dicen que debería usar SID para los nombres de grupo (es decir, notificaciones de rol en SAML) ya que si se cambia el nombre del grupo, el SID no varía.  Esto es cierto, pero a) no ocurre muy a menudo, b) ¿quién tiene ganas de empezar a escribir nombres de SID de grupos y agregarlos a grupos de SharePoint? (busca terapia si tu respuesta es afirmativa) y c) los SID no valen de nada fuera de tu sitio de Active Directory local; si te pasas a un servicio basado en la nube, como Azure, Google, Yahoo, Facebook, etc. tu SID será tan inútil como [introduce aquí cualquier cosa inútil que se te ocurra].

La otra cosa buena de esta herramienta es que no te limita a hacer cambios en un solo tipo de proveedor.  ¿Quieres convertir un grupo de Windows en una notificación de rol de SAML?  Puedes hacerlo.  ¿Quieres convertir una notificación de identidad de SAML en un usuario de pertenencia FBA?  Puedes hacerlo.  ¿Quieres convertir un rol FBA en un grupo de AD?  Puedes hacerlo.  Esa es la idea. He probado prácticamente todas las combinaciones de “usuarios” y “grupos” distintos entre diferentes proveedores y, por el momento, todos se han convertido correctamente.

La propia herramienta es muy sencilla de usar. Aquí tienes una imagen de la misma:

Cuando se inicia la aplicación por primera vez, carga una lista de todas las aplicaciones web.  Para cada aplicación web, rellena los dos cuadros combinados situados bajo la aplicación con una lista de todos los proveedores que se utilizan en esa aplicación web.  Si tienes varios proveedores de SAML o FBA, aparecerán todos en la lista desplegable.  Solo tienes que elegir el proveedor desde el que migras y el proveedor al que migras.  En la sección Valor de la notificación, introduce el valor que desees migrar y a qué deseas migrarlo.  Simplemente escribe el valor en los campos de edición del valor de texto sin formato y haz clic en el botón de notificación de identidad (el de la izquierda) o en el botón de notificación de grupo (el de la derecha).  La descripción del texto ofrece una completa explicación de esto y el texto de los botones cambia para que resulte más significativo en función del proveedor de identidades que se utilice.

Por ejemplo, imagina que solo usas la autenticación SAML y deseas migrar la dirección de correo electrónico “steve@contoso.com” a “stevep@contoso.com”.  Tendrías que seleccionar tu aplicación web y el proveedor de autenticación SAML se seleccionaría de forma predeterminada en cada lista desplegable.  A continuación, en la sección Valores anteriores, escribirías “steve@contoso.com” en el campo de edición del valor del texto sin formato y haz clic en el botón Notificación de Id.; que rellena el campo de edición Valor codificado con el valor de notificación codificado correcto.  A continuación, escribirías “stevep@contoso.com” en el campo de edición del valor de texto sin formato Valores posteriores.  Haz clic en el botón Notificación de Id. de nuevo que volverá a rellenar el campo de edición Valor codificado con el valor correcto (NOTA: en la imagen siguiente, el botón de la sección Valores posteriores se llama “Usuario” en lugar de “Notificación de Id.” porque en ese ejemplo se migra de notificaciones de SAML a notificaciones de Windows).  Una vez proporcionados todos los valores, solo tienes que hacer clic en el botón Migrar para completar el proceso. A continuación, se mostrará un cuadro de mensaje indicando que la migración se ha completado.

Al probar esto con diferentes aplicaciones web y tipos de autenticación, me encontré con un par de problemas que quiero exponer aquí por si también te han aparecido a ti.  En un caso, me apareció un mensaje de error de Acceso denegado al intentar migrar los usuarios de una aplicación web determinada.  Nunca pude rastrear el origen de este problema, por lo que lo único que puedo decir es que algo no está del todo bien en esa aplicación web, pero no estoy seguro de qué puesto que en las otras cuatro o cinco aplicaciones web que he probado en mi granja de servidores todo funcionaba correctamente.

El segundo problema es que, en un caso, recibí el mensaje de que la migración se había completado correctamente pero no pude iniciar sesión como el usuario migrado.  Al profundizar un poco, descubrí que no se estaba aplicando la función IMigrateUserCallback a la cuenta desde la que estaba migrando (es decir, es un problema de SharePoint, no de codificación con esta aplicación).  Si te ocurre eso, te recomiendo que uses el código fuente y Visual Studio para realizar todos los pasos del depurador a fin de garantizar que se llama a la cuenta desde la que migras.  Desafortunadamente, se me quedó atascado un solitario usuario de pertenencia FBA.

Una última cosa que tener en cuenta: no te asustes si migras una cuenta de un valor a otro, inicias sesión como el nuevo usuario y ves el nombre de cuenta antiguo, etc. en el control de bienvenida de la esquina superior derecha de la página.  La función de migración solo cambia el nombre de la cuenta.  Si se produce algún cambio en el resto de información del usuario, siempre que actualices los perfiles de usuario, se mostrará la información correcta en todas las colecciones de sitios tras la siguiente sincronización con el sistema de perfiles.

Eso es todo, espero que te sirva de ayuda.  Como dije anteriormente, incluyo el código fuente completo, así que no dudes en modificarlo todo lo necesario para ajustarlo a tu situación concreta.

Esta entrada de blog es una traducción. Puedes consultar el artículo original en The SPMigrateUsers Tool for Changing Account Identities in SharePoint 2010