Qual campo usar ao se autenticar no Active Directory?

Os objetos de usuário do Active Directory incluem vários campos que podem ser considerados um identificador. A seguir, são listadas algumas delas com o rótulo no ADUC e o nome do atributo:

• Nome completo - cn
• ? - nome
• Usuário sAMAccountName de logon - sAMAccountName
• Logon UPN do usuário: userPrincipalName
• ? - Nome Distinto

Estou tentando fazer com que nossos desenvolvedores padronizem o uso de apenas um deles ao escrever um código personalizado que se autentica no AD - o problema é que não tenho certeza de qual é o "certo" ou se os diferentes são o certo em diferentes circunstâncias. Não tenho certeza se algum dos campos acima deve ser usado!

Alguém mais escolheu um para usar de forma consistente, e o que influenciou você nessa decisão? Alguma documentação que esclarece o problema?

Um CN (nome comum) não é bom para fazer login, porque um CN sozinho não identifica exclusivamente um usuário. Eu poderia ter um

CN=Ryan Ries,OU=Dallas,DC=Domain,DC=com

e eu também poderia ter um

CN=Ryan Ries,OU=New York,DC=Domain,DC=com

O CN de um usuário também é um RDN (nome distinto relativo.) Eles têm o mesmo CN, mas DNs diferentes. Você pode perceber que se depara com problemas se tiver duas pessoas em sua organização chamada Ryan Ries e precisará criar o SamAccountName para o segundo como algo semelhante rries2.

Um DN (nome distinto) não é bom para fazer login, porque quem deseja fazer login em um sistema com um nome de usuário como CN=ryan,OU=Texas,DC=brazzers,DC=com? Embora o uso de um DN identifique um usuário de maneira exclusiva e definitiva, é irritante ter que digitar. É o mesmo tipo de conceito entre caminhos relativos e caminhos absolutos em um sistema de arquivos. Isso também implica que você sabe exatamente onde na estrutura de diretórios o objeto está localizado sem precisar procurá-lo. O que você frequentemente não faz.

Isso é chamado de Resolução de nomes ambíguos (ANR) - procurando no diretório por um usuário quando você não possui seu nome distinto.

O UPN (nome principal do usuário) é muito bom porque eles se parecem com endereços de e-mail, podem ser iguais ao endereço de e-mail corporativo do usuário, são fáceis de lembrar e preferem fazer login porque o nome será pesquisado primeiro no domínio local, antes de procurá-lo na floresta.

A Microsoft diz: O objetivo do UPN é consolidar os espaços de nome de email e logon para que o usuário precise se lembrar apenas de um único nome. O UPN é o nome de logon preferido para usuários do Windows. Os usuários devem estar usando seus UPNs para fazer logon no domínio. No momento do logon, um UPN é validado primeiro pesquisando o domínio local e depois o catálogo global. A falha em encontrar o UPN no domínio local ou no GC resulta na rejeição do UPN. O UPN pode ser atribuído, mas não é necessário , quando a conta do usuário é criada.

Lembre-se de que "não é necessário" no final ao projetar seus aplicativos.

SamAccountName também é bom porque SamAccountName precisa ser exclusivo para todos no domínio (mas não para a floresta.) Além disso, SamAccountNames são curtos. A maioria das pessoas efetua login com SamAccountNames, mesmo que não o identifique exclusivamente em uma floresta do AD, e é por isso que você precisa especificar um nome de domínio para acompanhar seu SamAccountName, para que o sistema saiba em qual domínio você está tentando efetuar login. .

Aqui está uma excelente documentação sobre o assunto para leituras adicionais:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms677605(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/windows/desktop/ms680857(v=vs.85).aspx

Se você estiver se referindo ao nome de usuário como algo que alguém digitaria para fazer login, eu recomendaria um sAMAccountName, que seria único em combinação com um nome de domínio ou ouserPrincipalName , que seria único em uma floresta.

No que diz respeito ao nome de usuário como identificador exclusivo, o Windows usa o SID para todas as entradas de controle de acesso e fornece um conjunto completo de métodos para converter para SIDs a partir de nomes de usuário. Os SIDs correspondem à metáfora do usuário durante a vida útil de uma conta, pois renomear e mover dentro de um domínio não têm efeito, mas excluir e recriar resultados em um novo SID.

Para esse fim, eu chamaria LookupAccountName, que pega uma string que representa o nome de usuário e retorna o sAMAccountName, oSID e o nome de domínio do domínio que o usuário foi encontrado em.

O usuário pode usar qualquer sintaxe suportada pelo Windows para efetuar login e nenhum treinamento adicional é necessário.

Eu recomendo permitir que o usuário escolha o formato do nome que ele deseja usar e determine a entrada do usuário no lado do aplicativo. por exemplo: Se o usuário digitar: nomedeusuário@domínio.com - considere-o como UPN e procure por UPN no AD. Se o usuário digitar: nome de usuário - considere samAccountName para um domínio padrão predefinido e, claro, se o usuário digitar domínio \ nome de usuário - considere samAccountName no domínio especificado. Sempre recupere o SID do usuário e atribua todas as permissões ao SID porque as pessoas se casam e o nome do usuário pode mudar.