Microsoft ha anunciado que planea deprecar las vías de sincronización de identidad con Yammer. De esta forma, con la adopción de Office 365, las integraciones realizadas con anterioridad serán ahora más sencillas y más «streamlined».
El hecho de que Yammer se integre aún más con Office 365 es una gran noticia, pero como responsables de estrategia corporativa de IT, o como administradores de los sistemas en nube, también nos plantea dudas sobre qué camino será el adecuado. ¿Dejamos nuestras antiguas implementaciones o evolucionamos siguiendo las directrices?. No le des más vueltas. Ha llegado el momento de salir de dudas 🙂
Yammer Single Sign-On (SSO) y la Sincronización de Directorio (DSync), desarrolladas de forma previa a la adquisición por parte de Microsoft, van a ser deprecadas para que los usuarios utilicen las herramientas habituales de Office 365. Es decir, el Single Sign-On con Identidad Federada y la Sincronización de Directorio con Azure Active Directory Connect (AadConnect, o ADConnect). Con este paso se gana independencia (al no necesitar el equipo de producto para implementar la solución), pero estas herramientas dejarán de funcionar de forma definitiva el 1 de Diciembre de 2016.
Si quieres algunos consejos a tener en cuenta, toma nota. Estos son los escenarios de sustitución por cada herramienta:
SSO Yammer
En los casos en los que se esté utilizando SSO Yammer , estos son los caminos adecuados, según nuestra infraestructura:
| Escenario YSSO | Sustitución |
|---|---|
| Login: todos los usuarios de la red son redirigidos al login con Federación (AD FS). Los usuarios sin ADFS no pueden logarse | Es necesario usar la configuración de Forzar Identidad O365 para hacer que solo los usuarios de O365 o logins de Azure Active Directory puedan acceder a Yammer, y después configurar la identidad federada de Office 365. Referencia |
| Login: los permalinks y links profundos llevan al usuario a autenticar con el ADFS | Configurar la red para Forzar Identidad 365 |
| Login: Usuarios sin correo | Los usuarios sin correo pueden logarse usando las credenciales O365, con el User Principal Name (UPN) en lugar del nombre de cuenta |
| Registro: Los usuarios que traten de registrarse en la red de Yammer serán redirigidos | Configurar la red para Forzar Identidad 365 para replicar este comportamiento |
| Bloqueo de Usuarios: Las reglas configuradas en el ADFS para restringir a ciertos usuarios el acceso a Yammer usando el SSO | Restricción de acceso de usuarios: Yammer permite el licenciado por usuario a nivel de Azure Active Directory, usando los mismos mecanismos de licenciado que son usados para otros servicios de O365. Como administrador de O365, es posible desmarcar el check de licenciamiento de Yammer para cualquier usuario y controlar de esta manera el acceso al servicio. Ver en detalle en Gestionar las licencias de Yammer en O365 |
| Redes no conectadas a tenants de O365: Las redes pueden estar o no conectadas a tenants de O365, pero el YSSO funciona también en tenants no conectados | Es necesario activar la red de Yammer a través de Office 365. a partir del día 1 de Diciembre de 2016 las redes no asociadas con O365 solo soportarán la identidad Yammer Legacy (correo y contraseña) |
Yammer DSync
Para los casos en los que se esté utilizando Yammer DSync y su funcionalidad, en la siguiente tabla encontramos la evolución para conservar la funcionalidad en el nuevo escenario.
| Escenario DSync | Sustitución |
|---|---|
| Provisionado: Los usuarios son creados de forma masiva con la herramienta Yammer DSync. A continuación, cada usuario puede registrarse a los servicios en un proceso | Los usuarios son creados en O365 con la herramienta Azure Active Directory Connect. A continuación, los usuarios pueden acceder a yammer sin un proceso adicional de registro |
| Mapeado: Los usuarios son mapeados al Active Directory a través de su correo electrónico, pero solo si se ha sincronizado el email primary con Yammer | Los usuarios son mapeados a un usuario de O365 usando su correo primario, las direcciones proxy y el user principal name (UPN), en este orden |
| Sincronización de propiedades: Los cambios de propiedades de usuarios son sincronizados desde el Directorio Activo local (OnPrem) usando la herramienta DSync. El mapeado de campos es configurable | Los cambios de propiedades de usuario en el directorio local son replicadas en el AAD por medio de ADConnect. El mapeo de propiedades y campos es configurable -más información aquí: Cambios de reglas de Sincronización – Todas las propiedades clave de los usuarios AAD serán sincronizadas con Yammer |
| Ciclo de Vida del Usuario: Los usuarios son suspendidos en Yammer cuando son suspendidos o borrados del Directorio local | La capacidad de manejar usuarios de Yammer en su ciclo de vida desde Office 365 está ya disponible |
| Notificaciones: Los administradores tienen la posibilidad de crear un mensaje que sea enviado a los usuarios la primera vez que estén en Yammer | Esta funcionalidad no está soportada |
| Informes: Un administrador puede visitar la sección de administración para obtener un informe de los usuarios e la red que no fueron creados originalmente via DSync | Esta funcionalidad no será soportada, y no es necesaria debido a que la integración de O365 y el Azure Active Directory incluye tanto el login como la sincronización, lo cual asegura que una red marcada como Forzar Identidad O365 solo permitira el acceso de los usuarios en el directorio de O365, y con licencias Yammer asignadas |
| Redes no conectadas a O365: Yammer DSync funciona en redes no conectadas a Office 365 | Las redes no conectadas a O365 no tendrán soporte para la sincronización de Directorio |
Proceso de Migración
El proceso general para hacer la migración de forma adecuada, es el siguiente:
Personalmente, añadiría un sexto paso… ¡no dejes de avisarnos!, en ENCAMINA siempre estamos encantados de acompañaros en cualquier nuevo reto que se os plantee y ¡¡¡ayudaros a pensar en colores!!!!
¡Suscríbete a nuestras RRSS!
