Cross Domain SQL Server-login ved hjælp af Windows-godkendelse

Som nævnt i min spørgsmålsopdatering ændrer du tjenestekontoen til at være i Domain2 løst problemet. Så hvad foregik der?

Problemet – forklaret

Efter hvad jeg kan se (også med hjælp fra en Microsoft-repræsentant), fordi tjenestekontoen oprindeligt var et Domain1 bruger, kunne den ikke bestemme, hvilke lokale domænegrupper den forbindende bruger er medlem af, når brugeren godkender via Kerberos. Den primære ledning til, at dette var et Kerberos-problem, var, da jeg oprettede forbindelse ved hjælp af "Named Pipes", da dette bruger NTLM-godkendelse.

Samlet løsning

For at bringe det hele sammen, at tilføje brugere fra Domain1 og Domain3 som medlemmer af grupper i Domain2 så grupperne kan bruges som SQL Server-login med Windows-godkendelse, er her en liste over krav (eller i det mindste stærkt opfordret):

1. Etablerede tillidsforhold mellem domænerne
   1. Mindst 1-vejs-trusts skal konfigureres, så Domain2 har tillid til Domain1 og Domain3
2. Grupper i Domain2 skal have omfanget "Lokalt domæne"
   1. Dette er, så du kan tilføje brugere og grupper fra Domain1 og Domain3
   2. Se her for mere information
3. Brug SQL Server Configuration Manager til at udpege en ikke-administrativ Domain2 bruger som tjenestekontoidentitet
   1. MSDN dokumenterer, hvorfor det kan være at foretrække at bruge en domænebrugerkonto
   2. Selvom det er meningen, at konfigurationsmanageren skal tilføje brugere til lokale SQL Server 2005-specifikke grupper for dig (dvs. SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), stødte jeg på nogle få tilfælde, hvor dette ikke var tilfældet. Så tjek bare dine lokale grupper for at sikre, at de er blevet opdateret korrekt med dit Domain2 brugerkonto.
   3. Selvom SQL Server-konfigurationen automatisk skulle tildele passende tilladelser til deres lokale grupper, stødte jeg igen på et par tilfælde, hvor dette ikke var tilfældet. Hvis dette sker for dig, kan du henvise til denne MSDN-artikel sammen med den tidligere nævnte artikel for tilladelseskrav.
4. Konfigurer et Service Principal Name (SPN) for SQL Server-instansværten (inklusive eventuelle aliaser) og Domain2 servicekonto
   1. SPN er påkrævet for gensidig godkendelse mellem klienten og serverværten
   2. Se denne TechNet-artikel for mere information
5. Afhængigt af hvordan du har tænkt dig at bruge personefterligning, vil du måske aktivere Domain2 servicekonto, der skal have tillid til delegering
   1. Se denne TechNet-artikel for mere information
6. Aktiver fjernforbindelser for SQL Service-instansen
7. Til sidst skal du oprette logins for det ønskede Domain2 grupper og enhver Domain1 eller Domain3 medlemmer skal kunne oprette forbindelse eksternt!

Bemærk

Som altid med enhver ekstern netværksaktivitet, skal du kontrollere dine firewalls for at sikre, at dine SQL Server-porte ikke er blokeret. Selvom standardporten er 1433, skal du kontrollere, at din port er fri.