Sqlserver
 sql >> Datenbank >  >> RDS >> Sqlserver

Domänenübergreifende SQL Server-Anmeldungen mit Windows-Authentifizierung

Wie in meiner Frageaktualisierung erwähnt, ändern Sie das Dienstkonto in Domain2 hat das Problem gelöst. Was war also los?

Das Problem – erklärt

Soweit ich das beurteilen kann (auch mit Hilfe eines Microsoft-Vertreters), war das Dienstkonto ursprünglich ein Domain1 user, konnte nicht ermittelt werden, zu welchen lokalen Gruppen der Domäne der sich verbindende Benutzer gehört, wenn sich der Benutzer über Kerberos authentifiziert. Der primäre Hinweis darauf, dass dies ein Kerberos-Problem war, war, als ich erfolgreich eine Verbindung mit "Named Pipes" hergestellt habe, da dies die NTLM-Authentifizierung verwendet.

Gesamtlösung

Um alles zusammenzubringen, um erfolgreich Benutzer aus Domain1 hinzuzufügen und Domain3 als Mitglieder von Gruppen in Domain2 Damit die Gruppen als SQL Server-Logins mit Windows-Authentifizierung verwendet werden können, ist hier eine Liste der Anforderungen (oder zumindest dringend empfohlen):

  1. Etablierte Vertrauensbeziehungen zwischen den Domänen
    1. Es müssen mindestens 1-Weg-Vertrauensstellungen eingerichtet werden, damit Domain2 vertraut Domain1 und Domain3
  2. Gruppen in Domain2 muss "Domain Local" sein
    1. Auf diese Weise können Sie Benutzer und Gruppen aus Domain1 hinzufügen und Domain3
    2. Weitere Informationen finden Sie hier
  3. Verwenden Sie den SQL Server-Konfigurations-Manager, um eine nicht administrative Domain2 festzulegen user als Dienstkontoidentität
    1. MSDN dokumentiert, warum die Verwendung eines Domänenbenutzerkontos bevorzugt werden kann
    2. Obwohl der Konfigurationsmanager Benutzer zu lokalen SQL Server 2005-spezifischen Gruppen für Sie hinzufügen soll (z. B. SQLServer2005MSSQLUser$MY_MACHINE$MY_INSTANCE), bin ich auf einige Fälle gestoßen, in denen dies nicht der Fall war. Überprüfen Sie also einfach Ihre lokalen Gruppen, um sicherzustellen, dass sie entsprechend mit Ihrer Domain2 aktualisiert wurden Benutzerkonto.
    3. Obwohl die Einrichtung von SQL Server automatisch die entsprechenden Berechtigungen für ihre lokalen Gruppen zuweisen sollte, bin ich wiederum auf einige Fälle gestoßen, in denen dies nicht der Fall war. Wenn Ihnen dies passiert, können Sie diesen MSDN-Artikel zusammen mit dem zuvor erwähnten Artikel für die Berechtigungsanforderungen lesen.
  4. Konfigurieren Sie einen Dienstprinzipalnamen (SPN) für den Host der SQL Server-Instanz (einschließlich aller Aliase) und Domain2 Dienstkonto
    1. Der SPN ist für die gegenseitige Authentifizierung zwischen dem Client und dem Serverhost erforderlich
    2. Weitere Informationen finden Sie in diesem TechNet-Artikel
  5. Je nachdem, wie Sie den Identitätswechsel verwenden möchten, möchten Sie möglicherweise Domain2 aktivieren Dienstkonto, dem für die Delegierung vertraut werden soll
    1. Weitere Informationen finden Sie in diesem TechNet-Artikel
  6. Aktivieren Sie Remote-Verbindungen für die SQL-Dienstinstanz
  7. Erstellen Sie zum Schluss Logins für die gewünschte Domain2 Gruppen und alle Domain1 oder Domain3 Mitglieder sollten sich aus der Ferne verbinden können!

Hinweis

Überprüfen Sie wie immer bei jeder Remote-Netzwerkaktivität Ihre Firewalls, um sicherzustellen, dass Ihre SQL Server-Ports nicht blockiert sind. Obwohl der Standardport 1433 ist, überprüfen Sie, ob Ihr Port unverschlüsselt ist.