Come dovrebbero essere le mie voci SPN per ogni istanza SQL?

Sto trovando informazioni contraddittorie su come formattare esattamente SPN (Service Principle Names) per ottenere le connessioni Kerberos corrette e quante ne ho bisogno per ogni istanza SQL.

Questo documento MS 2017 contiene quanto segue:

A partire da SQL Server 2008, il formato SPN viene modificato per supportare l'autenticazione Kerberos su TCP / IP, named pipe e memoria condivisa. I formati SPN supportati per le istanze denominate e predefinite sono i seguenti.

Istanza denominata: MSSQLSvc/FQDN:[port|instancename]

Istanza predefinita: MSSQLSvc/FQDN:port|MSSQLSvc/FQDN

Il nuovo formato SPN non richiede un numero di porta . Ciò significa che un server a più porte o un protocollo che non utilizza numeri di porta possono utilizzare l'autenticazione Kerberos.

Ho preso quest'ultimo paragrafo per indicare che ho bisogno di una sola voce, una delle seguenti:

Istanza denominata: MSSQLSvc/sqlbox1.mydomain.org/instance2
Istanza predefinita: MSSQLSvc/sqlbox1.mydomain.org

Ciò sembra contraddire questo vecchio documento MS (2011) , non solo sul numero di porta, ma anche su quale nome usare:

Per creare il nome SPN, è possibile utilizzare il nome NetBIOS o il nome di dominio completo (FQDN) di SQL Server. Tuttavia, è necessario creare un nome SPN sia per il nome NetBIOS che per il nome FQDN .

Quando guardo gli SPN già esistenti nel mio ambiente, vedo una grande varietà di combinazioni, alcuni server hanno fino a 4 voci:

MSSQLSvc/sqlbox1
MSSQLSvc/sqlbox1:1433
MSSQLSvc/sqlbox1.mydomain.org
MSSQLSvc/sqlbox1.mydomain.org:1433

Persino il gestore della configurazione Kerberos di MS sembra voler generare le ultime due versioni (con la relativa offuscamento):

Allo stesso modo per le istanze nominate esistenti, vedo uno strano mix, alcuni dei quali quasi certamente non validi:

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

Quindi, come dovrebbero essere i miei DSN in realtà, sia per le istanze predefinite che per quelle nominate, se uso TCP nel mio ambiente?

Devo includere la porta o no? O includerne uno con la porta e uno senza?

Utilizzare solo il nome FQDN o sono necessarie le voci con solo il nome Netbios? O sarebbe solo se stessimo usando named pipe (cosa che non siamo)?

(Per il contesto, eseguiamo SQL 2005 fino al 2014, alcuni in cluster, altri autonomi. La connettività è solo tramite TCP, named pipe è disabilitata in Config Manager. Ripareremo / creeremo questi manualmente invece di consentire all'account del servizio SQL di crearli su avvio del server.)

sql-server kerberos spn

— BradC
fonte

Qualche motivo particolare per cui vuoi gestire tu stesso gli SPN piuttosto che lasciare che SQL (e il suo account di servizio) lo facciano per te?

— Nic

per quanto riguarda gli SPN, se funziona, importa quale sia il formato? Secondo commento di @Nic

— Bob Klimes il

@Nic Poiché ciò richiederebbe la concessione a diverse dozzine di account di servizio di nuovi diritti di Active Directory, il nostro amministratore di Active Directory ha affermato che l'aggiunta manuale di una volta è più facile da gestire. Inoltre, sono stati trovati alcuni collegamenti che dicono che possono accadere cose divertenti quando gli SPN tentano di sincronizzarsi tra più controller di dominio quando vengono aggiunti / rimossi in modo dinamico all'avvio / arresto / failover del cluster. Detto questo, mi permetta di chiederle questo: quando si esegue consentire l'account di servizio per aggiungere l'SPN all'avvio, che cosa assomiglia? Una singola voce con FQDN e porta? O senza porto? O due voci?

— BradC,

@BobKlimes Bene, alcuni di loro non funzionano, questo è il problema. Immagino che non ci sia nulla di male nell'avere più voci del necessario, ma sto solo cercando di capire quali svolgono effettivamente il lavoro.

— BradC,

@BradC Sicuramente ho avuto problemi con il failover del cluster e più controller di dominio. Quelli erano i miei unici SPN creati manualmente.

— Bob Klimes,

Risposte:

Se si utilizza solo TCP / IP per connettersi alle istanze, sono necessarie solo le porte specificate. I nomi delle istanze vengono utilizzati durante la connessione alle istanze SQL tramite i protocolli Named Pipes. Purtroppo l'articolo di MS non viene subito detto quale formato è richiesto per quale protocollo, ma è derivato da (molti test nel mio ambiente) e la seguente frase di articolo MS :

Per le pipe con nome e le connessioni di memoria condivisa, un nome SPN nel formato MSSQLSvc / FQDN: nome istanza viene utilizzato per un'istanza denominata e MSSQLSvc / FQDN viene utilizzato per l'istanza predefinita.

Per quanto riguarda i nomi di dominio completi vs i nomi NETBIOS, consiglierò i nomi di dominio completi in quanto non sono inclini a problemi se si verificano problemi casuali con il server DNS.

Tratto dal mio post sul blog sull'argomento, i formati dovrebbero apparire come segue:

Il riferimento di origine da MS può essere trovato qui .

Ora per rendere il tuo Network Admin's Day (ad es. La configurazione dell'unità organizzativa che consente gli SPN con registrazione automatica)

