Detalles de Conexión de Active Directory¶

Introducción¶

Versión del conector

Esta documentación se basa en la versión 21.0.8257 del conector.

Empezando¶

Compatibilidad con la versión de Active Directory

El conector proporciona acceso basado en SQL a Active Directory a través del protocolo LDAP. El conector es un cliente LDAP estándar que admite LDAP v2 y v3.

Establecer una Conexión¶

Autenticación en Active Directory¶

Para autenticar solicitudes, establezca User y Password propiedades para credenciales válidas de Active Directory (por ejemplo, establecer User a "Dominio\BobF" o "cn=Bob F,ou=Empleados,dc=Dominio").

El conector utiliza la autenticación de texto sin formato de forma predeterminada, ya que el conector intenta negociar TLS/SSL con el servidor. Puede especificar otro método de autenticación con AuthMechanism.

Ver Configuración SSL para obtener más información sobre la configuración de TLS/SSL.

Conexión a Active Directory¶

Colocar Server y Port para conectividad básica. Además, puede ajustar la conexión con lo siguiente:

• FollowReferrals: cuando se configura, el conector muestra los datos como vistas solo de servidores de referencia. Para modificar datos en un servidor de referencia, debe especificar este servidor con Server y Port.
• LDAPVersion: establezca esto en la versión del protocolo que implementa su servidor; de forma predeterminada, el conector utiliza la versión 2.

Ajuste Fino del Acceso a Datos¶

Las siguientes propiedades controlan el alcance de los datos devueltos:

• BaseDN limitará el alcance de las búsquedas LDAP a la altura del nombre distinguido proporcionado. Nota: Especificar un estrecho BaseDN puede aumentar considerablemente el rendimiento; por ejemplo, un valor de "cn=users,dc=domain" solo devolverá los resultados contenidos en "cn=users" y sus elementos secundarios.
• Scope: esta propiedad permite un control más granular sobre los datos que se devuelven desde un subárbol.

Personalización de Tablas¶

El conector muestra las columnas que se necesitan con más frecuencia de las entidades de Active Directory. Sin embargo, si necesita trabajar con otros datos, las tablas son fáciles de modificar. Las tablas se definen en archivos de esquema, que tienen un formato simple.

Consulte Trabajar con tablas de Active Directory para obtener una guía para ampliar los esquemas predeterminados o escribir uno propio. Para usar esquemas personalizados, configure Location propiedad a la carpeta que contiene los archivos de esquema.

Trabajar con Tablas de Active Directory¶

El conector incluye esquemas de tablas para muchos objetos estándar de Active Directory. Puede ampliar fácilmente los esquemas de tabla incluidos para editar el comportamiento de las columnas o puede escribir uno propio desde cero.

Los esquemas de tablas se definen en archivos .rsd, que son archivos de configuración simples. Esta sección le guiará a través de diferentes partes del esquema, agregando varias columnas a la tabla Person como ejemplo.

Puede encontrar el archivo Person.rsd en la subcarpeta db en la carpeta de instalación de Jitterbit Connector for Active Directory.

Conexión a Tablas Personalizadas¶

Para usar esquemas personalizados, configure Location propiedad a la carpeta que contiene los archivos de esquema.

Definición de una Nueva Tabla¶

Es importante definir una nueva tabla con el mismo nombre que la clase de objeto que representará la tabla. Esto permitirá que el conector busque solo la clase de objeto deseada al consultar el servidor de Active Directory. El nombre del archivo define el nombre de la tabla.

Definición de Entradas y Columnas de Tabla¶

Las columnas se definen en el rsb:info bloque, como se muestra a continuación. El attr Las etiquetas en el esquema representan las columnas de la tabla. Estos deben coincidir con los atributos que componen la clase de objeto deseada.

Hay algunas columnas que toda tabla debe incluir, independientemente de la clase de objeto:

<rsb:script xmlns:rsb="http://www.rssbus.com/ns/rsbscript/2">
<rsb:info title="Person" description="Create, update, delete, and query person entries in Active Directory.">
<!-- Required Columns -->
<attr name="Id"          xs:type="string" readonly="true"  key="true"        />
<attr name="DN"          xs:type="string" readonly="true"  required="false" other:ldaptype="OID" />
<attr name="RDN"         xs:type="string" readonly="true"  required="false" other:ldaptype="Directory String" />
<attr name="BaseDN"      xs:type="string" readonly="true"  required="false" other:ldaptype="OID" />

