Ich finde widersprüchliche Informationen darüber, wie SPNs (Service Principle Names) genau formatiert werden müssen, um die richtigen Kerberos-Verbindungen zu erhalten, und wie viele ich für jede SQL-Instanz benötige.
Dieses MS-Dokument 2017 enthält Folgendes:
Ab SQL Server 2008 wird das SPN-Format geändert, um die Kerberos-Authentifizierung unter TCP / IP, Named Pipes und Shared Memory zu unterstützen. Die unterstützten SPN-Formate für benannte und Standardinstanzen lauten wie folgt.
- Benannte Instanz:
MSSQLSvc/FQDN:[port|instancename]- Standardinstanz:
MSSQLSvc/FQDN:port|MSSQLSvc/FQDNDas neue SPN-Format erfordert keine Portnummer . Dies bedeutet, dass ein Server mit mehreren Ports oder ein Protokoll, das keine Portnummern verwendet, die Kerberos-Authentifizierung verwenden kann.
Ich habe diesen letzten Absatz so verstanden, dass ich nur einen einzigen Eintrag benötige, einen der folgenden:
- Benannte Instanz:
MSSQLSvc/sqlbox1.mydomain.org/instance2 - Standardinstanz:
MSSQLSvc/sqlbox1.mydomain.org
Dies scheint diesem älteren (2011) MS-Dokument zu widersprechen , nicht nur in Bezug auf die Portnummer, sondern auch in Bezug auf den zu verwendenden Namen:
Zum Erstellen des SPN können Sie den NetBIOS-Namen oder den vollqualifizierten Domänennamen (FQDN) des SQL Servers verwenden. Allerdings müssen Sie ein SPN sowohl für den NetBIOS - Namen und den FQDN erstellen .
Wenn ich mir die SPNs ansehe, die bereits in meiner Umgebung vorhanden sind, sehe ich eine Vielzahl von Kombinationen. Einige Server haben bis zu 4 Einträge:
MSSQLSvc/sqlbox1MSSQLSvc/sqlbox1:1433MSSQLSvc/sqlbox1.mydomain.orgMSSQLSvc/sqlbox1.mydomain.org:1433
Selbst der Kerberos-Konfigurationsmanager von MS scheint die letzten beiden Versionen (mit entsprechender Verschleierung) generieren zu wollen:
In ähnlicher Weise sehe ich für vorhandene benannte Instanzen eine seltsame Mischung, von denen einige mit ziemlicher Sicherheit ungültig sind:
MSSQLSvc/sqlbox1:1522MSSQLSvc/sqlbox1:instance2MSSQLSvc/sqlbox1.mydomain.org:1522MSSQLSvc/sqlbox1.mydomain.org:instance2MSSQLSvc/sqlbox1.mydomain.org/instance2MSSQLSvc/sqlbox1.mydomain.org:1522:instance2
Wie sollten meine DSNs sowohl für Standardinstanzen als auch für benannte Instanzen aussehen, wenn ich nur TCP in meiner Umgebung verwende?
Soll ich den Port einschließen oder nicht? Oder eins mit und eins ohne Port?
Verwenden Sie nur den vollqualifizierten Domänennamen oder benötige ich die Einträge nur mit dem Netbios-Namen? Oder wäre das nur, wenn wir Named Pipes verwenden würden (was wir nicht sind)?
(Für den Kontext führen wir SQL 2005 bis 2014 aus, einige gruppiert, andere eigenständig. Die Konnektivität erfolgt nur über TCP, Named Pipes sind im Konfigurationsmanager deaktiviert. Wir werden diese manuell reparieren / erstellen, anstatt dem SQL-Dienstkonto zu erlauben, sie zu erstellen Serverstart.)
quelle
Antworten:
Wenn Sie nur TCP / IP verwenden, um eine Verbindung zu Ihren Instanzen herzustellen, benötigen Sie nur die angegebenen Ports. Die Instanznamen werden verwendet, wenn über die Named Pipes-Protokolle eine Verbindung zu den SQL-Instanzen hergestellt wird. Leider kommt der MS-Artikel nicht direkt heraus, welches Format für welches Protokoll erforderlich ist, sondern er leitet sich aus (vielen Tests in meiner Umgebung) und der folgenden MS-Artikelempfindung ab :
In Bezug auf FQDNs und NETBIOS-Namen empfehle ich FQDNs, da diese nicht so anfällig für Probleme sind, wenn Sie auf zufällige DNS-Serverprobleme stoßen.
Aus meinem Blog-Beitrag zu diesem Thema entnommen, sollten die Formate wie folgt aussehen:
Die Quellenangabe von MS finden Sie hier .
Machen Sie jetzt den Tag Ihres Netzwerkadministrators (z. B. OU-Konfiguration, die selbstregistrierende SPNs ermöglicht)
Ihr Netzwerkadministrator kann eine Organisationseinheit in der Domäne erstellen, die alle Ihre SQL Server-Dienstkonten enthält, die so konfiguriert werden können, dass das Dienstkonto einen SPN für sich selbst und für sich selbst erstellen kann. Die Methode folgt hauptsächlich dem Blog von Ryan Reis , weist jedoch einige geringfügige Änderungen auf, sodass keine Überzuschüsse vorgenommen werden.
Dieser Prozess beschreibt die Erstellung einer Organisationseinheit in der Domäne, mit der Konten in der Domäne ihre eigenen SPNs selbst registrieren können:
Nachdem Sie die obigen Schritte ausgeführt haben, wird der betreffende OU-Container jetzt so konfiguriert, dass jedes hinzugefügte Konto SPNs für sich und sich selbst registrieren und löschen kann. Dies ist genau die richtige Anzahl von Berechtigungen, da diese Konten SPNs, die von anderen Konten registriert wurden, nicht mit Füßen treten können.
Der Zweck des Neustarts von SQL Server in Schritt 16 besteht darin, sicherzustellen, dass die SPNs wie erwartet registriert sind. SQL versucht, alle registrierten SPNs beim Herunterfahren zu entfernen und beim Start hinzuzufügen. Daher ist der Neustart nur dann wirklich erforderlich, wenn für diesen SQL Server-Dienst derzeit keine SPNs vorhanden sind.
Der letzte Hinweis zu diesem Ansatz lautet: Wenn Sie SQL Server in einer herkömmlichen FCI-Konfiguration (Failover Clustered Instance) ausführen, wird NICHT empfohlen, das Dienstkonto dieser Instanz gemäß KB 2443457 zu dieser Organisationseinheit hinzuzufügen .
Ich muss wirklich Teil 2 meiner Kerberos-Serie posten ...
quelle
Wenn der SQL Server-Dienst SPN erstellt, werden für jede Instanz zwei erstellt. Dies ist das verwendete Format.
Standardinstanz:
Benannte Instanz:
Wenn Sie für Ihre benannten Instanzen SPNs manuell erstellen, benötigen Sie anstelle des dynamischen Standardports einen statischen Port.
quelle