Última hora: Keyfactor adquiere InfoSec Global y CipherInsights | Soluciones integrales para descubrimiento, control y agilidad

  • Inicio
  • Blog
  • FIM Sync: Cómo rastrear el historial de atributos ProxyAddresses

FIM Sync: Cómo rastrear el historial de atributos ProxyAddresses

Recientemente, uno de nuestros clientes tenía una situación que les exigía realizar un seguimiento del historial de atributos proxyAddresses entre dos dominios de Microsoft Active Directory (AD). Dado que FIM Sync Service no conserva ningún historial de valores de atributos (ya que es simplemente un motor de sincronización basado en estados), esto requería un poco de reflexión y planificación.

Examinando la necesidad de llevar un registro del historial y explorando opciones, llegamos a la solución mediante un sencillo mecanismo de historial de una sola revisión con FIM Sync.

Sin entrar en demasiada historia, empecemos con un breve resumen del escenario. Hay dos dominios de Active Directory (AD) (llamémoslos DomA y DomB) y los usuarios se están sincronizando de DomA a DomB. La situación se complica un poco porque cada dominio tiene su propio entorno de Exchange y cada uno añade valores únicos al atributo proxyAddresses de los objetos de usuario habilitados para correo electrónico. Con esta configuración, el motor de sincronización sobrescribiría normalmente los valores del atributo proxyAddresses en DomB, eliminando en esencia cualquier valor añadido por el entorno Exchange de DomB (véase la Figura 1).

Entorno de sincronización existente

Así que, en este caso, necesitamos una forma de añadir valores desde DomA sin sobrescribir los valores añadidos por DomB. Para conseguirlo, necesitábamos almacenar los últimos valores de DomA en algún lugar. Introduciéndolos en una base de datos SQL, pudimos devolverlos al metaverso como un atributo diferente. Esta era una buena solución porque necesitaríamos hacer referencia a ellos durante el proceso de sincronización, y el agente de gestión SQL (MA) integrado de FIM nos permitiría escribir y recuperar fácilmente los valores en y desde la base de datos SQL (véase la figura 2).

Añadir una base de datos SQL para guardar el historial de proxyAddresses

Con los valores de DomA en la base de datos, podríamos referirnos a ellos si los valores de DomA cambiasen. Los cambios fluirían desde DomA, aplicaríamos la lógica que necesitáramos en la sincronización de salida a DomB haciendo referencia a los nuevos valores de DomA y a los valores anteriores de DomA (ahora almacenados tanto en la base de datos SQL como en un nuevo atributo en el metaverso). Esto nos daría un historial de una revisión, que es todo lo que necesitábamos.

Para configurarlo, necesitamos añadir los siguientes elementos a nuestra infraestructura FIM Sync:

  • Dos nuevas tablas para guardar los valores de proxyAddresses (si fuera un atributo de valor único, sólo necesitaríamos una tabla, pero como es multivalor necesitamos dos: una para guardar el registro y otra para guardar los multivalores del registro).
  • Un nuevo atributo en el metaverso FIM para contener el historial de una revisión de los valores proxyAddresses de DomA (lo llamaremos proxyAddressHistory) .
  • Una nueva MA SQL para interactuar con la(s) nueva(s) tabla(s).
  • Un nuevo bit de lógica de aprovisionamiento para crear las nuevas entradas en la tabla SQL.
  • Nueva lógica de exportación en la MA DomB para el atributo proxyAddresses
Creación de las tablas SQL

Para nuestra configuración, utilizamos la misma instancia SQL que existía para el servicio de sincronización FIM. Habíamos creado previamente otra base de datos (llamada FIMExtension), así que añadimos allí las nuevas tablas para el historial de proxyAddresses.

Para la tabla principal (llamémosla ProxyTracking), en realidad sólo necesitas una columna que contenga la clave primaria. Me gusta un poco más de información, sin embargo, para tener una idea de lo que estoy viendo en la base de datos si alguna vez veo los datos desde allí. Puedes hacer esto más (o menos) complejo, pero para los propósitos de esta entrada de blog sólo crearemos la tabla para mantener una clave primaria (P_ID) y un employeeID.

Crear tabla ProxyTracking
(
P_ID int PRIMARY KEY IDENTITY,
employeeID (15) NOT NULL,
);Ahora, necesitaremos otra tabla para realizar un seguimiento de los valores almacenados en el atributo multivaluado proxyAddresses. Llamémosla ProxyTrackingRef. Para esta tabla, necesitamos una columna que haga referencia a la clave principal de la tabla ProxyTracking (P_ID), una columna que contenga el nombre del atributo que estamos rastreando (en nuestro caso siempre será proxyAddresses) y una columna que contenga los valores de proxyAddresses.
Crear tabla ProxyTrackingRef
(
P_ID int NOT NULL
attributeName varchar(20) NOT NULL,
attributeValue varchar(100) NOT NULL
);
Creación del nuevo atributo metaverso

