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/FQDNLe 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/sqlbox1MSSQLSvc/sqlbox1:1433MSSQLSvc/sqlbox1.mydomain.orgMSSQLSvc/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:1522MSSQLSvc/sqlbox1:instance2MSSQLSvc/sqlbox1.mydomain.org:1522MSSQLSvc/sqlbox1.mydomain.org:instance2MSSQLSvc/sqlbox1.mydomain.org/instance2MSSQLSvc/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.)
la source
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 :
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:
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 ...
la source
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:
Instance nommée:
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.
la source