Un peu de process d'ADMPWD dans ce monde de cloud (4/5)

C’est l’heure des sujets qui piquent mais juste un peu. Mais pourquoi donc ne pas tout faire dans un seul et unique Runbook? C’est une bonne question. Ça m’a pris comme ça. Plus sérieusement, c’est un choix personnel de toujours séparer :

  • Les Runbook d’interfaces avec SCSM
  • Les Runbook au cœur de l’activité
  • Les Runbook "Sub-routines" que j’utilise

De cette manière on évite le Runbook monstrueux impossible à maintenir. Dans le cas présent, nous avons un Runbook d’interface avec SCSM. Il a pour objectif de :

  • Récupérer les informations en provenance de la CMDB
  • Appeler un ou plusieurs Runbook "Sub-Routines"
  • Appeler le Runbook au cœur de l’activité
  • D’appeler un Runbook d’interface avec SCSM permettant de remonter des informations dans la Service Request

Mon Runbook d’interface doit récupérer les paramètres dont a besoin le Runbook que l’on va appeler et retourner un statut suite à l’exécution. Plongeons dans ce Runbook qui finalement n’est pas si compliqué qu’il n’y parait :

clip_image002

Pour ceux qui avaient esquivé la série A la surface d’un service dans System Center Service Manager, petit rappel. D’un point de vue technique, Service Manager va créer un objet "Runbook Automation Activity" qui va référencer les paramètres à passer sous forme de liaisons. Nous allons passer l’identifiant unique de cet objet en paramètre du Runbook ("SC Object Guid" le bien nommé). Ce choix me permettra d’utiliser l’IDP SCSM d’Orchestrator pour illustrer quelques manipulations de base de la CMDB. Donc revenons à notre Runbook d’interface. Il commence par une activité qui référence notre seul et unique paramètre.

clip_image004

Pour les plus curieux, voilà un objet "Runbook Automation Activity" ainsi que l’identifiant unique de l’objet RBA qui est passé en paramètre. Le Fameux "SC Object Guid" que nous allons revoir souvent.

clip_image006

Justement cet identifiant, nous allons l’utiliser immédiatement pour identifier notre paramètre, à savoir la machine virtuelle pour laquelle nous allons demander de révéler le mot de passe Administrateur. On va exploiter le potentiel de la CMDB. Au lieu de simplement coder le nom de la VM "en dur" dans l’objet "Runbook Automation Activity", on exploite les relations entre les objets et c’est plus classe. Dans le cas présent, lors de la création de l’objet "Runbook Automation Activity", une relation a été créée avec le paramètre qui n’est autre qu’un objet de la classe "Virtual Machine".

clip_image008

A noter que je suis parti du principe qu’il n’y avait qu’une seule relation, donc un seul paramètre. Si on autorisait la sélection multiple dans la "Request Offering" de SCSM, il faudrait en tenir compte pour traiter chaque cas. Dans le cas qui nous occupe, j’exploite un attribut de la relation pour déterminer qu’il n’y a qu’un seul objet en sortie de cette activité. Si ce n’est pas le cas, le Runbook sort en erreur.

A ce stade, nous avons la référence d’un objet de la classe "Virtual Machine", allons chercher des informations sur cet objet dans la CMDB avec l’activité "Get Object". <Mode Astuce SCSM ON> Nous faisons référence à un paramètre en relation avec une autre classe. Donc l’identifiant unique que nous cherchons (le "SC Object GUID") est référencé dans l’attribut Related Objet GUID" <Mode Astuce SCSM Off>.

clip_image010

Nous avons tous les paramètres ou presque. Au final, on doit dévoiler le mot de passe administrateur de la machine virtuelle que nous venons d’identifier. Encore faut-il savoir à qui envoyer un mail. Facile me direz-vous, dans la "Service Request", on a nécessairement cette information dans l’attribut "Created by user". C’est vrai, nous y reviendrons. Pour l’instant, nous allons appeler un Runbook qui va se charger pour nous de retrouver cette information à l’aide de l’identifiant de l’objet "Runbook Automation Activity" passé en paramètre.

clip_image012

Si on arrive ici, c’est qu’on a toutes les informations pour appeler le Runbook que nous avons développé dans le billet précédent. En retour, le Runbook nous retournera une variable indiquant le bon déroulement de l’exécution (OK, NOK).

clip_image014

Cette variable est importante car à ce stade de notre Runbook nous devons prendre une décision. Si le service a été correctement rendu, alors nous pouvons poursuivre dans une branche (OK). Si ce n’est pas le cas, c’est l’autre branche (NOK). Dans les deux cas, on appelle un Runbook qui va se charger de remonter un statut dans la "Service Request" avant de terminer le Runbook d’interface avec SCSM.

clip_image016

Maintenant que les grandes lignes sont tracées, penchons-nous sur les petits détails pour comprendre deux tours de magie utilisés. Commençons par comprendre comment on retrouve l’utilisateur initiateur de la "Service Request" dans SCSM. La méthode la plus basique aurait été de passer l’information en paramètre (d’où la V1 de la "Request Offering"). Or, cette information est présente dans la CMDB, encore faut-il faire son chemin pour y accéder. J’ai volontairement créé un Runbook dédié pour cela (Runbook "Sub-routine"). Ici encore, c’est une histoire de relation mais avec un objet de la classe "Service Request", lequel a lui-même une relation avec un objet de la classe "User" que nous allons identifier pour enfin en extraire son adresse de messagerie.

