Detalhes da Conexão do Active Directory¶

Introdução¶

Versão do conector

Esta documentação é baseada na versão 21.0.8257 do conector.

Começando¶

Suporte à versão do Active Directory

O conector fornece acesso baseado em SQL ao Active Directory por meio do protocolo LDAP. O conector é um cliente LDAP padrão que suporta LDAP v2 e v3.

Estabelecendo uma Conexão¶

Autenticação no Active Directory¶

Para autenticar solicitações, defina o User e Password propriedades para credenciais válidas do Active Directory (por exemplo, definir User para "Domínio\BobF" ou "cn=Bob F,ou=Funcionários,dc=Domínio").

O conector usa autenticação de texto sem formatação por padrão, pois o conector tenta negociar TLS/SSL com o servidor. Você pode especificar outro método de autenticação com AuthMechanism.

Consulte Configuração SSL para obter mais informações sobre a configuração TLS/SSL.

Conectando ao Active Directory¶

Definir Server e Port para conectividade básica. Além disso, você pode ajustar a conexão com o seguinte:

• FollowReferrals: Quando definido, o conector apresenta dados como exibições apenas de servidores de referência. Para modificar dados em um servidor de referência, você deve especificar este servidor com Server e Port.
• LDAPVersion: Configure para a versão do protocolo que seu servidor implementa; por padrão, o conector usa a versão 2.

Acesso a Dados de Ajuste Fino¶

As seguintes propriedades controlam o escopo dos dados retornados:

• BaseDN limitará o escopo das pesquisas LDAP à altura do nome distinto fornecido. Nota: Especificando um estreito BaseDN pode aumentar muito o desempenho; por exemplo, um valor de "cn=users,dc=domain" retornará apenas os resultados contidos em "cn=users" e seus filhos.
• Scope: Esta propriedade permite um controle mais granular sobre os dados a serem retornados de uma subárvore.

Personalizando Tabelas¶

O conector exibe as colunas mais frequentemente necessárias das entidades do Active Directory. No entanto, se você precisar trabalhar com outros dados, as tabelas são fáceis de modificar. As tabelas são definidas em arquivos de esquema, que possuem um formato simples.

Consulte Trabalhando com tabelas do Active Directory para obter um guia para estender os esquemas padrão ou escrever seus próprios. Para usar esquemas personalizados, defina o Location para a pasta que contém os arquivos de esquema.

Trabalhando com Tabelas do Active Directory¶

O conector inclui esquemas de tabela para muitos objetos padrão do Active Directory. Você pode estender facilmente os esquemas de tabela incluídos para editar o comportamento da coluna ou pode escrever o seu próprio a partir do zero.

Os esquemas de tabela são definidos em arquivos .rsd, que são arquivos de configuração simples. Esta seção percorrerá diferentes partes do esquema, adicionando várias colunas à tabela Person como exemplo.

Você pode encontrar o arquivo Person.rsd na subpasta db na pasta de instalação do Jitterbit Connector for Active Directory.

Conectando-se a Tabelas Personalizadas¶

Para usar esquemas personalizados, defina o Location para a pasta que contém os arquivos de esquema.

Definindo uma Nova Tabela¶

É importante definir uma nova tabela com o mesmo nome da classe de objeto que a tabela irá representar. Isso permitirá que o conector procure apenas a classe de objeto desejada ao consultar o servidor Active Directory. O nome do arquivo define o nome da tabela.

Definindo Colunas e Entradas da Tabela¶

As colunas são definidas no rsb:info bloco, mostrado abaixo. O attr tags no esquema representam as colunas da tabela. Estes devem corresponder aos atributos que compõem a classe de objeto desejada.

Existem algumas colunas que toda tabela deve incluir, independentemente da classe do 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" />

*Note o title atributo do rsb:info O bloco deve corresponder ao nome do arquivo .rsd.

Personalizando o Comportamento da Coluna¶

Cada coluna requer pelo menos name e xs:type atributos. Além disso, você precisará especificar dataFormat para decidir como os dados são retornados da tabela. Por exemplo:

<!-- 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" />

O other:dataFormat atributo tem três opções:

