Cross Domain SQL Server Logins Using Windows Authentication

Question

I have a SQL Server 2005 named instance using Windows Authentication with domain groups serving as logins. The domain structures are as follows:

      Forest         


        

Answer 1

As mentioned in my question update, changing the service account to be in Domain2 resolved the issue. So what was going on?

The Problem - Explained

From what I can tell (also with help from a Microsoft representative), because the service account was originally a Domain1 user, it could not determine what domain local groups the connecting user is a member of when the user is authenticating via Kerberos. The primary lead that this was a Kerberos issue was when I successfully connected using "Named Pipes" as this uses NTLM authentication.

Overall Solution

To bring it all together, to successfully add users from Domain1 and Domain3 as members of groups in Domain2 so that the groups can be used as SQL Server logins with Windows authentication, here's a list of requirements (or at least strongly encouraged):

1. Established trust relationships between the domains
   1. At a minimum, 1 way trusts must be set up so that Domain2 trusts Domain1 and Domain3
2. Groups in Domain2 must be scoped "Domain Local"
   1. This is so you can add users and groups from Domain1 and Domain3
   2. See here for more info
3. Use SQL Server Configuration Manager to designate a non-administrative Domain2 user as the service account identity
   1. MSDN documents why using a domain user account may be preferred
   2. Even though the configuration manager is supposed to add users to local SQL Server 2005 specific groups for you (i.e. SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), I ran into a few instances where this wasn't the case. So just check your local groups to ensure they've been updated appropriately with your Domain2 user account.
   3. Although SQL Server set up should automatically assign appropriate permissions for their local groups, again, I ran into a few instances where this was not the case. If this happens to you, you can reference this MSDN article along with the previously mentioned article for permission requirements.
4. Configure a Service Principal Name (SPN) for the SQL Server instance host (including any aliases) and the Domain2 service account
   1. The SPN is required for mutual authentication between the client and the server host
   2. See this TechNet article for more info
5. Depending on how you intend to use impersonation, you may want to enable the Domain2 service account to be trusted for delegation
   1. See this TechNet article for more info
6. Enable remote connections for the SQL Service instance
7. Finally, create logins for desired Domain2 groups and any Domain1 or Domain3 members should be able to connect remotely!

Note

As always with any remote network activity, check your firewalls to ensure your SQL Server ports are not blocked. Although the default port is 1433, check to make sure your port is in the clear.

Answer 2

Ok, I met the issue as well in 2017, hard to find any solution, finally, I figure it out only for my case.

My environment,

Forest 1 (Domain1) --- TRUST --- Forest 2(Domain2)

I have a service account in Domain2 trying to log in SQL server in Domain1 by using Windows Authentication.

And, following error message pops up.

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. (Microsoft SQL Server, Error: 18452)

The solution is simple enough, on domain1, open active directory domains and trusts tool,

Trusts -> outgoing trusts -> properties -> authentication -> change to "Forest-wide authentication"

My problem solved.