À quoi devraient ressembler mes entrées SPN pour chaque instance SQL?

Je trouve des informations contradictoires sur la façon de formater exactement les noms principaux de service (SPN) pour obtenir les connexions Kerberos appropriées et le nombre dont j'ai besoin pour chaque instance SQL.

Ce document MS 2017 contient les éléments suivants:

À partir de SQL Server 2008, le format SPN est modifié afin de prendre en charge l'authentification Kerberos sur TCP / IP, les canaux nommés et la mémoire partagée. Les formats SPN pris en charge pour les instances nommées et par défaut sont les suivants.

Instance nommée: MSSQLSvc/FQDN:[port|instancename]

Instance par défaut: MSSQLSvc/FQDN:port|MSSQLSvc/FQDN

Le nouveau format SPN ne nécessite pas de numéro de port . Cela signifie qu'un serveur à plusieurs ports ou un protocole qui n'utilise pas de numéros de port peut utiliser l'authentification Kerberos.

J'ai pris ce dernier paragraphe pour signifier que je n'ai besoin que d'une seule entrée, l'une des suivantes:

Instance nommée: MSSQLSvc/sqlbox1.mydomain.org/instance2
Instance par défaut: MSSQLSvc/sqlbox1.mydomain.org

Cela semble contredire cet ancien document MS (2011) , non seulement sur le numéro de port, mais aussi sur le nom à utiliser:

Pour créer le SPN, vous pouvez utiliser le nom NetBIOS ou le nom de domaine complet (FQDN) de SQL Server. Cependant, vous devez créer un SPN pour le nom NetBIOS et le FQDN .

Quand je regarde les SPN qui existent déjà dans mon environnement, je vois une grande variété de combinaisons, certains serveurs ont jusqu'à 4 entrées:

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

Même le propre gestionnaire de configuration Kerberos de MS semble vouloir générer les deux dernières versions (avec un obscurcissement approprié):

De même pour les instances nommées existantes, je vois un mélange étrange, certains d'entre eux presque certainement invalides:

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

Alors, à quoi devraient ressembler mes DSN, pour les instances par défaut et nommées, si j'utilise simplement TCP dans mon environnement?

Dois-je inclure le port ou non? Ou en inclure un avec le port et un sans?

Utilisez le FQDN uniquement ou ai-je besoin des entrées avec uniquement le nom Netbios? Ou serait-ce seulement si nous utilisions des tuyaux nommés (ce que nous ne sommes pas)?

(Pour le contexte, nous exécutons SQL 2005 à 2014, certains en cluster, d'autres en mode autonome. La connectivité est uniquement via TCP, les canaux nommés sont désactivés dans le gestionnaire de configuration. Nous allons les corriger / créer manuellement au lieu d'autoriser le compte de service SQL à les créer démarrage du serveur.)

sql-server kerberos spn

— BradC
source

Une raison particulière pour laquelle vous souhaitez gérer vous-même les SPN plutôt que de laisser SQL (et son compte de service) le faire pour vous?

— Nic

en ce qui concerne les SPN, si cela fonctionne, quel est le format? I second @Nic comment

— Bob Klimes

@Nic Parce que cela nécessiterait l'octroi à plusieurs dizaines de comptes de service de nouveaux droits Active Directory, notre administrateur Active Directory a déclaré qu'un ajout manuel ponctuel est plus facile à gérer. Nous avons également trouvé des liens indiquant que des choses amusantes peuvent se produire lorsque les SPN essaient de se synchroniser sur plusieurs contrôleurs de domaine lorsqu'ils sont ajoutés / supprimés dynamiquement lors du démarrage / arrêt / basculement de cluster. Cela dit, permettez - moi de demander ceci: quand vous faites permettre le compte de service pour ajouter le SPN au démarrage, qu'est-ce que ça ressemble? Une seule entrée avec FQDN et port? Ou sans port? Ou deux entrées?

— BradC

@BobKlimes Eh bien, certains d'entre eux ne fonctionnent pas, c'est le problème. Je suppose qu'il n'y a aucun mal à avoir plus d' entrées que nécessaire, mais juste à essayer de comprendre lesquelles font le travail.

— BradC

@BradC J'ai certainement eu des problèmes avec le basculement de cluster et plusieurs contrôleurs de domaine. Ce sont mes seuls SPN créés manuellement.

— Bob Klimes

Réponses:

Si vous utilisez uniquement TCP / IP pour vous connecter à vos instances, vous n'avez besoin que des ports spécifiés. Les noms d'instance sont utilisés lors de la connexion aux instances SQL via les protocoles Named Pipes. Malheureusement, l'article MS ne vient pas directement dire quel format est requis pour quel protocole, mais il est dérivé de (nombreux tests dans mon environnement) et de la phrase suivante de l' article MS :

