Active Directory

Noções básicas sobre a autenticação de proxy no AD LDS

Ken St. Cyr

Visão geral:

• Definindo a autenticação de proxy
• Por que a autenticação de proxy é útil
• Por dentro do objeto proxy
• O que acontece durante a autenticação

Sumário

O que é a autenticação de proxy?
Vantagens da autenticação de proxy
Por dentro do objeto proxy
Como a autenticação é efetivamente realizada
Configurando um laboratório de autenticação de proxy
Conclusão

Assim como qualquer serviço de diretório habilitado para LDAP, o Microsoft AD LDS (Active Directory Lightweight Directory Services), anteriormente chamado de ADAM, exige que o usuário se associe antes de executar qualquer operação LDAP no diretório. Essa associação pode ser feita usando alguns métodos diferentes, inclusive uma associação LDAP simples, uma associação SASL (Simple Authentication and Security Layer), ou mesmo o redirecionamento de associação. A associação também poderia ser anônima e, nesse caso, o usuário apresentaria uma senha nula. Neste artigo, abordarei e analisarei um método específico: o redirecionamento de associação, também conhecido como autenticação de proxy.

O que é a autenticação de proxy?

A autenticação proxy permite que um usuário realize uma associação simples a uma instância do AD LDS, mantendo, ao mesmo tempo, uma associação a uma conta do Active Directory. Há duas contas envolvidas na transação. A primeira é um objeto especial no AD LDS, chamado de objeto userProxy. A segunda é a conta do usuário no Active Directory.

O objeto userProxy do AD LDS é uma representação da conta do Active Directory. O objeto proxy é vinculado à conta do Active Directory por meio do SID (identificador de segurança) da conta. Nenhuma senha é armazenada no objeto proxy propriamente dito.

Quando um usuário realiza uma associação simples a uma instância do LDS com um objeto proxy, o vínculo é redirecionado para o Active Directory, com a passagem do SID e da senha para um controlador de domínio. O servidor AD LDS realiza a autenticação, e todo o processo é invisível para o usuário final. Isso é ilustrado na Figura 1, onde Lucy se conecta a uma instância do AD LDS chamada "CN=AppDir,DC=contoso,DC=com" com sua conta de usuária do AD LDS.

Figura 1 Conectando-se ao AD LDS (clique na imagem para ampliá-la)

Para a autenticação, Lucy usa uma associação simples, e fornece seu DN (nome diferenciado) e sua senha, como faria em uma associação LDAP normal. Embora Lucy aparentemente se conecte usando sua conta típica de usuária do LDS, ela está na verdade usando um objeto proxy. A autenticação no Active Directory ocorre nos bastidores, e Lucy nem imagina que está usando sua conta do Active Directory para associar-se.

Vantagens da autenticação de proxy

A eficiência da autenticação de proxy se deve ao fato de proporcionar aos desenvolvedores de aplicativos acesso a um objeto user, sem fornecer acesso à conta do Active Directory. Imagine o que acontece quando um novo aplicativo habilitado para diretório está sendo criado, e o aplicativo precisa armazenar alguns dados no Active Directory. O aplicativo pode usar um atributo existente ou criar um novo.

O perigo de usar um atributo já existente e não utilizado é que o atributo provavelmente está lá para alguma finalidade. Mesmo que não esteja em uso no momento, pode vir a ser usado no futuro. E, se servir para um objetivo diferente, os administradores do Active Directory precisarão manter o controle da forma como ele está sendo utilizado. E se o desenvolvedor do aplicativo precisar de mais de um atributo?

Com a autenticação de proxy, uma representação do objeto user do Active Directory já existe no diretório do AD LDS. Um diretório específico do aplicativo permite ao desenvolvedor modificar o esquema da forma como preferir, no contexto do AD LDS. É possível adicionar, alterar ou redefinir a finalidade de atributos da maneira escolhida pelo desenvolvedor, e o administrador do Active Directory não precisa se preocupar em fazer várias alterações no esquema ou manter o controle da forma como os atributos são usados. Se outro aplicativo se conectar e quiser utilizar o mesmo atributo, isso não será um problema, pois poderá ser uma instância separada do AD LDS, o que não criará nenhum conflito de atributos.

