Le blog technique

Il peut s’avérer nécessaire de changer les credentials des comptes de service utilisés par Orchestrator, lors d’incidents habituels dans le cycle de vie du produit (perte du mot de passe, politique de sécurité…).

Cependant, cela nécessite une reconfiguration à plusieurs niveaux :

Compte de service Orchestrator

Le premier niveau est le changement de credentials du compte utilisé pour exécutez les services Orchestrator (Management Service, Runbook Services…)

Dans un premier temps, il faut remplacer les mots de passe des services qui se trouvent sur chaque serveur hébergeant un rôle Orchestrator (Management, Runbook…).

Tout ou partie des services suivants peuvent être présents, en fonction des rôles attribués au serveur :

Pour modifier le compte utilisé par ces services, double-cliquez sur chacun d’eux et ouvrez l’onglet Log On :

Indiquez le nouveau login et/ou mot de passe puis cliquez sur OK.

Il est ensuite également nécessaire de modifier le compte utilisé par le pool d’application IIS :

Dans la console IIS Manager, ouvrez les Applications Pools et sélectionnez System Centez 2012 Orchestrator Web Features.

Faire un clic-droit et sélectionnez Advanced Settings.

Dans le champ Identity, cliquez sur l’icône « … »

Cliquez sur Set

Indiquez le nouveau login et/ou mot de passe du compte de service, puis cliquez sur OK dans chacune des fenêtres ouvertes.

Compte d’accès à la base SQL

Le second niveau concerne la modification des credentials du compte utilisé par Orchestrator pour se connecter à sa base SQL : il ne s’agit pas nécessairement du compte de service utilisé précédemment.

Lorsqu’il est modifié, la configuration d’Orchestrator doit être également modifiée sur l’ensemble des serveurs exécutant le rôle Runbook Server et/ou le rôle Web Service.

Runbook Server

Lancez la console Data Store Configuration :

Indiquez le nom du serveur SQL dans le champ Server et les credentials de connexion à l’instance SQL dans les champs Authentication Credentials., puis cliquez sur Next.

Cochez Use an existing data store et sélectionnez la base Orchestrator, puis cliquez sur Finish.

N’oubliez pas de répéter cette opération sur chacun des serveurs de Runbook.

Web Service

Le fichier de configuration du webservice est chiffré, il est donc nécessaire de le déchiffrer avant de le modifier.

Ouvrez un prompt de commande en mode administrateur et exécutez la commande

C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pdf "connectionStrings" "D:\Program Files (x86)\Microsoft System Centez 2012 R2\Orchestrator\Web Service\Orchestrator2012"

Dans la console IIS Management, ouvrez l’arborescence Sites/Microsoft System Centez 2012 Orchestrator Web Service/Orchestrator2012.

Ouvrez la configuration des Connection Strings

Ouvrez Orchestrator Context et modifiez les informations de connexion à la base de données (serveur, instance, credentials…) en fonction du besoin.

Chiffrez à nouveau le fichier de configuration à l’aide de la commande C:\Windows\Microsoft.NET\Framework\v4.0.30319\aspnet_regiis.exe -pef "connectionStrings" "D:\Program Files (x86)\Microsoft System Centez 2012 R2\Orchestrator\Web Service\Orchestrator2012"

Enfin, redémarrez IIS à l’aide de la commande iisreset.exe

Ca y est, nous avons désormais fait le tour de cette procédure, assez fastidieuse il est vrai… et malheureusement pas automatisable sous forme de runbook

Contexte

L’une des tâches régulièrement exécutées par un DBA est de restaurer ou d’attacher des bases entres différentes instances SQL. Lors de ce type d’opération, il est fréquent de rencontrer des erreurs d’authentification du type :

• Error 15023 : User already exists in the current database,
• Error 4064 : Cannot open user default database. Login failed,
• The database <VOTREBASE> is not accessible. (Object Explorer). A la vue de ces erreurs, un DBA peux être tenté de retirer manuellement les utilisateurs des différentes bases de données pour les ajouter, cette action – bien que fastidieuse – résoudrais le problème décrit, il existe néanmoins des solutions intégrées à SQL pour détecter et mapper les utilisateurs orphelins (orphaned users).

 

Explication du problème

Les utilisateurs orphelins apparaissent lorsque le SID d’un utilisateur d’une base de donnée ne correspond pas au SID du même utilisateur qui est renseigné dans la base master.

Le SID d’un utilisateur apparait donc à deux niveaux :

• Au niveau instance : dans les vues système ‘”sys.server_principals” et “sys.syslogins” présentes dans la table Master,
• Au niveau base de donnée : dans la table système sysusers.

Le SID d’un utilisateur (identifiant unique) sert à mapper un utilisateur d’une base de donnée au login renseigné dans l’instance SQL, donc lors de la restauration d’une base de donnée vers une instance SQL différente, il faut penser à re-mapper les utilisateurs orphelins.

Résolution

Afin de re-mapper les utilisateurs orphelins sans avoir à passer sur chaque utilisateur manuellement, on peux s’aider de sp_change_users, cette commande prends trois paramètres différents :

• Report pour détecter les utilisateurs orphelins :

• Update_one pour mapper manuellement un utilisateur de la base à un login de l’instance :
  

  USE <YOURDATABASE> GO sp_change_users_login @Action=’update_one’ @UserNamePattern=’User1′ @LoginName=’User1′ GO

• Auto_fix pour mapper automatiquement un utilisateur de la base à un login de l’instance et pour créer le login si absent de l’instance :
  

  USE <YOURDATABASE> GO sp_change_users_login @Action=’auto_fix’ , ‘User1’, null, ‘Password’ GO