Como autenticar um usuário de um domínio externo do Windows (Active Directory)

Question

Eu tenho um serviço (AcmeService) rodando em um domínio (ACME.COM) e um usuário rodando em outro domínio (DISNEY.COM).

[email protected] quer autenticar com o AcmeService. O serviço sabe sobre o domínio DISNEY.COM e importou todo o usuário em seu banco de dados de usuários local com LDAP usando uma credencial conhecida de DISNEY.COM.

Se a mickey enviar seu nome de usuário / senha totalmente qualificado, o AcmeService poderá autenticá-lo usando o LDAP conectando-se diretamente ao controlador de domínio DISNEY.COM (que ele já conhece).

[email protected] também quer se autenticar com o AcmeService, mas quer autenticar com segurança integrada porque ele não confia no AcmeService o suficiente para dar sua senha. (No meu cenário está usando .Net NegotiateStream que é um wrapper em torno do SSPI)

Meu entendimento desse problema é que o AcmeService não pode autenticar com segurança integrada um usuário que não faz parte de seu domínio (ACME.COM).

Acho que a solução geral seria criar uma relação de confiança de saída entre o ACME.COM e o DISNEY.COM, mas isso não é possível no meu cenário.

Existe uma solução para permitir que o AcmeService autentique um usuário com SSPI se esse usuário estiver em um domínio externo e não houver relação de confiança definida? Está tudo bem se a solução funcionar apenas na máquina AcmeService.

Eu posso estar enganado, mas tenho a impressão de que seria possível fazer uma coisa dessas com um MIT Kerberos externo usando o ksetup / addkdc.

Alguma ideia?

Obrigado

UPDATE

A comunicação entre o cliente e o AcmeService já está garantida com o TLS (sem autenticação mútua). Após a conclusão da conexão, o cliente sabe que está falando com o verdadeiro AcmeService (graças ao TLS), mas agora precisa autenticar sua identidade para o AcmeService usando suas credenciais DISNEY.COM, um certificado de cliente aqui não é uma opção, o AcmeService só sabe sobre as contas do ActiveDirectory que ele importou anteriormente.

O NTLM (v2) seria bom o suficiente para o meu cenário, mas não vejo por que o Kerberos não seria possível. O AcmeService tem uma conta DISNEY.COM ([email protected]) que pode ser usada para autenticar-se mutuamente com o Kerberos.

Acho que o problema é que, ao tentar autenticar um usuário disney.com com SSPI, o AcmeService não consegue localizar o controlador de domínio automaticamente para o domínio DISNEY.COM. A máquina AcmeService precisa saber que o controlador DISNEY.COM pode estar localizado em "dc.disney.com".

Aqui estão os resultados de dcdiag e nltest executados na máquina AcmeService:

dcdiag /s:dc.disney.com /u:disney.com\acmeuser/p: XXXX / test: LocatorCheck

   Running enterprise tests on : disney.com
      Starting test: LocatorCheck
         Warning: DcGetDcName(GC_SERVER_REQUIRED) call failed, error 1722
         A Global Catalog Server could not be located - All GC's are down.
         Warning: DcGetDcName(PDC_REQUIRED) call failed, error 1722
         A Primary Domain Controller could not be located.
         The server holding the PDC role is down.
         Warning: DcGetDcName(TIME_SERVER) call failed, error 1722
         A Time Server could not be located.
         The server holding the PDC role is down.
         Warning: DcGetDcName(GOOD_TIME_SERVER_PREFERRED) call failed, error 1722
         A Good Time Server could not be located.
         Warning: DcGetDcName(KDC_REQUIRED) call failed, error 1722
         A KDC could not be located - All the KDCs are down.
         ......................... disney.com failed test LocatorCheck

nltest /dsgetdc:disney.com

Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

O que eu preciso é de um comando mágico como "register-domain / domain: DISNEY.COM /controller:dc.disney.com", como eu disse anteriormente, tudo bem se apenas o AcmeService conseguir autenticar usuários DISNEY.COM , a solução não precisa funcionar com todos no domínio ACME.COM.

    

Answer 1

Is there a solution to allow AcmeService to authenticate a user with SSPI if that user is in an external domain and there is no defined trust relationship?

Não.

Se estiver restrito a trabalhar com a classe .NET NegotiateStream, você verá na documentação do MSDN a classe NegotiateStream, [MS-NNS] :

The .NET NegotiateStream Protocol uses SPNEGO (which selects between Kerberos and NTLM) to determine the underlying security protocol to use.

Então, suas escolhas são NTLM e Kerberos.

[email protected] wants to authenticate too with AcmeService, but wants to authenticate with integrated security because he doesn't trust AcmeService enough to give away [his] password.

Bem, então o NTLM está fora. O NTLM v1, v2 e v2 com Segurança de Sessão dependem de algoritmos hash fracos e, além disso, os hashes da senha são essencialmente equivalentes a senha, portanto, concordo com você que usar o NTLM para autenticar um serviço é dar uma senha para esse serviço.

Então agora você é deixado apenas com o Kerberos. E o Kerberos, como implementado pelo Active Directory, não autenticará as credenciais de um domínio não confiável.

Então agora você não tem mais opções.

I think the general solution would be to create an outgoing trust relationship between ACME.COM and DISNEY.COM, but it is not possible in my scenario.

Você está certo de que a criação de uma confiança permitiria que um domínio Kerberos confie no mecanismo de autenticação de outro território Kerberos, mas, como você não pode criar uma confiança, você é SOL.

Quando você deseja fornecer autenticação strong e mútua entre um cliente e um servidor e não pode usar o Kerberos, use PKI, certificados digitais, TLS.

Normalmente, sugiro que você explore os Serviços de Federação do AD, mas provavelmente não será possível criar uma relação de confiança tradicional do AD por qualquer motivo, então você não poderá criar uma confiança de Federação.

Então, minha sugestão é de certificados de cliente. (Schannel)