Nota la title atributo de la rsb:info El bloque debe coincidir con el nombre del archivo .rsd.

Personalización del Comportamiento de la Columna¶

Cada columna requiere al menos name y xs:type atributos Además, deberá especificar dataFormat para decidir cómo se devuelven los datos de la tabla. Por ejemplo:

<!-- Person Required Attributes -->
<attr name="ObjectClass"                 other:dataFormat="splitDataByRow" xs:type="string" readonly="false" required="false" other:ldaptype="OID" />
<attr name="SN"                          other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="CN"                          other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />

<!-- Person Optional Attributes -->
<attr name="UserPassword"                other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="Binary" />
<attr name="TelephoneNumber"             other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="SeeAlso"                     other:dataFormat="delimitedData"  xs:type="string" readonly="false" required="false" other:ldaptype="DN" />
<attr name="Description_1"               other:dataFormat="splitDataByCol" xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="Description_2"               other:dataFormat="splitDataByCol" xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="Description_3"               other:dataFormat="splitDataByCol" xs:type="string" readonly="false" required="false" other:ldaptype="Directory String" />

El other:dataFormat El atributo tiene tres opciones:

• delimitedData: devuelve varios valores de atributo de Active Directory como cadenas delimitadas, separadas por el delimiter carácter definido en la sección Configuración de la tabla del archivo .rsd, que se detalla más adelante.

  Este es el formato predeterminado en el que recuperar datos y el delimitador predeterminado es un punto y coma.

• splitDataByRow: inserte varios valores de atributo de Active Directory para el mismo DN como filas separadas. Todas las demás columnas se insertarán de manera consistente y el índice en ID se incrementará. Nota: Empujar varias columnas como esta aumentará exponencialmente el conjunto de resultados, lo que podría causar problemas de rendimiento.

• splitDataByCol: inserte varios valores de atributos de Active Directory para el mismo DN con un índice adjunto en el nombre de la columna. Debe definir varias columnas y agregar un "_n" al final; por ejemplo, ObjectClass_1, ObjectClass_2 y ObjectClass_3. En este ejemplo, si hay más de 3 valores, los valores restantes no serán visibles en la tabla, a menos que se agreguen más columnas.

Ejemplo: División del Atributo ObjectClass¶

El siguiente código se puede utilizar para dividir los diferentes valores de la ObjectClass atributos en sus propias filas y Description atributos en sus propias columnas. Observe que la definición de columna ahora incluye varias columnas para el Description atributo. También tenga en cuenta el other:dataFormat atributo para el attr.

...
<attr name="ObjectClass"     other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="OID" />
<attr name="SN"              other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" /> 
<attr name="CN"              other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" /> 
<attr name="UserPassword"    other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Binary" />
<attr name="TelephoneNumber" other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="SeeAlso"         other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="DN" />
<attr name="Description_1"   other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="Description_2"   other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />
<attr name="Description_3"   other:dataFormat="delimitedData" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" />

</rsb:info>

<!-- Table Settings -->
<rsb:set attr="delimiter" value=";"/>
...

Un resultado de ejemplo se verá así:

Especificación de la Codificación de Columnas¶

Además del formato de datos en las entradas, también se puede especificar la codificación. Actualmente, se admite la devolución de datos con codificación UTF8 o codificación BASE64. Para recuperar datos con una codificación específica, el other:encoding El campo debe especificarse para que se codifique el atributo deseado. Si no se especifica la codificación, UTF8 es la predeterminada.

Un ejemplo de especificación de codificación para un atributo:

...
<attr name="ObjectClass"     other:dataFormat="delimitedData" other:encoding="UTF8"   xs:type="string"  readonly="false" required="false" other:ldaptype="OID" desc="The object class of the entry."/>
<attr name="SN"              other:dataFormat="delimitedData" other:encoding="BASE64" xs:type="string"  readonly="false" required="false" other:ldaptype="Directory String" desc="The surname of the person."/> 
...