• delimitedData: Retorna vários valores de atributo do Active Directory como strings delimitadas, separadas pelo delimiter caractere definido na seção Table Settings do arquivo .rsd, detalhado posteriormente.

  Este é o formato padrão no qual recuperar dados e o padrão do delimitador é um ponto e vírgula.

• splitDataByRow: Empurre vários valores de atributo do Active Directory para o mesmo DN como linhas separadas. Todas as outras colunas serão enviadas consistentemente e o índice em ID será incrementado. Observação: Inserir várias colunas como essa aumentará exponencialmente o conjunto de resultados, podendo causar problemas de desempenho.

• splitDataByCol: Empurre vários valores de atributo do Active Directory para o mesmo DN com um índice anexado ao nome da coluna. Você precisa definir várias colunas e acrescentar um "_n" ao final; por exemplo, ObjectClass_1, ObjectClass_2 e ObjectClass_3. Neste exemplo, se houver mais de 3 valores, os valores restantes não ficarão visíveis na tabela, a menos que mais colunas sejam adicionadas.

Exemplo: Dividindo o Atributo ObjectClass¶

O código abaixo pode ser usado para dividir os diferentes valores do ObjectClass atributos em suas próprias linhas e Description atributos em suas próprias colunas. Observe que a definição da coluna agora inclui várias colunas para o Description atributo. Observe também o other:dataFormat atributo para o 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=";"/>
...

Um resultado de exemplo será semelhante a:

Especificando Codificação de Coluna¶

Além do formato de dados nas entradas, a codificação também pode ser especificada. Atualmente, há suporte para o retorno de dados com codificação UTF8 ou codificação BASE64. Para recuperar dados com uma codificação especificada, o other:encoding campo deve ser especificado para que o atributo desejado seja codificado. Se nenhuma codificação for especificada, UTF8 será o padrão.

Um exemplo de especificação de codificação para um 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."/> 
...

Modificando o Comportamento do Filtro¶

Opcionalmente, existem dois atributos que podem ser usados para controlar como a filtragem é tratada ao usar o driver com SupportEnhancedSQL. O other:ldaptype O atributo pode ser usado para definir a sintaxe LDAP de um campo. Isso é usado para determinar os operadores de comparação com suporte no lado do servidor por campo. Por exemplo, se um campo estiver marcado como o tipo 'DN' e uma filtragem de consultar para uma substring (isto é, CONTAINS), que não é suportada no lado do servidor, o driver processará essa parte do filtro inteiramente no lado do cliente. Os nomes de tipo suportados são encontrados na seção 4.3.2 do RFC 2252. Se você não tiver certeza do tipo ou apenas deseja desativar totalmente a filtragem do lado do servidor para uma determinada coluna, o other:filterable atributo também está disponível. Definir como falso para o campo impedirá que ele seja enviado ao servidor em um filtro, substituindo o other:ldaptype atributo inteiramente.

Configurando as Configurações da Tabela¶

Além dos atributos e entradas, você precisará especificar o delimiter.

O delimiter especifica o caractere que será usado para dados delimitados. Os dados delimitados serão retornados para qualquer atributo que apareça várias vezes para um único objeto (a menos que especificado de outra forma em other:dataFormat).

Por exemplo, o código abaixo irá concatenar vários valores de um atributo usando o ';' personagem.

...
</rsb:info>  

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

Definindo Operações Suportadas¶

As definições de operação permanecerão exatamente as mesmas para todas as tabelas recém-criadas: simplesmente copie e cole-as de uma tabela existente, conforme necessário.

<!-- 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>

Anotações Importantes¶

Procedimentos Armazenados¶

• Os recursos de procedimentos armazenados descritos nesta documentação não são suportados no momento.
• Como os procedimentos armazenados não são suportados atualmente, qualquer recurso dependente de procedimentos armazenados também não é suportado atualmente.

Arquivos de Configuração e Seus Caminhos¶

• Todas as referências para adicionar arquivos de configuração e seus caminhos referem-se a arquivos e locais no Harmony Agente onde o conector está instalado. Esses caminhos devem ser ajustados conforme apropriado, dependendo do agente e do sistema operacional. Se vários agentes forem usados em um grupo de agentes, arquivos idênticos serão necessários em cada agente.

Características Avançadas¶

Esta seção detalha uma seleção de recursos avançados do conector do Active Directory.

Visualizações definidas pelo usuário

