0

I have installed SQL Server on a server(lets say Server1) which is joined to a domain in AD(lets say domain01), and I have another server(lets say server2) which is joined to another domaim(lets say domain02).

There is not any trusted connection between domain01 and domain02.

Now I want to install Microsoft AzureDevops on server2, in Database page, when I enter the SQL Server instance I get the following error:

login failed in initializing the provider

What I suspect, is the lack of trusted connection between domains(I am not sure). If I am true, is there any solution to solve this problem, without making both domains trust eachother?

I have tested the connection using udl file too, and got the same result for windows authentication method, however using SQL Server authetication, udl test connection is ok, but this option is not suitable for me.

Vahid Farahmandian
  • 101
  • 3

1 Answers1

1

I've maintained an environment of SQL servers in multiple domains. I used to be able to get things to work without a domain trust, but with newer versions (of SQL, or the underlying OS, or both -- I never got a solid answer) I haven't been able to make it work.

Back in the 2000/2003/2008 era, I was able to use Windows authentication to use an account from Domain A to connect to a SQL instance in Domain B, even with no domain trust in place, as long as the username and password were the same in both domains.

Somewhere along the way, that stopped working. Even if the usernames and password matched, authentication would fail. We ended up having to revamp a lot of our architecture so that we could get the SQL instances in the same domain as the clients applications.

Bottom line: Windows authentication between untrusted domains is not going to work. You'll need to do one of these things instead:

  • Get them in the same domain
  • Establish a domain trust
  • Use SQL authentication
Doug Deden
  • 1,796
  • 6
  • 10
  • In modern versions of Windows, authentication uses "tickets" issued via Kerberos from your Active Directory domain controller (after initial authorization), rather than constantly passing credentials across the network. Everyone needs to talk to the same AD domain to be able to validate those tickets. Passing credentials directly isn't done any longer because it's susceptible to various forms of password snooping and attacks. – AMtwo Nov 02 '20 at 09:25
  • Two great Twitter threads from the Microsoft PM working on Kerberos [here](https://twitter.com/SteveSyfuhs/status/1287931640929333249?s=19) and [here](https://twitter.com/SteveSyfuhs/status/1305934862591750145?s=19) – AMtwo Nov 02 '20 at 09:31