Modificación del Comportamiento del Filtro¶

Opcionalmente, hay dos atributos que se pueden usar para controlar cómo se maneja el filtrado cuando se usa el controlador con SupportEnhancedSQL. El other:ldaptype El atributo se puede utilizar para establecer la sintaxis LDAP de un campo. Esto se usa para determinar los operadores de comparación que se admiten en el lado del servidor por campo. Por ejemplo, si un campo está marcado como el tipo 'DN' y una consultar filtra para una subcadena (es decir, CONTIENE), que no es compatible en el lado del servidor, el controlador procesará esta parte del filtro completamente en el lado del cliente. Los nombres de tipo admitidos se encuentran en la sección 4.3.2 de RFC 2252. Si no está seguro del tipo o simplemente desea deshabilitar por completo el filtrado del lado del servidor para una columna determinada, el other:filterable El atributo también está disponible. Establecer esto en falso para el campo evitará que esto se envíe al servidor en un filtro, anulando el other:ldaptype atributo por completo.

Configuración de los Ajustes de la Tabla¶

Además de los atributos y las entradas, deberá especificar el delimiter.

El delimiter especifica el carácter que se utilizará para los datos delimitados. Se devolverán datos delimitados para cualquier atributo que aparezca varias veces para un solo objeto (a menos que se especifique lo contrario en other:dataFormat).

Por ejemplo, el siguiente código concatenará múltiples valores de un atributo usando el ';' personaje.

...
</rsb:info>  

<!-- Table Settings -->
<rsb:set attr="delimiter" value=";"/>
...

Definición de Operaciones Admitidas¶

Las definiciones de operaciones seguirán siendo exactamente las mismas para todas las tablas recién creadas: simplemente cópielas y péguelas desde una tabla existente, según sea necesario.

<!-- Operation definitions -->
<rsb:script method="GET">
<rsb:set attr="action" value="Get" />
<rsb:call op="ldapadoLDAP" >
<rsb:push />
</rsb:call>
</rsb:script>

<rsb:script method="POST">
<rsb:set attr="action" value="Post" />
<rsb:call op="ldapadoLDAP" >
<rsb:push item="toout"/>
</rsb:call>
</rsb:script>

<rsb:script method="MERGE">
<rsb:set attr="action" value="Merge" />
<rsb:call op="ldapadoLDAP" >
<rsb:push />
</rsb:call>
</rsb:script>

<rsb:script method="DELETE">
<rsb:set attr="action" value="Delete" />
<rsb:call op="ldapadoLDAP" >
<rsb:push />
</rsb:call>
</rsb:script>

Notas Importantes¶

Procedimientos Almacenados¶

• Las funciones de procedimientos almacenados descritas en esta documentación no se admiten actualmente.
• Debido a que los procedimientos almacenados no se admiten actualmente, cualquier característica que dependa de los procedimientos almacenados tampoco se admite actualmente.

Archivos de Configuración y Sus Rutas¶

• Todas las referencias a la adición de archivos de configuración y sus rutas se refieren a archivos y ubicaciones en Harmony Agente donde está instalado el conector. Estas rutas deben ajustarse según corresponda según el agente y el sistema operativo. Si se utilizan varios agentes en un grupo de agentes, se requerirán archivos idénticos en cada agente.

Características Avanzadas¶

Esta sección detalla una selección de funciones avanzadas del conector de Active Directory.

Vistas definidas por el usuario

El conector le permite definir tablas virtuales, llamadas vistas definidas por el usuario, cuyo contenido se decide mediante una consultar preconfigurada. Estas vistas son útiles cuando no puede controlar directamente las consultas que se envían a los controladores. Consulte Vistas definidas por el usuario para obtener una descripción general de la creación y configuración de vistas personalizadas.

Configuración SSL

Usar Configuración SSL para ajustar cómo el conector maneja las negociaciones de certificados TLS/SSL. Puede elegir entre varios formatos de certificado; ver el SSLServerCert propiedad en "Opciones de cadena de conexión" para obtener más información.

Firewall y Proxy

Configure el conector para cumplir con Firewall y Proxy, incluidos los proxies de Windows. También puede configurar conexiones de túnel.

Vistas Definidas por el Usuario¶

