Archivo de la etiqueta: azure ad

Proceso de sincronización. Resolviendo InvalidSoftMatch en ADConnect

El objetivo que me he planteado para este artículo, es explicar a alto nivel el proceso de sincronización, y, una vez establecido el contexto, ver algunos de los errores que podríamos tener, en concreto el tipificado como InvalidSoftMatch. Pero antes de entrar en materia, me gustaría poner un poco de contexto.

¿Qué es ADConnect?

ADConnect es un elemento fundamental en implementaciones de identidad sincronizada o federada con Azure AD (AAD). Nos sirve para poder emplear las credenciales de nuestro directorio local, en servicios proporcionados por Azure AD, y, así, tener una mayor experiencia de integración.

En el core de las aplicaciones que instala, se encuentra el servicio de sincronización. Sin entrar en mucho detalle, esta herramienta, mediante el empleo de ciclos de sincronización regulares, divididos en distintas etapas (Import, Sync y Export), va a realizar una “comparativa” de los elementos que hay en local, con los de Azure, y, realizará las acciones necesarias: creación, actualización, eliminación. Esta “comparativa” la hace empleando los parámetros configurados durante la instalación de ADConnect.

¿Cómo funciona la sincronización?

El proceso de sincronización, permite  establecer una correspondencia entre los elementos que existen en local y los de Azure.  Son necesarios 2 atributos del directorio local para ello :  un atributo para el inicio de sesión, y otro, para identificarlo de forma única o ImmutableId (que permanecerá inalterable a lo largo de la vida del objeto). Los valores empleados  por defecto (aunque no los únicos), son respectivamente el UserPrincipalName y el ObjectGuid.

Durante la sincronización, los objetos son importados , convertidos a un formato  apropiado, y por último provisionados o actualizados en el destino (si hubiera modificaciones).  El objectGUID del usuario de origen es convertido a base 64 y pasará a ser el atributo ImmutableId en AzureAD.

Errores de sincronización

Si bien, en un entorno perfectamente controlado los errores de sincronización no suelen ser frecuentes, puede darse situaciones, en las que nuestro ADConnect reporte algún error al realizar alguna exportación.  Éstos podrán visualizarse en la pantalla de operaciones del administrador de sincronización, y para poder analizarlos y solventarlos, tendremos que acceder a cada uno de ellos.

Entre los errores que podemos encontrar figuran: ObjectTypeMismatch, AttributeMustBeUnique, InvalidSoftMach entre otros. Nos centraremos en el error InvalidSoftMatch.

Error InvalidSoftMatch

Este error aparece porque hay una incoherencia en el atributo ImmutableId. Si un usuario está correctamente sincronizado su UserPrincipalName y su inmutableId (en AD y AAD) deben ser el mismo. En este caso, el UserprincipalName coincide, pero no el ImmutableId, y,  por tanto, no se puede realizar una correspondencia con ese usuario. Este error puede producirse cuando un objecto de ADD ya está sincronizado, y, en el directorio de origen se elimina ese objeto y se crea otro con las mismas propiedades.  Al crear un nuevo objecto, se generará un nuevo GUID, que no coincidirá con el de AAD.

Para poder solucionar este error, debemos hacer un “Hard Match” o macheo manual, que consiste en cambiar el ImmutableId del  usuario de AAD, por el correcto del directorio local.  Previamente nos tenemos que conectar a O365 con usuario administrador global del tenant.

Como último comentario, indicar,  que si nuestro dominio está federado, necesitaremos previamente cambiar el UPN por el de un dominio no federado para machearlo, y a continuación establecer el upn correcto.

¡Hasta el próximo post! 🙂

 

Azure AD Privileged Identity Management

Dentro de la suite de seguridad que nos proporciona Azure EMS, encontramos la solución ante una de las dudas que muchos usuarios y administradores del servicio han tenido.

¿Cómo concederíamos acceso administrador o de servicio a nuestro tenant de Office 365 o Azure Active Directory durante un tiempo limitado o mediante revisiones teniendo un registro de auditoría de todo el proceso?

La solución a ese problema se denomina: Azure AD Privileged Identity Management.

En primer lugar, para realizar un deployment de la aplicación en nuestro servicio de Azure AD, son necesarios los siguientes requisitos:

  • Acceso administrador global.
  • Licencia Azure Active Directory Premium Plan 2, la cual podemos activarla de forma independiente o a través del paquete de Azure EMS E5.

Caso de uso

Procedemos a su búsqueda en el portal de Azure y activación. Al realizar el primer acceso, automáticamente aparecerá el Security Wizard, el cual nos guiará para activar los administradores de PIM (Privileged Identity Management), revisar el acceso permanente para los administradores de los diferentes servicios como actualmente o cambiarlos a elegibles, en caso de optar por ésta segunda opción, su administración se realizará a través de diferentes peticiones y con un tiempo limitado.

Una vez que tenemos todo configurado, veremos lo siguiente en nuestro portal:

Vamos a explicar cada uno de las opciones por pasos:

  • Activate my roles: En caso de ser un administrador elegible, podremos activar los roles de administrador al servicio que nos hayan proporcionado indicando la razón de esta necesidad y por defecto, es obligatorio hacer uso de MFA para que los roles puedan ser activados.

Una vez activado, podremos observar la fecha de espiración del rol asignado:

  • Managed privileged roles: Desde esta sección podremos ver un resumen de los diferentes roles de administración que tenemos asignados en nuestro directorio, así como alertas en caso de que los valores en las políticas que hayamos definido se hayan superado, un resumen de auditoría y las diferentes opciones presentes para modificar las políticas que debe de cumplir cada rol.

Desde el historial de auditoría podremos ver el número de activaciones de roles que se ha producido durante el día, así como diferenciar por colores los diferentes roles que tenemos activos en nuestro directorio, pudiendo exportar en todo momento esta auditoría a un fichero .csv para analizar los datos mejor en nuestro cliente preferido:

Desde el apartado de configuración, podremos modificar las políticas de acceso a un determinado rol, en este caso seleccionaremos el de administrador global desde el cual podremos indicar el número de horas que vamos a permitir de acceso (mínimo 30 mins.), enviar emails de las activaciones que se producen por los administradores elegibles a los administradores actuales del directorio, requerir un número de ticket para el usuario que quiere escalar sus privilegios en el directorio y por último y de manera obligatoria, requerir MFA.

En las configuraciones de alertas podremos definir por ejemplo, el trigger con el cual queremos que nos alerte de que nuestro directorio cuenta con > X administradores, etc.

Por último, en las configuraciones de revisiones de acceso podremos definir, notificaciones de emails, recordatorios, requerir una razón para aprobar o denegar el acceso y la duración en días que una revisión de acceso estará disponible.

  • Review privileged access: Desde este último punto, podremos revisar los roles que tenemos pendientes de los usuarios elegibles en caso de que así lo hayamos configurado previamente, podremos seleccionar quién o quiénes serán los revisores y deberemos de aprobar o denegar el acceso de esos administradores elegibles con una razón, por defecto nos enviará emails recordatorios y hemos marcando un tiempo máximo de 30 días.

Conclusiones

Viendo la versatilidad del producto, es importante tenerlo en cuenta para aumentar la seguridad en nuestro directorio activo de Azure, alertarnos de diferentes aspectos de administración e incluso establecer políticas de revisiones de acceso para escalar un rol determinado en nuestro entorno.

Esperemos que os haya gustado el ejemplo de uso en un entorno real.