Pour les canaux nommés et les connexions de mémoire partagée, un SPN au format MSSQLSvc / FQDN: nom_instance est utilisé pour une instance nommée et MSSQLSvc / FQDN est utilisé pour l'instance par défaut.

En ce qui concerne les noms de domaine complets par rapport aux noms NETBIOS, je recommanderai les noms de domaine complets car ils ne sont pas aussi sujets aux problèmes si vous rencontrez des problèmes de serveur DNS aléatoires.

Tiré de mon article de blog sur le sujet, les formats devraient ressembler à ceci:

La référence source de MS peut être trouvée ici .

Maintenant, faites de votre administrateur réseau (par exemple une configuration d'unité d'organisation qui autorise l'auto-enregistrement des SPN)

Votre administrateur réseau peut créer une unité d'organisation sur le domaine qui contient tous vos comptes de service SQL Server qui peuvent être configurés de telle manière que le compte de service puisse créer un SPN pour lui-même et lui-même. La méthode suit principalement le blog de Ryan Reis , mais a quelques légers ajustements afin que les sur-subventions ne soient pas effectuées.

Ce processus décrit la création d'une unité d'organisation sur le domaine qui permet aux comptes qu'il contient d'auto-enregistrer leurs propres SPN:

En tant que compte avec des droits élevés sur le domaine, ouvrez ADSI Edit (adsiedit à partir de l'invite de commande)
Cliquez avec le bouton droit sur ADSI Edit -> Connect to ...
Se connecter au contexte de nommage par défaut
Accédez à / Créez le conteneur OU contenant les comptes de service auxquels vous souhaitez accorder des droits SPN.
Faites un clic droit sur l'unité d'organisation -> Propriétés
Cliquez sur l' onglet Sécurité
Cliquez sur le bouton Avancé
Mettez en surbrillance SELF et cliquez sur Modifier ... ou si l' utilisateur spécial SELF n'apparaît pas dans la liste des noms de groupe ou d'utilisateur, cliquez sur Ajouter ... et entrez SELF pour le nom de l'objet
Cliquez sur l' onglet Propriétés
Sélectionnez Objets d'utilisateur descendant dans la liste déroulante à côté de Appliquer à: Remarque: Il s'agit du léger ajustement des étapes décrites dans le billet de blog de Ryan pour les raisons mieux décrites par ce message ServerFault / StackExchange .
Cochez la case Autoriser à côté des éléments suivants:
- Lire servicePrincipalName
- Service d'écriturePrincipalName
Cliquez sur OK (dans la fenêtre de saisie des autorisations)
Cliquez sur OK (dans la fenêtre Paramètres de sécurité avancés)
Cliquez sur OK (dans la fenêtre des propriétés de l'unité d'organisation)
Ajouter des comptes de service exécutant des services SQL Server à l'unité d'organisation
(Facultatif) Redémarrez les services SQL Server exécutés sous lesdits comptes
Profitez de friandises

Après avoir suivi les étapes ci-dessus, le conteneur OU en question est maintenant configuré de telle sorte que tout compte qui lui est ajouté pourra enregistrer et supprimer des SPN pour lui-même et pour lui-même. C'est exactement la bonne quantité d'autorisations, car ces comptes ne pourront pas piétiner les SPN enregistrés par d'autres comptes.

Le redémarrage de SQL Server à l'étape 16 a pour but de garantir que les SPN sont enregistrés comme prévu. SQL essaiera de supprimer tous les SPN enregistrés à l'arrêt et de les ajouter au démarrage, de sorte que le redémarrage n'est vraiment nécessaire que si aucun SPN n'existe actuellement pour ledit service SQL Server.

La dernière remarque sur cette approche est que si vous exécutez SQL Server dans une configuration FCI (Failover Clustered Instance) traditionnelle, il n'est PAS recommandé d'ajouter le compte de service de cette instance à cette unité d'organisation, par KB 2443457 .

J'ai vraiment besoin de poster la partie 2 de ma série Kerberos ...

— John Eisbrener
source

Ce ne sont pas des objets utilisateur descendants , ce sont des objets informatiques descendants .

— Isaac Kleiman

Lorsque le service SQL Server crée SPN, il en crée deux pour chaque instance. C'est le format qu'il utilise.

Instance par défaut:

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

Instance nommée:

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

Pour vos instances nommées, si vous créez des SPN manuellement, vous devrez disposer d'un port statique au lieu du port dynamique par défaut.

— Bob Klimes
source