Tout ce qui est écrit ici est donné tel quel et ne confère aucun droit.
Après près de 10 ans de conseil dans l'équipe française de Microsoft Consulting Services (MCS), j'ai rejoint l'équipe européenne de Customer Service and Support (CSS) comme ingénieur conseil grands comptes. Mon rôle consiste à délivrer du conseil proactif et réactif sur les logiciels de la gamme System Center (ConfigMgr et OpsMgr, principalement).Je délivre de l'expertise technique associée aux méthodologies ITIL/MOF sous la forme d'atelier de type vérification de l'état de santé, évaluation des risques, revues de supportabilité, cours magistraux.Si vous êtes intéressés pour avoir un contact Microsoft dédié pour des ressources techniques, travailler avec vous sur des projets, délivrer une formation ou un transfert d’expertise et vous aider à résoudre vos problèmes, le PFE dédié est fait pour vous. Pour en savoir plus, contactez votre responsable technique de compte ou interlocuteur habituel chez Microsoft.
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 :
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 : http://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 :
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 : http://msdn.microsoft.com/fr-fr/library/ms143504.aspx
Dans le cas de SQL Server avec SSRS, nous avons, à minima, les services suivants :
Optionnellement, les comptes de service des services suivants :
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 :
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 : http://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.