El conector Jitterbit para Active Directory le permite definir una tabla virtual cuyo contenido se decide mediante una consultar preconfigurada. Estas se denominan Vistas definidas por el usuario, que son útiles en situaciones en las que no puede controlar directamente la consultar que se envía al controlador, por ejemplo, cuando se utiliza el controlador de Jitterbit. Las vistas definidas por el usuario se pueden utilizar para definir predicados que siempre se aplican. Si especifica predicados adicionales en la consultar a la vista, se combinan con la consultar ya definida como parte de la vista.

Hay dos formas de crear vistas definidas por el usuario:

• Cree un archivo de configuración con formato JSON que defina las vistas que desea.
• Declaraciones DDL.

Definición de Vistas Usando un Archivo de Configuración¶

Las vistas definidas por el usuario se definen en un archivo de configuración con formato JSON llamado UserDefinedViews.json. El conector detecta automáticamente las vistas especificadas en este archivo.

También puede tener múltiples definiciones de vista y controlarlas usando UserDefinedViews propiedad de conexión. Cuando utiliza esta propiedad, el conector solo ve las vistas especificadas.

Este archivo de configuración de vista definida por el usuario tiene el siguiente formato:

• Cada elemento raíz define el nombre de una vista.
• Cada elemento raíz contiene un elemento hijo, llamado query, que contiene la consultar SQL personalizada para la vista.

Por ejemplo:

{
    "MyView": {
        "query": "SELECT * FROM User WHERE MyColumn = 'value'"
    },
    "MyView2": {
        "query": "SELECT * FROM MyTable WHERE Id IN (1,2,3)"
    }
}

Utilizar el UserDefinedViews propiedad de conexión para especificar la ubicación de su archivo de configuración JSON. Por ejemplo:

"UserDefinedViews", "C:\Users\yourusername\Desktop\tmp\UserDefinedViews.json"

Esquema para Vistas Definidas por el Usuario¶

Las vistas definidas por el usuario se exponen en UserViews esquema por defecto. Esto se hace para evitar que el nombre de la vista entre en conflicto con una entidad real en el modelo de datos. Puede cambiar el nombre del esquema utilizado para UserViews configurando UserViewsSchemaName propiedad.

Trabajar con Vistas Definidas por el Usuario¶

Por ejemplo, una instrucción SQL con una vista definida por el usuario llamada UserViews.RCustomers solo enumera clientes en Raleigh:

SELECT * FROM Customers WHERE City = 'Raleigh';

Un ejemplo de una consultar al controlador:

SELECT * FROM UserViews.RCustomers WHERE Status = 'Active';

Dando como resultado la consultar efectiva a la fuente:

SELECT * FROM Customers WHERE City = 'Raleigh' AND Status = 'Active';

Ese es un ejemplo muy simple de una consultar a una vista definida por el usuario que es efectivamente una combinación de la consultar de vista y la definición de vista. Es posible componer estas consultas en patrones mucho más complejos. Todas las operaciones de SQL están permitidas en ambas consultas y se combinan cuando corresponde.

Configuración SSL¶

Personalización de la Configuración SSL¶

De forma predeterminada, el conector intenta negociar SSL/TLS comparando el certificado del servidor con el almacén de certificados de confianza del sistema.

Para especificar otro certificado, consulte SSLServerCert propiedad de los formatos disponibles para hacerlo.

Modelo de Datos¶

El conector Jitterbit para Active Directory modela entidades de Active Directory en tablas relacionales y procedimientos almacenados.

Mesas

Las Tablas incluidas cubren muchas clases de objetos estándar de Active Directory. Puede ampliar fácilmente los esquemas para que se acerquen más a sus clases de Active Directory. Los esquemas se definen en archivos de configuración simples.

Para usar tablas y esquemas personalizados, configure Location propiedad a la carpeta que contiene los archivos de esquema. Los esquemas enviados con el conector se encuentran en la subcarpeta db del directorio de instalación.

Consulte Trabajar con tablas de Active Directory para obtener una guía para personalizar esquemas de tablas.

Procedimientos almacenados

NOTE: Los procedimientos almacenados no se admiten actualmente. Consulte la nota anterior para detalles.