clip_image018

Je ne détaille plus le pourquoi mais nous repartons de notre identifiant unique de l’objet "Runbook Automation Activity", c’est notre point d’entrée dans la CMDB.

clip_image020

Cette fois, la relation concerne un objet de la classe "Service Request". Sauf que sur ma maquette qui a déjà beaucoup vécu, j’ai intégré quelques personnalisations de CMDB. J’utilise donc mon extension de la classe "Service Request" que j’ai nommé "My Service Request".

clip_image022

On remarquera que j’ai volontairement fait l’impasse sur la gestion d’erreur. Il y a forcément un objet de la classe "My Service Request" que nous allons identifier à l’aide de son identifiant "SC Object Guid" référencé dans l’attribut" Related Object Guid". Ça commence à rentrer maintenant?

clip_image024

Etage "Service Request", direction "Created user". Ici encore, c’est une relation avec un objet de la classe "Active Directory User". Jusqu’ici, rien de bien compliqué.

clip_image026

C’est en sortie de cette activité que cela se complique (Ce n’est pas la faute à Powershell). En retour, nous n’avons pas un objet en relation mais deux. On s’en rend compte lors qu’on regarde le détail de l’exécution de l’activité. Problème, comment identifier l’un ou l’autre.

clip_image028

C’est une bonne piste, maintenant, faut faire le tri. Pour cela, il a été nécessaire d’utiliser le débogueur pour clairement identifier les différents "Related Object Guid" en question. Avec un peu de persévérance, on finit par comprendre la différence :

clip_image030

Nous avons deux relations :

  • La première pour l’utilisateur qui a créé la requête
  • La seconde pour l’utilisateur à qui on a affecté la requête (notion d’analyste dans SCSM)

Ce qui nous intéresse, c’est le premier. Pour filtrer uniquement celui-ci, nous allons jouer sur les propriétés "Include" et Exclude" de la relation. Même les liaisons entre les activités ont des propriétés que l’on peut configurer (sic). J’ai donc indiqué que nous ne retenons les objets que si l’activité "Get-Relation" s’est déroulée avec succès ou que celle-ci nous désigne bien un attribut dont la valeur est "Created By user".

clip_image032

Au contraire, je veux exclure, tout objet pour lequel la valeur de ce même attribut n’est pas celle attendue.

clip_image034

La gestion des propriétés "include" et "exclude" est importante dans Orchestrator car c’est grâce à elles que l’on va introduire la gestion d’erreur au sein de nos Runbooks. Il faut donc s’assurer de bien les configurer. Dès lors qu’on est assuré d’avoir la référence au bon objet, allons rechercher ses caractéristiques avec une activité "Get-Object".

clip_image036

Nous avons maintenant toutes les informations pour retourner l’adresse mail de l’utilisateur créateur de la "Service Request" en résultat de Runbook. On notera que si cette information est dans la CMDB, c’est que le connecteur Active Directory en a importé l’objet et la majeure partie de ses propriétés.

Second tour de magie, utilisé : La mise à jour de la "Service Request" en fonction du résultat du Runbook. C’est ce qui permettra d’informer l’utilisateur que sa requête a été traitée avec succès. Le cas échéant d’indiquer l’erreur rencontrée. Vous reprendrez bien un petit Runbook pour la route? Sans Powershell ajouté!

clip_image038

Notre Runbook attend deux paramètres en entrée, à savoir l’identifiant du Runbook Automation Activity qui sera notre point de départ pour remonter vers la "Service Request" ainsi que l’information que nous allons inscrire comme résultat de la "Service Request".

clip_image040

On ne change pas une méthode qui gagne en recherchant l’objet "Service Request" en relation avec notre objet "Runbook Automation Activity".

clip_image042

Je sais qu’il y a nécessairement qu’une seule relation, donc pas la peine de tester, allons à l’essentiel en mettant à jour objet "Service Request" dans la CMDB. La mécanique est maintenant rodée, on va juste passer un peu de temps sur les attributs que l’on met à jour.

clip_image044

Pour le second, rien de bien sorcier, c’est du texte qui est issu d’un retour du Runbook qui a révélé le mot de passe Administrateur de notre serveur. Pour le premier par contre, c’est un peu plus subtile. Dans la "Service Request", cet attribut n’accepte que des valeurs définies dans une liste SCSM (encore un objet dans la CMDB) nommée "Service Request Implementation results".

clip_image046

C’est ce contenu qu’Orchestrator nous propose. J’ai donc deux Runbooks. Le premier pour indiquer que tout s’est déroulé avec succès et le second pour indiquer qu’une erreur est survenu lors de l’exécution. Au passage deux piqures de rappel sur le sujet pour éviter les déconvenues suite à une installation malencontreuse d’Orchestrator sur un système autre qu’US :

Vous lisez encore? Bien, reste plus maintenant qu’à mettre tout cela en musique dans Service Manager. Courage, plus qu’un seul billet à supporter.

BenoitS – Simple and Secure by Design but business compliant

Benoit

Simple, yes, Secure Maybe, by design for sure, Business compliant always!

Les derniers articles par Benoit (tout voir)

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.