A autenticação de proxy também pode ser útil em situações que exigem o formato X.500. O Active Directory não usa a nomenclatura X.500 típica para DNs. Por exemplo, um objeto user no Active Directory tem o DN "CN=Lucy D. Smith,CN=Users,DC=contoso,DC=com". Contudo, no AD LDS, o DN do usuário pode ser "CN=Lucy D. Smith,CN=Users,O=Contoso,C=US", que é compatível com X.500.

Isso é útil quando você está usando um cliente LDAP de terceiros, ou tentando fazer a integração com um diretório de terceiros que exige o formato X.500. Dessa forma, o LDS pode ser um diretório intermediário entre um diretório de terceiros e o Active Directory. Usando a autenticação de proxy, a conta de serviço que o diretório de terceiros precisa usar para associar-se à instância do LDS pode ser mantido no Active Directory, e não no próprio LDS.

Por dentro do objeto proxy

Até aqui, apresentei uma breve visão geral da forma como o objeto proxy do LDS é vinculado à conta do usuário no Active Directory. Agora, explicarei isso de forma mais detalhada e analisarei o que realmente acontece nos bastidores, começando pela classe de objeto.

No Windows Server 2008, o diretório %SYSTEMROOT%\ADAM contém dois arquivos LDF que representam um objeto proxy:

• MS-UserProxy.LDF
• MS-UserProxyFull.LDF

MS-UserProxy.LDF retém a definição da classe simples userProxy, que tem atributos básicos e contém a classe auxiliar msDS-BindProxy. MS-UserProxyFull.LDF também contém a classe auxiliar msDS-BindProxy, mas preenche antecipadamente atributos adicionais de usuário no atributo mayContain da classe. Por isso, as classes do atributo precisam existir de antemão. Então, ao importar a classe userProxyFull, é preciso importar primeiro o usuário ou a classe inetOrgPerson. O usuário e inetOrgPerson contêm as definições da classe para os atributos que userProxyFull utiliza. A Figura 2 mostra as diferenças entre as classes userProxy e userProxyFull.

Figura 2 As classes userProxy e userProxyFull (clique na imagem para ampliá-la)

O fato de que as duas classes contêm msDS-BindProxy como classe auxiliar é significativo. Uma classe auxiliar é um tipo de classe capaz de fornecer dados adicionais a uma classe estrutural. No LDS, por exemplo, a classe User é uma classe estrutural, herdada da classe Organizational-Person. Isso significa que a classe User tem tudo o que Organizational-Person tem. Mas a classe User também tem uma classe auxiliar chamada msDS-BindableObject. Isso significa que User contém todos os atributos obrigatórios e opcionais de msDS-BindableObject, além dos atributos da classe Organizational-Person. Nessa instância, o uso de msDS-BindableObject como classe auxiliar torna a classe User associável.

Como a classe userProxy tem msDS-BindProxy como classe auxiliar (veja a Figura 3), agora contém também todo o conjunto de atributos obrigatórios e opcionais de msDS-BindProxy. A classe auxiliar msDS-BindProxy é o que transforma um objeto em um objeto proxy. Então, mesmo que você tenha uma classe personalizada, poderá adicionar a ela a classe auxiliar msDS-BindProxy, e usar seus objetos personalizados para a autenticação de proxy.

Figura 3 Criando um objeto proxy (clique na imagem para ampliá-la)

Se você examinasse a classe msDS-BindProxy, perceberia que há apenas um atributo obrigatório definido: objectSID. Esse é o atributo onde o SID da conta de usuário do Active Directory será colocado, para criar a associação entre o objeto proxy no LDS e o objeto user no Active Directory. Esse atributo só poderá ser preenchido quando o objeto for criado. Ele não poderá ser alterado sem excluir o objeto e recriá-lo.

Como a autenticação é efetivamente realizada

Para realmente entender o que acontece nos bastidores, precisaremos nos aprofundar um pouco mais na forma como a autenticação é realizada. Descreverei dois rastreamentos de rede que ajudarão a mostrar como a autenticação de proxy funciona. O primeiro rastreamento é uma captura de rede da associação simples de um usuário proxy a uma instância do LDS do Windows Server 2008, feita a partir de uma estação de trabalho Windows XP. Nessa captura, Lucy se associa a seu objeto user proxy utilizando LDP.EXE em sua estação de trabalho.