O conector permite definir tabelas virtuais, denominadas visões definidas pelo usuário, cujo conteúdo é decidido por uma consultar pré-configurada. Essas exibições são úteis quando você não pode controlar diretamente as consultas enviadas aos drivers. Consulte Visualizações definidas pelo usuário para obter uma visão geral da criação e configuração de exibições personalizadas.

Configuração SSL

Use Configuração SSL para ajustar como o conector lida com as negociações de certificado TLS/SSL. Você pode escolher entre vários formatos de certificado; Veja o SSLServerCert propriedade em "Opções de cadeia de conexão" para obter mais informações.

Firewall e Proxy

Configure o conector para conformidade com Firewall e Proxy, incluindo proxies do Windows. Você também pode configurar conexões de túnel.

Visualizações Definidas pelo Usuário¶

O Jitterbit Connector for Active Directory permite definir uma tabela virtual cujo conteúdo é decidido por uma consultar pré-configurada. Elas são chamadas de Visualizações Definidas pelo Usuário, que são úteis em situações onde você não pode controlar diretamente a consultar que está sendo emitida para o driver, por exemplo, ao usar o driver do Jitterbit. As Visualizações Definidas pelo Usuário podem ser usadas para definir predicados que são sempre aplicados. Se você especificar predicados adicionais na consultar para a visualização, eles serão combinados com a consultar já definida como parte da visualização.

Há duas maneiras de criar exibições definidas pelo usuário:

• Crie um arquivo de configuração em formato JSON definindo as visualizações desejadas.
• declarações DDL.

Definindo Visualizações Usando um Arquivo de Configuração¶

As visualizações definidas pelo usuário são definidas em um arquivo de configuração formatado em JSON chamado UserDefinedViews.json. O conector detecta automaticamente as visualizações especificadas neste arquivo.

Você também pode ter várias definições de exibição e controlá-las usando o UserDefinedViews propriedade de conexão. Quando você usa essa propriedade, apenas as exibições especificadas são vistas pelo conector.

Este arquivo de configuração de exibição definida pelo usuário é formatado da seguinte forma:

• Cada elemento raiz define o nome de uma exibição.
• Cada elemento raiz contém um elemento filho, chamado query, que contém a consultar SQL personalizada para a exibição.

Por exemplo:

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

Use o UserDefinedViews propriedade de conexão para especificar a localização do seu arquivo de configuração JSON. Por exemplo:

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

Esquema para Exibições Definidas pelo Usuário¶

As visualizações definidas pelo usuário são expostas no UserViews esquema por padrão. Isso é feito para evitar que o nome da exibição entre em conflito com uma entidade real no modelo de dados. Você pode alterar o nome do esquema usado para UserViews definindo o UserViewsSchemaName propriedade.

Trabalhando com Exibições Definidas pelo Usuário¶

Por exemplo, uma instrução SQL com uma Visualização Definida pelo Usuário chamada UserViews.RCustomers lista apenas clientes em Raleigh:

SELECT * FROM Customers WHERE City = 'Raleigh';

Exemplo de consultar ao driver:

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

Resultando na consultar efetiva à fonte:

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

Esse é um exemplo muito simples de uma consultar a uma exibição definida pelo usuário que é efetivamente uma combinação da consultar de exibição e da definição de exibição. É possível compor essas consultas em padrões muito mais complexos. Todas as operações SQL são permitidas em ambas as consultas e são combinadas quando apropriado.

Configuração SSL¶

Personalizando a Configuração SSL¶

Por padrão, o conector tenta negociar SSL/TLS verificando o certificado do servidor em relação ao armazenamento de certificados confiáveis do sistema.

Para especificar outro certificado, consulte o SSLServerCert propriedade para os formatos disponíveis para fazê-lo.

Modelo de Dados¶

O Jitterbit Connector for Active Directory modela entidades do Active Directory em tabelas relacionais e procedimentos armazenados.

Mesas

As Tabelas cobrem muitas classes de objetos padrão do Active Directory. Você pode facilmente estender os esquemas para mapear mais de perto suas classes do Active Directory. Os esquemas são definidos em arquivos de configuração simples.

Para usar tabelas e esquemas personalizados, defina o Location para a pasta que contém os arquivos de esquema. Os esquemas fornecidos com o conector estão localizados na subpasta db do diretório de instalação.