L'amministratore di rete può creare un'unità organizzativa sul dominio che contiene tutti gli account del servizio SQL Server che possono essere configurati in modo tale che l'account del servizio possa creare un SPN per sé e per sé. Il metodo segue principalmente il blog di Ryan Reis , ma presenta alcune lievi modifiche in modo da non eseguire sovvenzioni eccessive.

Questo processo descrive la creazione di un'unità organizzativa nel dominio che consente agli account al suo interno di autoregistrare i propri nomi SPN:

Come account con diritti elevati sul dominio, apri ADSI Edit (adsiedit dal prompt dei comandi)
Fare clic con il tasto destro del mouse su Modifica ADSI -> Connetti a ...
Connetti al contesto di denominazione predefinito
Passare a / Creare il contenitore OU contenente gli account di servizio a cui si desidera concedere i diritti SPN
Fare clic con il tasto destro del mouse su OU -> Proprietà
Fai clic sulla scheda Sicurezza
Fai clic sul pulsante Avanzate
Evidenzia SELF e fai clic su Modifica ... o se l' utente speciale SELF non viene visualizzato nell'elenco dei nomi di gruppo o utente, fai clic su Aggiungi ... e inserisci SELF per il nome dell'oggetto
Fai clic sulla scheda Proprietà
Seleziona Oggetti utente discendente dall'elenco a discesa accanto a Applica a: Nota: questa è la leggera modifica ai passaggi descritti nel post del blog di Ryan per i motivi meglio descritti da questo post ServerFault / StackExchange .
Seleziona la casella Consenti accanto a quanto segue:
- Leggi servicePrincipalName
- Scrivi servicePrincipalName
Fai clic su OK (nella finestra di immissione delle autorizzazioni)
Fai clic su OK (nella finestra Impostazioni di sicurezza avanzate)
Fai clic su OK (nella finestra delle proprietà dell'unità organizzativa)
Aggiungere account di servizio che eseguono servizi SQL Server all'unità organizzativa
(Facoltativamente) Riavvia i servizi di SQL Server in esecuzione con detti account
Goditi gli ossequi

Dopo aver seguito i passaggi precedenti, il contenitore OU in questione è ora configurato in modo tale che qualsiasi account aggiunto ad esso sia in grado di registrare ed eliminare SPN per sé e per sé. Questa è esattamente la giusta quantità di autorizzazioni poiché questi account non saranno in grado di calpestare gli SPN registrati da altri account.

Lo scopo di riavviare SQL Server nel passaggio 16 è garantire che gli SPN siano registrati come previsto. SQL tenterà di rimuovere tutti gli SPN registrati all'arresto e di aggiungerli all'avvio, quindi il riavvio è realmente necessario solo se attualmente non esistono SPN per detto servizio SQL Server.

La nota finale di questo approccio è che se si esegue SQL Server in una configurazione FCI (Failover Clustered Instance) tradizionale, NON è consigliabile aggiungere l'account del servizio di questa istanza a questa unità organizzativa, per KB 2443457 .

Ho davvero bisogno di pubblicare la parte 2 della mia serie Kerberos ...

— John Eisbrener
fonte

Non è Discendant User Objects , è Descendant Computer Objects .

— Isaac Kleiman,

Quando il servizio SQL Server crea SPN, ne crea due per ogni istanza. Questo è il formato che utilizza.

Istanza predefinita:

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

Istanza denominata:

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

Per le istanze denominate, se si creano manualmente SPN, sarà necessario disporre di una porta statica anziché della porta dinamica predefinita.

— Bob Klimes
fonte