web-dev-qa-db-fra.com

À 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) , pas 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 .

Lorsque 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é):

enter image description here

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 canaux 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é se fait via TCP uniquement, les canaux nommés sont désactivés dans le gestionnaire de configuration. Nous allons les réparer/créer manuellement au lieu de permettant au compte de service SQL de les créer au démarrage du serveur.)

sql-serverkerberosspn
8
BradC

Si vous utilisez uniquement TCP/IP pour vous connecter à vos instances, vous n'avez que les 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 (de nombreux tests dans mon environnement) et des éléments suivants Sentence d'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 le 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 à ce sujet, les formats devraient ressembler à ceci:

enter image description here

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

Maintenant, faites de votre administrateur réseau (par exemple, la configuration de l'unité d'organisation qui permet 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:

  1. En tant que compte avec des droits élevés sur le domaine, ouvrez ADSI Edit (adsiedit à partir de l'invite de commande)
  2. Clic droit sur ADSI Edit -> Connectez-vous à ...
  3. Connectez-vous à Contexte de dénomination par défaut
  4. Naviguez vers/Créez le conteneur OU contenant les comptes de service auxquels vous souhaitez accorder des droits SPN
  5. Clic droit sur l'OU -> Propriétés
  6. Cliquez sur l'onglet Sécurité
  7. Cliquez sur le bouton Avancé
  8. Mettez en surbrillance [~ # ~] auto [~ # ~] et cliquez sur Modifier ... ou si le [~ # ~] auto [~ # ~] l'utilisateur spécial 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
  9. Cliquez sur l'onglet Propriétés
  10. Sélectionnez Objets utilisateur descendants 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écrit par ce ServerFault/StackExchange post.
  11. Cochez la case Autoriser à côté des éléments suivants:
    • Lire servicePrincipalName
    • Service d'écriture NomPrincipal
  12. Cliquez sur Ok (dans la fenêtre de saisie des autorisations)
  13. Cliquez sur Ok (dans la fenêtre Paramètres de sécurité avancés)
  14. Cliquez sur Ok (dans la fenêtre des propriétés de l'unité d'organisation)
  15. Ajouter comptes de service exécutant les services SQL Server à l'unité d'organisation
  16. (Facultatif) Redémarrez Services SQL Server exécutés sous lesdits comptes
  17. Profitez de friandises

Après avoir suivi les étapes ci-dessus, le conteneur OU en question est maintenant configuré de 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 s'assurer que les SPN sont enregistrés comme prévu. SQL va essayer 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 note 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 ...

5
John Eisbrener

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.

1
Bob Klimes