A Figura 4 mostra os três pacotes na captura que precisamos examinar. O pacote 1 é a solicitação de associação da estação de trabalho (10.0.0.107) para o servidor LDS do Active Directory (10.0.0.201). A solicitação de associação contém o DN de Lucy, "cn=lucy,cn=people,cn=appdir,dc=contoso,dc=com". O pacote 2 é a resposta do servidor LDS do Active Directory para a estação de trabalho, indicando uma associação bem-sucedida. E o pacote 3 é a confirmação da estação de trabalho para o servidor LDS do Active Directory, indicando a confirmação da resposta à associação.

Figura 4 Solicitação de associação e resposta (clique na imagem para ampliá-la)

Se você se aprofundar nos detalhes do pacote 1 (veja a Figura 5), perceberá algo surpreendente. A senha fornecida por Lucy (P@ssw0rd) é exibida em texto não criptografado na captura. Essa é, na verdade, uma das desvantagens de utilizar uma associação LDAP simples para autenticação. A menos que a associação seja encapsulada em criptografia SSL, a senha do usuário será divulgada para quem estiver na rede.

Figura 5 Associação simples com SSL desativado (clique na imagem para ampliá-la)

Contudo, o LDS do Active Directory habilita o SSL por padrão. Você precisa desviar-se do seu curso natural para desativá-lo. Foi exatamente isso o que fiz neste exercício, para tornar o rastreamento de rede legível. E não me preocupei em atribuir um certificado ao servidor LDS do Active Directory. Mas, em uma implementação real, com certeza você vai querer garantir que o servidor LDS do Active Directory tenha um certificado válido que possa ser usado para SSL.

O segundo rastreamento é uma captura de rede do servidor LDS do Active Directory para o DC (controlador de domínio). Esse rastreamento é um pouco maior do que o primeiro. Então, vou dividi-lo em partes. Os nove primeiros pacotes desse rastreamento são mostrados na Figura 6.

Figura 6 AD LDS conectando-se ao controlador de domínio (clique na imagem para ampliá-la)

O primeiro pacote deve lhe parecer familiar. Ele faz parte da solicitação de associação recebida da estação de trabalho. Mais uma vez, o pacote contém o DN e a senha de Lucy em texto não criptografado. Os pacotes de 2 a 9 mostram o servidor AD LDS (10.0.0.201) conectando-se ao controlador de domínio (10.0.0.200). Eles consistem em algumas mensagens no protocolo ARP, seguidas por uma conexão RPC (chamada de procedimento remoto) com o DC (controlador de domínio).

Na Figura 7, os pacotes 10 e 11 chamam um método denominado LsarLookupSids3, em uma chamada RPC que instrui o DC a capturar um lote de SIDs e retornar seus nomes correspondentes. O servidor AD LDS faz a solicitação no pacote 10 e recebe a resposta do DC no pacote 11.

Figura 7 Tentativa de autenticação do Kerberos (clique na imagem para ampliá-la)

Então, após um breve handshake TCP para iniciar a sessão do Kerberos (pacotes 12 a 14), no pacote 15, o servidor AD LDS tenta obter o tíquete de serviço de autenticação (AS-REQ) do KDC (centro de distribuição de chaves). No pacote 16, a solicitação de tíquete de serviço de autenticação é negada, pois o DC está aguardando dados de pré-autenticação que o servidor AD LDS não forneceu. Nesse caso, o DC espera o carimbo de data/hora, que poderá ser usado para verificação de identidade. A sessão do Kerberos termina e uma reinicialização é solicitada (pacotes 17 a 19).

A Figura 8 mostra o resto da captura. Os pacotes 20 a 22 estabelecem uma nova sessão do Kerberos, e uma nova solicitação de serviço de autenticação é enviada pelo servidor AD LDS para o DC, no pacote 23. Essa nova solicitação contém os dados de pré-autenticação necessários, o que é indicado pela resposta bem-sucedida do DC, no pacote 25. Agora, o servidor AD LDS tem o tíquete de serviço de autenticação, e pode fazer uma solicitação ao serviço de concessão de tíquete, a fim de autenticar as credenciais de Lucy.

Figura 8 Autenticação bem-sucedida (clique na imagem para ampliá-la)

A solicitação e a resposta do serviço de concessão de tíquete são capturadas nos pacotes 33 e 34. O recebimento de KRB_TGS_REP no pacote 34 indica que Lucy foi autenticada corretamente. Por fim, no pacote 38, o servidor AD LDS passa a resposta de associação de volta para a estação de trabalho, informando a Lucy que ela foi associada corretamente à instância do AD LDS. Embora esse processo envolva várias etapas, o tempo total da transação é de apenas cerca de um décimo de segundo.

