Qualquer diferença entre DOMAIN \ username e [email protected]?

Question

Estou tentando solucionar um erro de autenticação obscuro e preciso de algumas informações básicas.

• Existe alguma diferença entre como o Windows (e programas como o Outlook) processam DOMAIN\username e [email protected] ?

• Quais são os termos apropriados para esses dois formatos de nome de usuário?

• Editar : Em particular, há alguma diferença na forma como o Windows autentica os dois formatos de nome de usuário?

Answer 1

Supondo que você tenha um ambiente do Active Directory:

Acredito que o formato de barra invertida DOMAIN \ USERNAME pesquisará o domínio DOMAIN para um objeto de usuário cujo nome da conta SAM seja USERNAME.

O formato username do UPN @ domain pesquisará na floresta por um objeto de usuário cujo Nome do Princípio do Usuário seja username @ domain.

Agora, normalmente uma conta de usuário com uma conta SAM O nome de USERNAME tem um UPN de USERNAME @ DOMAIN, portanto, o formato deve localizar a mesma conta, pelo menos desde que o AD esteja totalmente funcional. Se houver problemas de replicação ou você não puder acessar um catálogo global, o formato de barra invertida poderá funcionar nos casos em que o formato UPN falhará. Também pode haver condições (anormais) sob as quais o contrário se aplica - talvez se nenhum controlador de domínio puder ser alcançado para o domínio de destino, por exemplo.

No entanto, você também pode configurar explicitamente uma conta de usuário para ter um UPN cujo componente de nome de usuário seja diferente do nome da conta SAM e cujo componente de domínio seja diferente do nome do domínio.

A guia Conta em Usuários e Computadores do Active Directory mostra o UPN sob o título "Nome de logon do usuário" e o nome da conta SAM sob o título "Nome de logon do usuário (anterior ao Windows 2000)". Então, se você está tendo problemas com usuários específicos, eu verifico que não há discrepâncias entre esses dois valores.

Observação: é possível que pesquisas adicionais sejam feitas se a pesquisa descrita acima não encontrar a conta do usuário. Por exemplo, talvez o nome de usuário especificado seja convertido no outro formato (da maneira óbvia) para ver se isso produz uma correspondência. Também deve haver algum procedimento para localizar contas em domínios confiáveis que não estão na floresta. Eu não sei onde / se o comportamento exato está documentado.

Apenas para complicar ainda mais a solução de problemas, os clientes Windows irão, por padrão, armazenar em cache informações sobre logons interativos bem-sucedidos, para que você possa efetuar login no mesmo cliente mesmo que as informações da conta do usuário no Active Directory estejam inacessíveis.

    

Answer 2

Eu posso ser corrigido, mas não há muita diferença.

Domínio \ Usuário é o formato de logon "antigo", chamado nome de logon de baixo nível . Também conhecido pelos nomes SAMAccountName e nome de logon anterior ao Windows 2000 .

[email protected] é um UPN - nome principal do usuário . É o formato de logon mais "preferido". É um nome de login no estilo da Internet, que deve ser mapeado para o nome do usuário. ( Ref. em MSDN )

As razões para fazer login com UPNs são principalmente cosméticas - elas hipoteticamente fornecem aos usuários em sua empresa um único nome para fazer logon em suas estações de trabalho, o que também pode funcionar como endereço de e-mail corporativo.

edit: Mais elaboração - outra vantagem dos UPNs é que você pode configurar mais de um UPN válido para os usuários fazerem logon. Mais uma vez, em grande parte cosmética. Mas o importante é que nem todos os aplicativos são compatíveis com UPNs, e isso pode ser o que você está enfrentando.

edit # 2: Eu gosto da resposta de Harry Johnston abaixo sobre os dois formatos de pesquisa ligeiramente diferentes executados. Faz sentido e, o mais importante, pode realmente explicar o seu problema. :)

    

Answer 3

O formato de barra ( DOMAIN\username ) é, na verdade, o NetBIOS equivalente do nome DNS do domínio ( domain.mycompany.local ).
O nome NetBIOS está limitado a 15 caracteres e não pode conter pontos, sublinhados, etc.

Esta página explica com mais detalhes:
* Jeff Schertz, 2012-08-20, Entendendo os formatos de nomeação do Active Directory (Arquivado aqui .)

Como mencionado por @ harry-johnston acima, é realmente apenas o antigo formato compatível com NT4 e Windows 2000, mas parece ter ficado como um formato favorito (é menos para digitar!). Eventualmente, o suporte para o formato legado pode ir do Windows.

Provavelmente, é uma boa idéia levar os usuários ao hábito de usar o formato UPN, pois evita problemas em que eles estão tendo problemas para fazer login em um PC com seu nome de usuário e não percebem que a caixa de login do Windows entrou em default. para o domínio local do PC (por exemplo, pc01\fred ) ou quando eles se conectam a diferentes hosts da área de trabalho remota e precisam lembrar de incluir o domínio e seu nome de usuário porque o Cliente da Área de Trabalho Remota pode armazenar em cache outro nome de domínio usado anteriormente. Aderir ao formato UPN toda vez só faz menos chamadas de suporte no final.

    

Answer 4

Existe uma diferença entre esses dois, apenas 99% dos usuários não terão problemas com isso. Vou tentar explicar a diferença e quando tal problema pode ocorrer.

Se você usar domínio \ nome de usuário quando tentar acessar um compartilhamento de arquivos, o DNS primeiro resolverá o domínio e, em seguida, verificará o nome de usuário. Se você usar username @ domain, ele verificará diretamente se o usuário está na ACL (lista de controle de acesso) e tem acesso. Então, o que importa você pode pensar ... bem, imagine isso:

1 controlador de domínio com nome DC01 e todos os clientes recebem dns e estão nesse domínio. Você deseja migrar e alguém adicionou outro servidor com o mesmo nome. O último servidor também se tornará um controlador de domínio, portanto, o SAM local não será mais usado e também terá um compartilhamento de arquivos.

Quando os usuários se conectam ao servidor, eles são solicitados a fornecer credenciais. Se você usar domínio \ nome de usuário, ele verificará primeiro o domínio atual em vez de usar o novo domínio e usamos as contas do novo domínio no compartilhamento de arquivos. Então, uma vez que tenha encontrado o dc atual e verifique o nome de usuário, ele não pode ser encontrado. (mesmo se o nome de usuário e a senha forem encontrados e forem exatamente os mesmos, não funcionarão, pois não usarão o nome de usuário para verificar se é permitido na ACL, mas usarão o SID. O sid será criado no tempo de criação de usuário no AD e você tem uma mudança de 1 em um trilhão que é o mesmo, ótimo hein :-P).