SQL Server Reporting Services et System Center

  • Article

Depuis SQL Server 2000, il existe un composant associé à SQL Server qui permet la restitution de données via un simple navigateur ; SQL Server Reporting Services ou SSRS. Dans SQL Server 2000, ce composant doit être téléchargé. Il est nativement présent dans SQL Server 2005 et amélioré avec SQL Server 2008 ou SQL Server 2008 R2.

Si System Center Operations Manager 2007 (OpsMgr 2007) repose obligatoirement sur les possibilités de reporting de SSRS, pour System Center Configuration Manager 2007 (ConfigMgr 2007) ne l’utilise qu’optionnellement si vous utilisez ConfigMgr 2007 R2 et ConfigMgr 2007 R3. Pour ConfigMgr 2012, SSRS est la seule solution pour son reporting.

De par son architecture, SSRS peut être relativement complexe à installer car il repose sur différentes briques dont la connaissance fait partie des compétences périphériques à celles des produits de la gamme System Center :

  • un moteur de bases de données SQL Server,
  • un serveur de pages html,
  • un navigateur tel qu’Internet Explorer.

Pour le serveur de pages html, SQL Server 2008 et ultérieur apporte son propre moteur et, donc, ne repose plus sur Internet Informations Server (IIS). Les performances de ces dernières versions sont nettement supérieures et, quand bien même ce ne serait pas le critère le plus pertinent, cela incite à privilégier cette version ou les suivantes.

Le développement de rapports peut s’effectuer de manière plus naturelle au moyen des outils livrés nativement ou des compléments tels que Report Builder, mais aussi de Visual Studio. Pour ConfigMgr, une référence est disponible à travers la documentation ‘Creating Custom Reports By Using Configuration Manager 2007 SQL Views’. Pour OpsMgr, la référence du schéma de la base OperationsManagerDW est disponible sur :
https://technet.microsoft.com/en-us/library/gg508713.aspx

Les évolutions de la sécurité dans Windows Server et un niveau de contraintes acceptables en fonction de votre stratégie de sécurité peuvent rendre la mise en place de SSRS complexe, voire mystérieuse. Faute de croire aux vertus des pattes de lapin et autres gri-gris, je vais tenter de faire le point.

Je ne détaillerai pas ici les comptes et groupes propres à ConfigMgr ou OpsMgr, mais uniquement ceux en rapport avec SQL Server et SSRS.

De manière générale, l’identité sous laquelle s’exécute différents services peut être choisie parmi :

  • un compte ordinaire local à la machine
  • un compte utilisateur local qui est administrateur du système
  • un compte ordinaire du domaine
  • le compte Service Réseau (AUTORITE NT\SERVICE RÉSEAU ou NT AUTHORITY\NETWORK SERVICE)
  • le compte Service Local (AUTORITE NT\SERVICE LOCAL ou NT AUTHORITY\LOCAL SERVICE)
  • le compte du système local (AUTORITE NT\SYSTEM ou NT AUTHORITY\SYSTEM)
  • un compte de domaine qui est administrateur du système
  • un compte de domaine qui est administrateur du domaine ou plus encore.

Pour faire fonctionner SQL Server ou ses services associés, les pratiques les plus courantes sont d’utiliser un compte de domaine ayant des privilèges d’administrateur de l’ordinateur, mais ce n’est pas une bonne pratique que de donner ces privilèges trop importants. Idéalement, s’il est bon d’utiliser un compte de domaine, il est souhaitable de ne donner à ce compte que le minimum de droits nécessaires. À défaut d’aller jusqu’à ce réglage, l’utilisation de 'Service Réseau' est un bon compromis entre la facilité d’exploitation et la sécurité, mais ce n’est pas, non plus, une bonne pratique.

Les comptes de services et droits et privilèges pour SQL Server sont décrits sur la page suivante :
https://msdn.microsoft.com/fr-fr/library/ms143504.aspx

Dans le cas de SQL Server avec SSRS, nous avons, à minima, les services suivants :

  • le compte de service du moteur SQL Server
  • le compte de service du service SQL Server Reporting Services

Optionnellement, les comptes de service des services suivants :

  • SQL Server Agent
  • SQL Active Directory Helper Service
  • SQL Server Browser
  • SQL Server VSS Writer

Lors de l’installation, tous les services ne sont pas proposés pour recevoir un réglage spécifique. Ainsi SQL Server VSS Writer ne peut fonctionner qu’en tant que Système Local.

