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):
- Etablierte Vertrauensbeziehungen zwischen den Domänen
- Es müssen mindestens 1-Weg-Vertrauensstellungen eingerichtet werden, damit
Domain2
vertrautDomain1
undDomain3
- Es müssen mindestens 1-Weg-Vertrauensstellungen eingerichtet werden, damit
- Gruppen in
Domain2
muss "Domain Local" sein- Auf diese Weise können Sie Benutzer und Gruppen aus
Domain1
hinzufügen undDomain3
- Weitere Informationen finden Sie hier
- Auf diese Weise können Sie Benutzer und Gruppen aus
- Verwenden Sie den SQL Server-Konfigurations-Manager, um eine nicht administrative
Domain2
festzulegen user als Dienstkontoidentität- MSDN dokumentiert, warum die Verwendung eines Domänenbenutzerkontos bevorzugt werden kann
- 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. - 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.
- Konfigurieren Sie einen Dienstprinzipalnamen (SPN) für den Host der SQL Server-Instanz (einschließlich aller Aliase) und
Domain2
Dienstkonto- Der SPN ist für die gegenseitige Authentifizierung zwischen dem Client und dem Serverhost erforderlich
- Weitere Informationen finden Sie in diesem TechNet-Artikel
- 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- Weitere Informationen finden Sie in diesem TechNet-Artikel
- Aktivieren Sie Remote-Verbindungen für die SQL-Dienstinstanz
- Erstellen Sie zum Schluss Logins für die gewünschte
Domain2
Gruppen und alleDomain1
oderDomain3
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.