Cross Domain SQL Server-aanmeldingen met Windows-verificatie

Zoals vermeld in mijn vraagupdate, het wijzigen van het serviceaccount naar Domain2 het probleem opgelost. Dus wat was er aan de hand?

Het probleem - uitgelegd

Voor zover ik kan zien (ook met hulp van een Microsoft-vertegenwoordiger), omdat het serviceaccount oorspronkelijk een Domain1 was gebruiker, kan het niet bepalen van welke lokale domeingroepen de verbindende gebruiker lid is wanneer de gebruiker authenticeert via Kerberos. De belangrijkste aanwijzing dat dit een Kerberos-probleem was, was toen ik met succes verbinding maakte met "Named Pipes" omdat dit NTLM-authenticatie gebruikt.

Algemene oplossing

Om het allemaal samen te brengen, om met succes gebruikers toe te voegen van Domain1 en Domain3 als leden van groepen in Domain2 zodat de groepen kunnen worden gebruikt als SQL Server-aanmeldingen met Windows-authenticatie, hier is een lijst met vereisten (of op zijn minst sterk aangemoedigd):

1. Gevestigde vertrouwensrelaties tussen de domeinen
   1. Er moeten minimaal 1-way trusts worden ingesteld zodat Domain2 vertrouwt Domain1 en Domain3
2. Groepen in Domain2 moet het bereik "Domein Lokaal" hebben
   1. Dit is zodat u gebruikers en groepen kunt toevoegen vanuit Domain1 en Domain3
   2. Zie hier voor meer info
3. Gebruik SQL Server Configuration Manager om een ​​niet-administratief Domain2 aan te wijzen gebruiker als de identiteit van het serviceaccount
   1. MSDN documenteert waarom het gebruik van een domeingebruikersaccount de voorkeur kan hebben
   2. Hoewel het de bedoeling is dat de configuratiemanager gebruikers toevoegt aan lokale SQL Server 2005-specifieke groepen voor u (d.w.z. SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), kwam ik een paar gevallen tegen waarin dit niet het geval was. Controleer dus uw lokale groepen om er zeker van te zijn dat ze correct zijn bijgewerkt met uw Domain2 gebruikersaccount.
   3. Hoewel het instellen van SQL Server automatisch de juiste machtigingen voor hun lokale groepen zou moeten toewijzen, kwam ik opnieuw een paar gevallen tegen waarin dit niet het geval was. Als dit je overkomt, kun je dit MSDN-artikel samen met het eerder genoemde artikel raadplegen voor toestemmingsvereisten.
4. Configureer een Service Principal Name (SPN) voor de SQL Server instance-host (inclusief eventuele aliassen) en de Domain2 serviceaccount
   1. De SPN is vereist voor wederzijdse authenticatie tussen de client en de serverhost
   2. Zie dit TechNet-artikel voor meer info
5. Afhankelijk van hoe u imitatie wilt gebruiken, kunt u de Domain2 inschakelen te vertrouwen serviceaccount voor delegatie
   1. Zie dit TechNet-artikel voor meer info
6. Externe verbindingen inschakelen voor de SQL Service-instantie
7. Maak ten slotte aanmeldingen voor het gewenste Domain2 groepen en elk Domain1 of Domain3 leden moeten op afstand verbinding kunnen maken!

Opmerking

Zoals altijd bij elke externe netwerkactiviteit, controleert u uw firewalls om er zeker van te zijn dat uw SQL Server-poorten niet worden geblokkeerd. Hoewel de standaardpoort 1433 is, moet u controleren of uw poort vrij is.