How to authenticate a user from an external Windows Domain (Active Directory)

Question

I have a service (AcmeService) running on a domain (ACME.COM) and a user running in another domain (DISNEY.COM).

mickey@disney.com wants to authenticate with the AcmeService. The service knows about the DISNEY.COM domain and it imported all the user in its local user database with LDAP by using a known credential of DISNEY.COM.

If mickey sends his fully qualified username/password, AcmeService can authenticate him using LDAP by connecting directly to the DISNEY.COM domain controller (which he already knows).

scrooge@disney.com 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. (In my scenario it is using .Net NegotiateStream which is a wrapper around SSPI)

My understanding of this problem is that AcmeService cannot authenticate with integrated security a user that is not part of his domain (ACME.COM).

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.

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? It is ok if the solution works only on the AcmeService machine.

I might be mistaken, but I am under the impression that it would be possible to do such a thing with an external MIT Kerberos by using ksetup /addkdc.

Any idea?

Thanks

UPDATE

The communication between the client and AcmeService is already secured with TLS (without mutual authentication). After the connection is complete, the client knows he's talking with the real AcmeService (thanks to TLS), but he now needs to authenticate his identity to the AcmeService using his DISNEY.COM credentials, a client certificate here is not an option, the AcmeService only knows about ActiveDirectory accounts that it previously imported.

NTLM (v2) would be good enough for my scenario, but I don't see why Kerberos would not be possible. AcmeService has a DISNEY.COM account (acmeuser@disney.com) it can use to mutually authenticate with Kerberos.

I think the problem is that while trying to authenticate a disney.com user with SSPI, AcmeService is unable to locate the domain controller automatically for the DISNEY.COM domain. The AcmeService machine needs to know that the DISNEY.COM controller can be located at "dc.disney.com".

Here is the results of dcdiag and nltest ran on the AcmeService machine:

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

What I need is a magic command like "register-domain /domain:DISNEY.COM /controller:dc.disney.com", as I said previously, it's ok if only the AcmeService is able to authenticate DISNEY.COM users, the solution doesn't need to work with everyone in the ACME.COM domain.

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?

No.

If you are constrained to working with the .NET NegotiateStream class, then you will see in the MSDN documentation for the NegotiateStream class, [MS-NNS]:

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

So your choices are NTLM and Kerberos.

scrooge@disney.com 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.

Well then NTLM is out. NTLM v1, v2, and v2 with Session Security all rely on weak hashing algorithms, and furthermore the hashes of the password are essentially password-equivalent, so I agree with you that using NTLM to authenticate to a service is to give one's password away to that service.

So now you're left only with Kerberos. And Kerberos as it's implemented by Active Directory is not going to authenticate credentials for an untrusted domain.

So now you have no choices left.

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.

You are right that creating a trust would allow one Kerberos realm to trust the authentication mechanism of another Kerberos realm, but since you cannot create a trust, then you are SOL.

When you want to provide strong, mutual authentication between a client and a server and you cannot use Kerberos, then you use PKI, digital certificates, TLS.

I would normally suggest that you explore AD Federation Services, but chances are if you cannot create a traditional AD trust relationship for whatever reason, then you won't be able to create a Federation trust either.

So my suggestion is client certificates. (Schannel)