Procedimientos almacenados son interfaces similares a funciones para la fuente de datos. Se pueden usar para acceder a la funcionalidad de Active Directory no representada como SELECCIONAR, INSERTAR, ACTUALIZAR o ELIMINAR.

Procesamiento colaborativo de consultas

Las limitaciones y los requisitos de la API se documentan en esta sección. El conector descarga la mayor parte posible del procesamiento de la declaración SELECT en Active Directory y luego procesa el resto de la consultar en la memoria.

Ver SupportEnhancedSQL para obtener más información sobre cómo el conector elude las limitaciones de la API con el procesamiento del lado del cliente en memoria.

Mesas¶

El conector modela los datos en Active Directory en una lista de tablas que se pueden consultar mediante instrucciones SQL estándar.

Generalmente, consultar tablas de Active Directory es lo mismo que consultar una tabla en una base de datos relacional. A veces hay casos especiales, por ejemplo, incluir una determinada columna en la cláusula WHERE puede ser necesario para obtener datos para ciertas columnas de la tabla. Esto suele ser necesario para situaciones en las que se debe realizar una solicitud separada para cada fila para obtener ciertas columnas. Estos tipos de situaciones están claramente documentados en la parte superior de la página de la tabla vinculada a continuación.

Conector Jitterbit para Tablas de Active Directory¶

Cuenta¶

La clase de objeto de cuenta se utiliza para definir entradas que representan cuentas de equipo.

Columnas¶

Pseudo-Columnas¶

Los campos de pseudocolumna se utilizan en la cláusula WHERE de las declaraciones SELECT y ofrecen un control más granular sobre las tuplas que se devuelven desde la fuente de datos.

Entidad de Aplicación¶

Clase base X.500 para aplicaciones: el servicio de directorio solo usa la subclase MSFT-DSA.

Columnas¶

Pseudo-Columnas¶

Los campos de pseudocolumna se utilizan en la cláusula WHERE de las declaraciones SELECT y ofrecen un control más granular sobre las tuplas que se devuelven desde la fuente de datos.

Proceso de Solicitud¶

Clase base X.500 para aplicaciones: Exchange solo usa la subclase DSA-Application.

Columnas¶

Pseudo-Columnas¶

Los campos de pseudocolumna se utilizan en la cláusula WHERE de las declaraciones SELECT y ofrecen un control más granular sobre las tuplas que se devuelven desde la fuente de datos.

Configuraciones de la Aplicación¶

Clase base para la configuración de la aplicación específica del servidor.

Columnas¶

Pseudo-Columnas¶

Los campos de pseudocolumna se utilizan en la cláusula WHERE de las declaraciones SELECT y ofrecen un control más granular sobre las tuplas que se devuelven desde la fuente de datos.

Configuración del Sitio de la Aplicación¶

Contiene todas las configuraciones específicas del sitio.

Columnas¶

Pseudo-Columnas¶

Los campos de pseudocolumna se utilizan en la cláusula WHERE de las declaraciones SELECT y ofrecen un control más granular sobre las tuplas que se devuelven desde la fuente de datos.

Versión de la Aplicación¶

Los desarrolladores de aplicaciones pueden utilizarla para almacenar información sobre la versión de su aplicación o su esquema.

Columnas¶

Pseudo-Columnas¶

Los campos de pseudocolumna se utilizan en la cláusula WHERE de las declaraciones SELECT y ofrecen un control más granular sobre las tuplas que se devuelven desde la fuente de datos.

DominioIntegrado¶

El contenedor que contiene los grupos predeterminados para un dominio.

Columnas¶

Pseudo-Columnas¶

Los campos de pseudocolumna se utilizan en la cláusula WHERE de las declaraciones SELECT y ofrecen un control más granular sobre las tuplas que se devuelven desde la fuente de datos.

Autoridad de Certificación¶

Representa un proceso que emite certificados de clave pública, por ejemplo, un servidor de certificados.

Columnas¶

Pseudo-Columnas¶

Los campos de pseudocolumna se utilizan en la cláusula WHERE de las declaraciones SELECT y ofrecen un control más granular sobre las tuplas que se devuelven desde la fuente de datos.

Computadora¶

Esta clase representa una cuenta de equipo en el dominio.

Columnas¶