it-swarm.com.de

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

Für das neue SPN-Format ist keine Portnummer erforderlich. 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

Das scheint zu widersprechen dieses ältere (2011) MS-Dokument , 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. Sie müssen jedoch einen SPN sowohl für den NetBIOS-Namen als auch für 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

Sogar MS-eigener Kerberos-Konfigurationsmanager scheint die letzten beiden Versionen (mit entsprechender Verschleierung) generieren zu wollen:

(enter image description here

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 in meiner Umgebung nur TCP?)

Soll ich den Port einschließen oder nicht? Oder eins mit dem Port und eins ohne?

Verwenden Sie nur den vollqualifizierten Domänennamen oder benötige ich nur Einträge 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 über TCP, Named Pipes sind im Konfigurationsmanager deaktiviert. Wir werden diese manuell reparieren/erstellen, anstatt Ermöglichen, dass das SQL-Dienstkonto sie beim Serverstart erstellt.)

8
BradC

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 richtig heraus und sagt, welches Format für welches Protokoll erforderlich ist, aber er leitet sich ab von (vielen Tests in meiner Umgebung) und dem folgenden MS-Artikel-Sentance :

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

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 in dieser Angelegenheit herausgenommen, sollten Formate wie folgt aussehen:

(enter image description here

Die Quellenangabe von MS finden Sie hier .

Nun zum 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 Ryan Reis's Blog , hat aber einige leichte Verbesserungen, so dass keine Überzuschüsse durchgeführt 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 Domain ADSI Edit (adsiedit über den Befehl Eingabeaufforderung)
  2. Klicken Sie mit der rechten Maustaste auf ADSI Edit -> Connect to ...
  3. Verbindung zu Standard-Namenskontext
  4. Navigieren Sie zu/Create the OU containermit den Dienstkonten, denen Sie SPN-Rechte gewähren möchten
  5. Klicken Sie mit der rechten Maustaste aufin der Organisationseinheit -> Eigenschaften
  6. Klicken Sie auf die Registerkarte Sicherheit
  7. Klicken Sie auf die Schaltfläche Erweitert
  8. Markieren Sie [~ # ~] self [~ # ~]und klicken Sie auf Bearbeiten ... oder wenn das [~ # ~] self [~ # ~]special user wird nicht in der Liste der Gruppen- oder Benutzernamen angezeigt. Klicken Sie auf Add ... und geben Sie ein. [~ # ~] self [~ # ~]für den Objektnamen
  9. Klicken Sie auf die Registerkarte Eigenschaften
  10. Wählen Sie Descendant User-Objekteaus der Dropdown-Liste neben Anwenden auf: Hinweis: Dies ist die geringfügige Anpassung der in Ryans Blog-Beitrag beschriebenen Schritte aus den Gründen, die in diesem Abschnitt besser erläutert werden ServerFault/StackExchange post.
  11. Aktivieren Sie das Kontrollkästchen Zulassenneben dem folgenden:
    • Lesen Sie servicePrincipalName
    • Schreibe servicePrincipalName
  12. Klicken Sie auf Ok(im Fenster zur Eingabe der Berechtigungen).
  13. Klicken Sie auf Ok(im Fenster Erweiterte Sicherheitseinstellungen).
  14. Klicken Sie auf Ok(im Fenster mit den Eigenschaften der Organisationseinheit).
  15. Fügen Sie der Organisationseinheit Dienstkonten Ausführen von SQL Server-Diensten hinzu
  16. (Optional) Starten Sie SQL Server Servicesneu, das unter diesen Konten ausgeführt wird.
  17. Genieße 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 ...

5
John Eisbrener

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 einen statischen Port anstelle des dynamischen Standardports.

1
Bob Klimes