Les droits et permission suivantes sont nécessaires et suffisantes pour le compte de service qui fait fonctionner le moteur SQL Server :

  • Ouvrir une session en tant que service (SeServiceLogonRight)
  • Remplacer un jeton de niveau processus (SeAssignPrimaryTokenPrivilege)
  • Ignorer le contrôle de parcours (SeChangeNotifyPrivilege)
  • Changer les quotas de mémoire d'un processus (SeIncreaseQuotaPrivilege)
  • Autorisation de démarrer SQL Server Active Directory Helper
  • Autorisation de démarrer SQL Writer
  • Autorisation de lire le service Journal des événements
  • Autorisation de lire le service d'appel de procédure distante (RPC, Remote Procedure Call)
  • Le compte doit se trouver dans la liste des comptes dotés des autorisations « Liste du dossier » sur le lecteur racine où est installé SQL Server. Il doit aussi être à la racine de tout autre lecteur où les fichiers SQL Server sont stockés
  • Le compte doit avoir les autorisations « Contrôle total » sur tous les dossiers dans lesquels résident les fichiers de données ou les fichiers journaux (.mdf, .ndf, .ldf)

Si vous utilisez un compte de service, il est indispensable d’enregistrer le "ServicePrincipalName" ou SPN pour pouvoir l’utiliser via Kerberos.

Les commandes sont évoquées déjà sur un précédent billet, sont sous la forme de :

Setspn -a MSSQLSvc/<NomFQDNd’ordinateur>:<port> <domaine>\<compte>

Setspn -a MSSQLSvc/<NomNetBIOSd’ordinateur>:<port> <domaine>\<compte>

<Edition du 29 juin 2012>

La commande précise à composer utilise MSSQLSvc et non pas MSSQLServer comme précédemment indiqué. Merci aux interlocuteurs qui m’ont signalé l’erreur.

<Fin de l’édition du 29 juin 2012>

Pour tenir compte des nouvelles possibilités telles que décrites sur le blog de Tristan K, je passerais aujourd’hui la commande suivante :

Setspn –s MSSQLSvc/<NomFQDNd’ordinateur>:<port> <domaine>\<compte>

Setspn –s MSSQLSvc/<NomNetBIOSd’ordinateur>:<port> <domaine>\<compte>

La page de référence de l’enregistrement de ce SPN est sur :
https://msdn.microsoft.com/fr-fr/library/cc281382.aspx

L’utilisation d’un compte de service est une bonne pratique, mais doit s’accompagner d’un changement régulier du mot de passe de ce compte. Windows Server 2008 R2 apporte la possibilité d’utiliser les "comptes de service administrés" ou "managed service accounts", mais SQL Server ne fait pas (encore) partie des services pouvant être administrés par cette nouvelle technique. D’après la documentation de SQL Server 2012, il semble possible de l’utiliser ainsi que des comptes virtuels (voir la page déjà citée ci-dessus).

Si vous utilisez une version antérieure à SQL Server 2008, IIS vous propose également de faire fonctionner un pool d’application sous une certaine identité ; ce qui peut s’assimiler à un compte de service.

Si le compte utilisé ne possède pas de privilèges sur les compte d’ordinateur, il est également utile de penser à l’enregistrement du SPN via :

Setspn –s HTTP/<FQDNcomputername>:<port> <domain>\<domain-user-account>

Prenez exemple sur les précédents exemples cités ci-dessus pour l’ensemble des commandes à passer.

Dans la conception de votre solution, n’oubliez pas les limitations des comptes de services sur leurs activations respectives. Un compte ordinaire n’est pas capable de démarrer un process sous une identité possédant d’avantages de privilèges. C’est ainsi que vous ne pouvez pas utiliser le compte Service Réseau pour le compte de service du service SQL Server Reporting Services si vous envisagez d’automatiser la génération de rapports avec un compte d’accès à la base.

Presque tous les comptes utilisés par SSRS se règlent via l'Outil de configuration de Reporting Services qui est installé dans le menu démarrer lorsque SSRS est installé.

Pour l’ensemble des comptes de service, vous pouvez restreindre les privilèges de ces comptes en les empêchant d’ouvrir des sessions interactives (Refuser l'ouverture de session localement, deny local logon ou SeDenyInteractiveLogonRight).

Une fois la stratégie des comptes de service établie, il vous est nécessaire de régler le compte qui sert à SSRS pour accéder aux différentes bases de données (execution account). Ce compte est optionnel si vous ne planifiez pas l’exécution de rapports à intervalles réguliers.

À partir du moment où vous utilisez les possibilités de planification de rapports, il est nécessaire de sauvegarder la clé de chiffrement pour permettre une reprise rapide d’activité en cas de problème. Cette clé protège les comptes et mots de passes sockés dans la base de SSRS comtre une utilisation frauduleuse.

Un dernier point de réglage de la sécurité se situe, en dehors des rapports eux-mêmes, au niveau des propriétés de la source de données accessible en mode détaillé via le navigateur. Les différentes possibilités offertes sont les suivantes :

 Se connecter avec :

- Informations d’identification fournies par l’utilisateur qui exécute le rapport

- Informations d’identification stockées en sécurité dans le serveur de rapports

- Sécurité intégrée de Windows

- Informations d’identification non requises

La dernière option correspond au cas où le compte d’exécution est réglé et utilisé.

J’espère avoir fait le tour des points d’attention dans la mise en œuvre de SSRS pour System Center. N’hésitez pas à publier un commentaire si vous avez besoin de précisions.