O que aconteceria se Lucy digitasse a senha errada? Em nosso exemplo, a solicitação ao serviço de autenticação falharia no pacote 25. A falha da solicitação ao serviço de autenticação indicaria ao servidor AD LDS que as credenciais de Lucy eram incorretas. Em vez de emitir uma solicitação ao serviço de concessão do tíquete, o servidor AD LDS emitiria uma resposta de associação e a enviaria de volta à estação de trabalho, declarando que as credenciais eram inválidas.

Eis uma recapitulação do que acontece na troca bem-sucedida:

1. A estação de trabalho envia uma solicitação de associação ao servidor AD LDS.
2. O servidor AD LDS estabelece uma conexão com o DC.
3. O servidor AD LDS solicita que o DC traduza o SID de Lucy em um identificador que possa ser usado para autenticação.
4. O DC fornece ao servidor AD LDS o ID de Lucy.
5. O servidor AD LDS obtém do DC um TGT (tíquete de concessão de tíquete) com o ID de Lucy.
6. O servidor AD LDS obtém um tíquete de sessão usando o TGT de Lucy.
7. O servidor AD LDS envia uma resposta de associação bem-sucedida à estação de trabalho.

Esse processo mostra que a conexão da estação de trabalho com o servidor AD LDS é uma transação de associação LDAP padrão. Então, do servidor AD LDS para o DC, o Kerberos é usado para autenticar o usuário com segurança.

Configurando um laboratório de autenticação de proxy

Agora que você já sabe como funciona a autenticação de proxy, vejamos como fazer essa configuração em um ambiente de laboratório. Observe que, para esse exercício, vou desabilitar o requisito de SSL na autenticação de proxy. Mas, como já mencionei, lembre-se de que você nunca deve desabilitar esse requisito em uma implementação real.

Antes de começar, você precisará de um domínio totalmente funcional com um servidor membro do Windows Server 2008 e uma estação de trabalho associado a ele. O servidor membro do Windows Server 2008 executará o AD LDS, e a estação de trabalho será o ponto de extremidade do cliente. A vantagem de separar esses computadores é que você poderá obter capturas de rede da interação entre eles. Para configurar o laboratório, descreverei as seguintes etapas:

• Instalar o AD LDS no servidor membro.
• Desabilitar o requisito de SSL para a autenticação de proxy.
• Importar a classe userProxy para o esquema do AD LDS.
• Criar o objeto proxy e atribuir permissões a ele.
• Fazer a associação ao diretório do AD LDS com o objeto proxy.

A primeira etapa consiste em instalar o AD LDS no servidor membro do Windows Server 2008. No Gerenciador do Servidor, você encontrará a opção para instalar o LDS no Assistente para Adicionar Funções. Depois que a função for instalada, uma nova opção aparecerá no menu Ferramentas Administrativas, chamada Assistente de Instalação dos Serviços AD LDS. Use esse assistente para criar uma nova instância do LDS.

Quando for solicitado que você informe o nome da partição do aplicativo, digite o DN que preferir. Lembre-se de que o LDS oferece suporte à nomenclatura X.500. Então, você não está limitado a usar um nome no estilo "DC=". Nos meus exemplos, usei "cn=appdir,dc=contoso,dc=com", mas também poderia ter usado "cn=appdir,o=contoso,c=us".

Depois que a instância do AD LDS for instalada, a etapa seguinte é desabilitar o requisito de SSL para a autenticação de proxy. No snap-in ADSI Edit (adsiedit.msc), você deve conectar-se à partição de configuração da instância do AD LDS usando a conta de administrador especificada durante a instalação. Se não souber o DN da partição de configuração, você poderá escolher "Configuração" na lista suspensa "Selecione um contexto de nomenclatura bem conhecido", na caixa de diálogo de configurações de conexão no ADSI Edit.

Navegue até o contêiner "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={guid}" e abra a caixa de diálogo de propriedades do contêiner "CN=Directory Service". Há na lista de atributos um atributo de cadeia de caracteres com vários valores, chamado msDS-Other-Settings, que lista várias cadeias de caracteres, cada qual indicando uma configuração diferente para a instância do AD LDS. Edite esse atributo e altere a cadeia de caracteres "RequireSecureProxyBind" para o valor 0.

