SPN für SQL-Server setzen

[speer 19]

Hallo zusammen,
in der Microsoft Doku HIER unter SPN Formats steht geschrieben, wie man den SPN anlegt. Wie sieht die Syntax für eine TCP Verbindung zu einer Instanz mit Port 1433 aus?

So sieht die Syntax aus: MSSQLSvc/<FQDN>:[<port> | <instancename>]

Kappiere nicht was es mit dem "|" auf sich hat :(

[NilsK 2.930]

Moin,

 

ob die Syntax dann so passt, kann ich jetzt nicht sagen, aber das Pipe-Zeichen steht für "oder". Du gibst also entweder den Port an, auf dem die jeweilige Instanz lauscht, oder deren Instanznamen.

 

Gruß, Nils

 

[speer 19]

Hm, gebe ich anstatt dem Port den Instanzname ein, wird mittels TCP nur NTLM verwendet. Die Named-Pipes allerdings über Kerberos. Verwende ich die Default-Instanz plus Port, funktioniert wird die Kerberos Authentifizierung verwendet.

Die Syntax habe ich direkt von der Microsoft Seite kopiert. Leider erfordert der Application Server dringend als Protokoll TCP und auch die Kerberos Authentifizierung wegen der Delegierung.

Hm, werde mal weiter Recherchieren.

[daabm 1.348]

Was heißt "mittels TCP"? Gehst Du dann über den Hostname oder über die IP?

[zahni 550]

Ich meine, dass der SQL den richtigen SPN selber setzt, wenn man ihn einmalig mit einem Domain-Admin startet.

Danach kann man das Service-Konto wieder zurückändern.

Das stand auch mal irgendwann in der Doku oder irgendeinem Blog von MS.

Update: Da hat gerade etwas geklingelt. MS hat zur Kerberos-Config ein Tool geschrieben:

 

https://www.microsoft.com/en-us/download/details.aspx?id=39046&WT.mc_id=soc-n-[TR]-loc-[Services]-[farukc]

bearbeitet 17. November 2019 von zahni

[Dukel 451]

Oder man baut den Setspn Befehl in seinem SQL Server Deployment Script ein. Dann hat man alles sauber und nachvollziehbar :)

[speer 19]

Ich gehe über den FQDN, über IP wäre NTLM Authentifizierung normal. Möchte eigentlich nur wissen wie man den SPN bei einer weiteren Instanz verwendet, die TCP und nicht die Named Pipes verwendet, anlegt. Bei der Default-Instanz wird Kerberos verwendet, bei der Named-Instanz aber NTLM. Bei NTLM funktioniert aber der Application Server davor nicht weil dieser für die Delegierung ein Domänen-Konto und kein SQL Konto benötigt.

Werde morgen mal in der Testumgebung das MS SQL Tool runterladen und schauen, wie dieses den SPN anlegt.

@zahni, Danke für den Link :)

 

@Dukel,

sinnvoll ja, sinnfrei aber weil ich die korrekte Syntax nicht kenne.

[Dukel 451]

Wie wäre es für jede Instanz einen eigenen SPN.

 

MSSQLSvc/<FQDN> bzw. MSSQLSvc/<FQDN>:1433 für die Default Instanz

MSSQLSvc/<FQDN>:<instancename> für die Named Instanz.

 

Mehrere Instanzen möchte man aber eigentlich nicht.

[zahni 550]

Ich würde auch nie mehr als eine Instanz auf einer VM installieren. Der Mehrwert von mehr als einer Instanz erschließt sich mir nicht.

Zumal man dann beispielsweise den RAM-Bedarf der  beiden Instanzen exakt konfigurieren muss. 

[speer 19]

Hallo zusammen,

die Lösung war ganz einfach. Jede Named Instance greift mittels dynamic ports zu. Das managed der SQL Client Browser problemlos. Da ich allerdings eine 2-Tier Umgebung habe, funktioniert das nicht mehr. Lösung ist, die zweite Instanz einen anderen Port zuweisen und den SPN auf diesen Port setzen. Danach verwendet TCP auch die Kerberos Authentifizeriung. Eleganter wäre den SQL-Server über ein MSA Konto zu starten. Dieses darf den SPN "von Haus aus" im AD selbst aktualisieren. Somit aktualisiert sich der SPN bei jedem SQL Server neustart selbst. Vermutlich müssten dann Named-Instance nicht mehr auf einem statischen Port laufen. Das habe ich aber aus mangels an MSA Konten nicht getestet. Nur eine Vermutung.

 

Wir brauchen die Named Instance weil die Collation für den SQL Server festgeschrieben ist. Auch die ist organisatorische Zuordnung der SQL Server sehr wahrscheinlich anders als bei vielen Firmen. Das zu erläutern würde aber den Rahmen hier sprengen :)

 

@Dukel

mittels MSSQLSvc/<FQDN>:<instancename> legt man den SPN für alle Protokolle, außer TCP fest!