Ahora tenemos que crear el nuevo atributo en el metaverso FIM para guardar el historial de una revisión. Desde FIM Sync Metaverse Designer, añada un nuevo atributo a persona llamado "proxyAddressHistory". Que sea una cadena multivaluada, no indexable (véase la figura 3).

Crear nuevo atributo metaverso

Creación de la nueva MA SQL

A continuación, necesitamos una MA para leer y escribir en las tablas SQL que acabamos de crear. En la pestaña Agentes de gestión de sincronización de FIM, cree una nueva MA de SQL Server llamada "MA de historial de proxy". Especifica la instancia de servidor SQL que contiene nuestra base de datos y las nuevas tablas. Escriba "ProxyTracking" para la tabla/vista y "ProxyTrackingRef" para la opción de tabla multivalor (véase la figura 4 a continuación).

Crear la MA SQL

Figura 4 - Crear la MA SQL

En la sección "Configurar columnas", asegúrese de que la columna P_ID está configurada como Ancla. Haga clic en el botón Multivalor y seleccione "attributeName" del menú desplegable para el "nombre de columna de atributo", haga clic en "Columna de atributo de cadena" y seleccione "attributeValue" del menú desplegable, y haga clic en el botón Nuevo y añada "ProxyAddresses" como nuevo atributo multivalor como Tipo "Cadena" (véase la Figura 5 a continuación).

Configuración multivalor de SQL MA

No es necesario preocuparse por los filtros de conectores ni por las reglas de unión y proyección.

En la sección "Configure Attribute Flow" (Configurar flujo de atributos), configure un flujo de exportación directa desde el atributo proxyAddressCollection de Metaverse (aquí es donde almacenamos los valores de DomA) al atributo ProxyAddresses de SQL MA, y un flujo de importación directa desde el atributo ProxyAddresses de SQL MA al atributo proxyAddressHistory de Metaverse (que creamos previamente) (véase la Figura 6 a continuación).

Flujo de atributos de SQL MA

En la sección "Configurar el desaprovisionamiento" realice un borrado en el objeto para la siguiente ejecución de exportación, y asegúrese de que en las secciones "Configurar extensiones" aparece un nombre de extensión Rules (Proxy History MAExtension.dll).

Crear lógica de aprovisionamiento para la MA de historial de proxy

Ahora necesitamos crear la lógica de aprovisionamiento en la MVExtension.dll (si aún no ha habilitado la Extensión de Reglas de Aprovisionamiento, necesitará hacerlo desde el menú Herramientas, Opciones). Primero, cree una subrutina llamada "ProvisionToProxyHist" (como abajo).

Sub ProvisionToProxyHist(ByVal mventry As MVEntry)

'---------------

'- Subrutina para aprovisionar a la tabla SQL que contiene el historial de proxy

'---------------

Pruebe

Dim PHistMA As ConnectedMA = mventry.ConnectedMAs("Proxy History MA")

If PHistMA.Connectors.Count <> 0 Then Exit Sub

Dim obCS As CSEntry

obCS = PHistMA.Conectores.IniciarNuevoConector("persona")

Dim DN As ReferenceValue

DN = PHistMA.EscapeDNComponent(System.Guid.NewGuid().ToString)

obCS.DN = DN

obCS.CommitNuevoConector()

Catch ex Como Excepción

Lanzar ex

Fin del intento

Fin Sub

Entonces, todo lo que tenemos que hacer es llamar a esa subrutina desde dentro de la subrutina Provision() del MVExtension.dll (como abajo).

A ProxyHistory MA
ProvisionToProxyHist(mventry)

Con esto en su lugar, y los flujos de atributos que especificamos en el MA de arriba, la información del historial del proxy será enviada a las tablas SQL.

Configurar la lógica de exportación para DomB

Para utilizar el nuevo historial al exportar al dominio DomB, tenemos que hacer dos cosas. En primer lugar, tenemos que modificar el flujo Exportar del Metaverso a DomB y cambiarlo de un flujo directo a un flujo avanzado (extensión de reglas) tanto con la función proxyAddressCollection y proxyAddressHistory seleccionados como atributos Metaverse para DomB proxyAddresses (he especificado el nombre de regla de flujo "proxyAddressCollection_proxyAddressHistory_to_proxyAddresses").

A continuación, tenemos que añadir el nombre de la regla de flujo a nuestra sentencia Case en la subrutina MapAttributesForExport() de DomB MAExtension.dll como se indica a continuación.