A etapa seguinte consiste em importar a definição de classe do esquema para a classe userProxy. Talvez você já tenha feito essa importação quando solicitado no assistente do AD LDS. Em caso positivo, pule essa etapa. Se você ainda não fez a importação, use o comando LDIFDE.EXE a seguir. Certifique-se de especificar no comando o nome do servidor AD LDS e a porta correta:

C:\> ldifde –i -f c:\windows\adam\ms-userproxy.ldf –s
   server:port –k –j . –c 
   "cn=schema,cn=configuration,dc=X"
   #schemaNamingContext

Agora que a classe de objeto foi importada, o objeto proxy pode ser criado. Utilizarei LDP.EXE, mas você poderia usar outra ferramenta ou um método programático. Usando o LDP, conecte-se à sua instância do AD LDS e associe-se com suas credenciais de administrador. Navegue até o DN da sua instância do AD LDS e escolha o contêiner onde deseja criar o objeto proxy. Clique com o botão direito do mouse no contêiner e escolha Adicionar Filho na lista suspensa. Na caixa de diálogo Adicionar, você precisará digitar o DN do novo objeto proxy no campo DN. Você pode usar, por exemplo, "cn=lucy,cn=appdir,o=contoso,c=us".

Você também precisará criar dois atributos com esse objeto. O primeiro é objectClass, que indica o tipo de objeto criado. O valor, para este exemplo, deve ser userProxy. Coloque essas informações na seção Editar Entrada da caixa de diálogo e clique no botão Inserir.

O segundo atributo a ser adicionado é objectSID, que contém o SID da conta de usuário do Active Directory à qual o objeto proxy está associado. É possível obter esse SID usando diversos métodos, mas eu simplesmente me conectei ao Active Directory em uma instância separada do LDP e copiei o atributo objectSID da conta de usuário existente ali. Depois que você inserir essas informações, a caixa de diálogo Adicionar deverá ter aparência semelhante à da Figura 9. Por fim, clique no botão Executar para confirmar a alteração.

Figura 9 Criando um objeto proxy

Para usar o objeto proxy que você acaba de criar, será preciso atribuir a ele algumas permissões. Você pode fazer isso facilmente, selecionando o objeto "CN=Readers" no contêiner "CN=Roles", no LDP. Clique com o botão direito do mouse e escolha Modificar na lista suspensa. Adicione um atributo chamado member e, como valor, digite o DN do objeto userProxy criado por você. Lembre-se de clicar no botão Inserir antes de clicar em Executar. Agora, o objeto userProxy deve ser membro do grupo Readers, na instância do LDS.

Tudo já deve estar configurado para que você possa testar a autenticação de proxy. Abra uma nova instância do LDP e conecte-se ao servidor AD LDS. Só que, desta vez, quando se associar à sua instância, selecione Associação Simples e digite o DN do objeto proxy no campo de nome de usuário. Digite a senha da conta do Active Directory à qual você vinculou o objeto proxy. Clique em OK. Agora, você deve estar associado à instância em modo somente leitura.

Dedique algum tempo a obter rastreamentos de rede e experimentar métodos de associação diferentes. Pode ser um exercício interessante reativar o SSL e, então, obter uma captura do processo de associação LDAP. Você pode até mesmo digitar intencionalmente um nome de usuário ou uma senha incorreta para ver o que acontece com o processo de autenticação.

Conclusão

Não se assuste com a dificuldade de usar a autenticação de proxy. Escolhi a abordagem de demonstrar esse processo com o LDP e o ADSI Edit por proporcionar uma visão melhor dos bastidores. Por isso, o exemplo descrito aqui ilustra a autenticação de proxy a partir de uma perspectiva muito pouco automatizada.

Na prática, o processo demorado de criar e manipular objetos userProxy é geralmente codificado com um sistema de gerenciamento de identidade ou um front-end desenvolvido de forma personalizada para a criação de contas. Recomendo que você crie seu próprio laboratório do LDS e confira como é possível usar a autenticação de proxy para integrar diretórios e aplicativos de terceiros.

Ken St. Cyr é consultor da Microsoft. Ele projeta e implementa soluções para diretórios com base no Active Directory desde sua criação. Tornou-se recentemente um dos primeiros a obter a certificação Microsoft Certified Master para Serviços de Diretório. Entre em contato com ele pelo email ken.stcyr@microsoft.com.