Wie sollten meine SPN-Einträge für jede SQL-Instanz aussehen?

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/FQDN

Das 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/sqlbox1
• MSSQLSvc/sqlbox1:1433
• MSSQLSvc/sqlbox1.mydomain.org
• MSSQLSvc/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:1522
• MSSQLSvc/sqlbox1:instance2
• MSSQLSvc/sqlbox1.mydomain.org:1522
• MSSQLSvc/sqlbox1.mydomain.org:instance2
• MSSQLSvc/sqlbox1.mydomain.org/instance2
• MSSQLSvc/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.)

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 :

Für Named Pipes und Shared - Memory - Verbindungen, ein SPN im Format MSSQLSvc / FQDN: instancename wird für eine benannte Instanz und verwendet MSSQLSvc / FQDN wird für die Standardinstanz verwendet.

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:

1. Öffnen Sie als Konto mit erhöhten Rechten für die Domäne ADSI Edit (adsiedit über die Eingabeaufforderung).
2. Klicken Sie mit der rechten Maustaste auf ADSI-Bearbeitung -> Verbinden mit ...
3. Stellen Sie eine Verbindung zum Standard-Namenskontext her
4. Navigieren Sie zu / Erstellen Sie den OU-Container mit den Dienstkonten, denen Sie SPN-Rechte gewähren möchten
5. Klicken Sie mit der rechten Maustaste auf die Organisationseinheit -> Eigenschaften
6. Klicken Sie auf die Registerkarte Sicherheit
7. Klicken Sie auf die Schaltfläche Erweitert
8. Markieren Sie SELBST und klicken Sie auf Bearbeiten ... oder wenn der spezielle SELBST- Benutzer nicht in der Liste der Gruppen- oder Benutzernamen angezeigt wird, klicken Sie auf Hinzufügen ... und geben Sie SELBST als Objektnamen ein
9. Klicken Sie auf die Registerkarte Eigenschaften
10. Wählen Sie Nachkommenobjekte aus der Dropdown-Liste neben Anwenden auf aus: Hinweis: Dies ist die geringfügige Anpassung der in Ryans Blogbeitrag beschriebenen Schritte aus den in diesem ServerFault / StackExchange- Beitrag besser beschriebenen Gründen .
11. Aktivieren Sie das Kontrollkästchen Zulassen neben den folgenden:
    • Lesen Sie servicePrincipalName
    • Schreiben Sie servicePrincipalName
12. Klicken Sie auf Ok (auf Berechtigungen Eingabefenster)
13. Klicken Sie auf Ok (auf Advanced Security setings Fenstern)
14. Klicken Sie auf OK (im OU-Eigenschaftenfenster).
15. Fügen Sie der Organisationseinheit Dienstkonten hinzu, auf denen SQL Server-Dienste ausgeführt werden
16. (Optional) Starten Sie SQL Server Services neu, die unter diesen Konten ausgeführt werden.
17. Genießen Sie Leckereien

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 ...

Wenn der SQL Server-Dienst SPN erstellt, werden für jede Instanz zwei erstellt. Dies ist das verwendete Format.

Standardinstanz:

MSSQLSvc/servername.domain.com
MSSQLSvc/servername.domain.com:1433

Benannte Instanz:

MSSQLSvc/servername.domain.com:54321
MSSQLSvc/servername.domain.com:instancename

Wenn Sie für Ihre benannten Instanzen SPNs manuell erstellen, benötigen Sie anstelle des dynamischen Standardports einen statischen Port.