Cross Domain SQL Server-inloggningar med Windows-autentisering

Som nämnts i min frågeuppdatering, ändra tjänstekontot till att vara i Domain2 löste problemet. Så vad var på gång?

Problemet – förklarat

Vad jag kan säga (även med hjälp av en Microsoft-representant), eftersom tjänstekontot ursprungligen var en Domain1 användare kunde den inte avgöra vilken lokala domängrupper den anslutande användaren är medlem i när användaren autentiserar via Kerberos. Den primära ledningen att detta var ett Kerberos-problem var när jag lyckades ansluta med "Named Pipes" eftersom detta använder NTLM-autentisering.

Övergripande lösning

För att få ihop allt, för att framgångsrikt lägga till användare från Domain1 och Domain3 som medlemmar i grupper i Domain2 så att grupperna kan användas som SQL Server-inloggningar med Windows-autentisering, här är en lista med krav (eller åtminstone uppmuntras starkt):

1. Etablerade förtroenderelationer mellan domänerna
   1. Minst 1-vägs-förtroende måste ställas in så att Domain2 litar på Domain1 och Domain3
2. Grupper i Domain2 måste omfattas av "Domän lokal"
   1. Detta är så att du kan lägga till användare och grupper från Domain1 och Domain3
   2. Se här för mer information
3. Använd SQL Server Configuration Manager för att ange en icke-administrativ Domain2 användaren som tjänstkontoidentitet
   1. MSDN-dokument varför användning av ett domänanvändarkonto kan vara att föredra
   2. Även om konfigurationshanteraren ska lägga till användare till lokala SQL Server 2005-specifika grupper för dig (dvs SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), stötte jag på några fall där detta inte var fallet. Så kolla bara dina lokala grupper för att se till att de har uppdaterats på rätt sätt med din Domain2 användarkonto.
   3. Även om SQL Server-inställningarna automatiskt ska tilldela lämpliga behörigheter för sina lokala grupper, stötte jag återigen på några fall där detta inte var fallet. Om detta händer dig kan du referera till den här MSDN-artikeln tillsammans med den tidigare nämnda artikeln för behörighetskrav.
4. Konfigurera ett Service Principal Name (SPN) för SQL Server-instansvärden (inklusive eventuella alias) och Domain2 servicekonto
   1. SPN krävs för ömsesidig autentisering mellan klienten och servervärden
   2. Se denna TechNet-artikel för mer information
5. Beroende på hur du tänker använda identitetsstöld, kanske du vill aktivera Domain2 tjänstkonto som ska litas på för delegering
   1. Se denna TechNet-artikel för mer information
6. Aktivera fjärranslutningar för SQL Service-instansen
7. Skapa slutligen inloggningar för önskad Domain2 grupper och valfri Domain1 eller Domain3 medlemmar bör kunna ansluta på distans!

Obs

Som alltid med all fjärrnätverksaktivitet, kontrollera dina brandväggar för att säkerställa att dina SQL Server-portar inte är blockerade. Även om standardporten är 1433, kontrollera att din port är fri.