none
Verbindungsserver mit delegation funktioniert nicht RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    wir haben ein Problem beim Einrichten eines Verbindungsservers mit Deligierung.

    Umgebung:

     Domänencontroller: TEST-DC1  (Windows Server 2008 R2 SP1)
 SQL Server1:       TEST-SQL1 (Windows Server 2008 R2 SP1 & SQL Server 2008 R2 SP1)
 SQL Server2:       TEST-SQL2 (Windows Server 2008 R2 SP1 & SQL Server 2012 SP1)
 SQL Server3:       TEST-SQL3 (Windows Server 2008 R2 SP1 & SQL Server 2012 SP1)
    Das SQL Server-Dienstkonto ist auf allen drei SQL Servern TEST\SQL.


    Ein Verbindungsserver von TEST-SQL2 nach TEST-SQL1 konnte ohne Probleme eingerichtet werden, von TEST-SQL3 nach TEST-SQL1 jedoch nicht.

    Für TEST-SQL2, sowie TEST-SQL3 wurden die SPNs gesetzt:

     setspn -A MSSQLSvc/TEST-SQL2.test.local:1433 TEST\SQL
 setspn -A MSSQLSvc/TEST-SQL2:1433 TEST\SQL
 setspn -A MSSQLSvc/TEST-SQL3.test.local:1433 TEST\SQL
 setspn -A MSSQLSvc/TEST-SQL3:1433 TEST\SQL

    Die Server TEST-SQL2 und TEST-SQL3 sind identisch konfiguriert worden, trotzdem bekommen wir folgende Fehlermeldung:

    Wenn wir den Server TEST-SQL3 zu TEST-SQL4 umbennen, setspn ausführen und den Verbindungsserver einrichten, funktioniert dies ohne Probleme. Den Servernamen auf TEST-SQL4 zu belassen ist keine Option.

    Wir haben den Server TEST-SQL3 schon neu installiert. Dies brachte auch keine Besserung.

    Wo können wir weiter ansetzen um den Fehler einzugrenzen / zu finden?

    Vielen Dank

    Mittwoch, 12. Juni 2013 13:19
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Phil,

    evtl. ist noch eine Registrierung für TEST-SQL3 im AD versteckt.

    Bei Manually Registering SPNs wird beschrieben, dass man SetSPN -S einem SetSPN -A vorziehen sollte, oder aber über SetSPN -L prüfen ob es etwas störendes gibt.

    Gruß Elmar

    • Als Antwort markiert Phil Gramzow Mittwoch, 12. Juni 2013 14:20
    Mittwoch, 12. Juni 2013 13:49
    |

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo Phil,

    evtl. ist noch eine Registrierung für TEST-SQL3 im AD versteckt.

    Bei Manually Registering SPNs wird beschrieben, dass man SetSPN -S einem SetSPN -A vorziehen sollte, oder aber über SetSPN -L prüfen ob es etwas störendes gibt.

    Gruß Elmar

    • Als Antwort markiert Phil Gramzow Mittwoch, 12. Juni 2013 14:20
    Mittwoch, 12. Juni 2013 13:49
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Elmar,

    mit setspn -L TEST\SQL haben wir bereits geprüft, ob es etwas störendes gibt. Das sieht jedoch nicht danach aus:

     Registrierte Dienstprinzipalnamen (SPN) für CN=SQL,OU=Dienstkonten,OU=testfirma,DC=test,DC=local:
         MSSQLSvc/TEST-SQL1:1433
         MSSQLSvc/TEST-SQL1.TEST.local:1433
         MSSQLSvc/TEST-SQL2:1433
         MSSQLSvc/TEST-SQL2.TEST.local:1433
         MSSQLSvc/TEST-SQL3:1433
         MSSQLSvc/TEST-SQL3.TEST.local:1433

    Gruß

    Phil

    Mittwoch, 12. Juni 2013 14:01
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Phil,

    finden sich Einträge - im obigen Artikel sind einige aufgeführt - im Ereignisprotokoll des Domänen-Controllers, die Aufschluss über den Fehler geben ?

    Gruß Elmar

    Mittwoch, 12. Juni 2013 14:09
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Elmar,

    das Problem hat sich gerade erledigt.

    Es war ein doppelter SPN vorhanden, den wir über setspn -L nicht sehen konnten.

    setspn -Q MSSQLSvc/TEST-SQL3.test.local:1433 hat den Eintrag gezeigt. Diesen haben wir gelöscht und konnten den "richtigen" SPN erfolgreich anlegen.

    Der Verbindungsserver funktioniert jetzt.

    Vielen Dank für den Tipp mit setspn -S !

    Gruß

    Phil

    Mittwoch, 12. Juni 2013 14:19
    |