Caso "proxyAddressCollection_proxyAddressHistory_to_proxyAddresses"

'Añadir cualquier entrada smtp del

'MV proxyAddressCollection sin sobrescribir las entradas de destino

Si no hay proxyAddressCollection en la VM, no es necesario continuar.

If Not mventry("proxyAddressCollection").IsPresent Then Exit Sub

Dim aOrigCSProxyAddresses() As String = {}

Dim sp1(), sp2() As String

Dim bExists As Boolean

'Coge los valores del espacio del conector DomB para que podamos volver a añadir valores únicos

If csentry("proxyAddresses").IsPresent Then

aOrigCSProxyAddresses = csentry("proxyAddresses").Values.ToStringArray

csentry("proxyAddresses").Values.Clear()

Fin If

'... La lógica para añadir especificar/añadir dirección primaria (SMTP) debe ir aquí

'... - ...

'... - ...

'A continuación, añada direcciones smtp del metaverso al atributo de salida

For Each pAddr As String In mventry("proxyAddressCollection").Values.ToStringArray

If pAddr.StartsWith("smtp:") Then

Añadir smtp(s) que no existan en la lista

bExiste = Falso

bucle a través de cada entrada en el proxyAddresses

For Each csPAddr As String In csentry("proxyAddresses").Values.ToStringArray

'divide los dos valores que estamos comparando en los dos puntos (:)

sp1 = Split(csPAddr, ":")

sp2 = Split(pAddr, ":")

If sp1(1).ToLower = sp2(1).ToLower Then

'los valores de las direcciones coinciden

'establece la bandera en true

bExiste = Verdadero

'no es necesario continuar a través de la lista, salir del bucle

Salida para

Fin If

Siguiente

'si no se encontró ninguna coincidencia, siga adelante y añada el valor a la lista

If Not bExists Then csentry("proxyAddresses").Values.Add(pAddr)

Fin If

Siguiente

'Ahora reemplaza cualquier entrada del CS que no esté en el MV de DomA

If aOrigCSProxyAddresses.Length > 0 Then

For l As Integer = 0 To aOrigCSProxyAddresses.Length - 1

'En primer lugar, compruebe que no se trata de una dirección primaria (SMTP)

If Not aOrigCSProxyAddresses(l).StartsWith("SMTP:") Then

A continuación, comprobamos si está en la lista del historial.

no es necesario volver a añadirlo porque se originó a partir de DomA

If Not mventry("proxyAddressHistory").Values.Contains(aOrigCSProxyAddresses(l)) Then

'A continuación, comprueba si ya está en la lista de salidas

If Not csentry("proxyAddresses").Values.Contains(aOrigCSProxyAddresses(l)) Then

'poner la bandera en false

bExiste = Falso

bucle a través de cada entrada en el outbound proxyAddresses utilizando insensibilidad a mayúsculas y minúsculas

For Each csPAddr As String In csentry("proxyAddresses").Values.ToStringArray

'dividir los dos valores que estamos comparando en los dos puntos

sp1 = Split(csPAddr, ":")

sp2 = Split(aOrigCSProxyAddresses(l), ":")

If sp1(1).ToLower = sp2(1).ToLower Then

'los valores de dirección coinciden -poner la bandera a true

bExiste = Verdadero

'no es necesario continuar. Salir del bucle

Salida para

Fin If

Siguiente

'si no se encontró ninguna coincidencia, sigue adelante y vuelve a añadir el valor

a la lista

If Not bExists Then csentry("proxyAddresses").Values.Add(aOrigCSProxyAddresses(l))

Fin If

Fin If

Fin If

Siguiente

Fin If

Secuencia de ejecución MA

La última cosa que necesitamos tratar es la secuencia de ejecución de MA. Obviamente, no queremos actualizar las tablas SQL antes de exportar a DomB o estaríamos sobreescribiendo el historial de ProxyAddresses con nuevos valores de DomA - por lo tanto perdiendo el historial. Así que asegúrese de Importar y Sincronizar desde DomA, Exportar a DomB (seguido de una Importación Delta), luego Exportar a la MA del Historial de Proxy, y finalmente Importar y Sincronizar la MA del Historial de Proxy para obtener los valores del historial de nuevo en el Metaverso. Una cosa a tener en cuenta aquí es que sólo obtuve resultados fiables de la MA Proxy Historia cuando corrí una sincronización completa después de la importación.

(ignorar)

La necesidad de realizar un seguimiento del historial de atributos no debe ser muy común, y complicamos este caso con el hecho de que el atributo era multivaluado, pero esperemos que el ejemplo ayude a cualquiera que se encuentre en una situación similar.