Consulte Trabalhando com tabelas do Active Directory para obter um guia para personalizar esquemas de tabela.

Procedimentos armazenados

NOTE: Procedimentos armazenados não são suportados atualmente. Veja a nota para detalhes.

Procedimentos armazenados são interfaces semelhantes a funções para a fonte de dados. Eles podem ser usados para acessar a funcionalidade do Active Directory não representada como SELECT, INSERT, UPDATE ou DELETE.

Processamento de consulta colaborativa

As limitações e os requisitos da API estão documentados nesta seção. O conector transfere o máximo possível do processamento da instrução SELECT para o Active Directory e, em seguida, processa o restante da consultar na memória.

Ver SupportEnhancedSQL para obter mais informações sobre como o conector contorna as limitações da API com processamento na memória do lado do cliente.

Tabelas¶

O conector modela os dados no Active Directory em uma lista de tabelas que podem ser consultadas usando instruções SQL padrão.

Geralmente, consultar tabelas do Active Directory é o mesmo que consultar uma tabela em um banco de dados relacional. Às vezes, há casos especiais, por exemplo, incluir uma determinada coluna na cláusula WHERE pode ser necessário para obter dados para determinadas colunas na tabela. Isso geralmente é necessário para situações em que uma solicitação separada deve ser feita para cada linha para obter determinadas colunas. Esses tipos de situações estão claramente documentados na parte superior da página da tabela vinculada abaixo.

Conector Jitterbit para Tabelas do Active Directory¶

Conta¶

A classe de objeto de conta é usada para definir entradas que representam contas de computador.

Colunas¶

Pseudo-colunas¶

Os campos de pseudocoluna são usados na cláusula WHERE das instruções SELECT e oferecem um controle mais granular sobre as tuplas que são retornadas da fonte de dados.

ApplicationEntity¶

Classe base X.500 para aplicativos: o serviço de diretório usa apenas a subclasse MSFT-DSA.

Colunas¶

Pseudo-colunas¶

Os campos de pseudocoluna são usados na cláusula WHERE das instruções SELECT e oferecem um controle mais granular sobre as tuplas que são retornadas da fonte de dados.

Processo de Aplicação¶

Classe base X.500 para aplicativos: o Exchange usa apenas a subclasse DSA-Application.

Colunas¶

Pseudo-colunas¶

Os campos de pseudocoluna são usados na cláusula WHERE das instruções SELECT e oferecem um controle mais granular sobre as tuplas que são retornadas da fonte de dados.

Configurações do Aplicativo¶

Classe base para configurações de aplicativo específicas do servidor.

Colunas¶

Pseudo-colunas¶

Os campos de pseudocoluna são usados na cláusula WHERE das instruções SELECT e oferecem um controle mais granular sobre as tuplas que são retornadas da fonte de dados.

ApplicationSiteSettings¶

Contém todas as configurações específicas do site.

Colunas¶

Pseudo-colunas¶

Os campos de pseudocoluna são usados na cláusula WHERE das instruções SELECT e oferecem um controle mais granular sobre as tuplas que são retornadas da fonte de dados.

ApplicationVersion¶

Pode ser usado por desenvolvedores de aplicativos para armazenar informações de versão sobre seu aplicativo ou seu esquema.

Colunas¶

Pseudo-colunas¶

Os campos de pseudocoluna são usados na cláusula WHERE das instruções SELECT e oferecem um controle mais granular sobre as tuplas que são retornadas da fonte de dados.

BuiltinDomain¶

O contêiner que contém os grupos padrão de um domínio.

Colunas¶

Pseudo-colunas¶

Os campos de pseudocoluna são usados na cláusula WHERE das instruções SELECT e oferecem um controle mais granular sobre as tuplas que são retornadas da fonte de dados.

Autoridade de Certificação¶

Representa um processo que emite certificados de chave pública, por exemplo, um Certificate Server.

Colunas¶

Pseudo-colunas¶

Os campos de pseudocoluna são usados na cláusula WHERE das instruções SELECT e oferecem um controle mais granular sobre as tuplas que são retornadas da fonte de dados.

Computador¶

Esta classe representa uma conta de computador no domínio.

Colunas¶