Synchronisation des services et rôles avec l'ActiveDirectory (AD)
Synchronisation des services
Dans cet exemple, les services Process Studio correspondent à des groupes de l'AD, appartenant au groupe AD ici dénommé GEDQIM_SERVICES Le travail de mise en relation PERSONNE (from) ↔ SERVICE (to) se fait lors de la synchronisation des users. Pour la mise en relation, l'agent de synchronisation des users utilise un attribut précis qui contient un ou des noms de services d'appartenance. L'agent de synchronisation des users doit donc être planifié après l'agent de synchronisation des services (il faut que le service existe)
Filtre AD pour lecture des services (équivalences AD / Process Studio) Dans cet exemple, le nom court (cn) et le nom complet (dn) des services récupèrent l'attribut AD [name]. Il faudra s'assurer qu'il n'y ait pas de doublons dans l'AD. Autre exemple de mapping clé unique: [samaccountname]
Ne pas utiliser l'attribut AD [distinguishedname] pour récupérer le nom court (cn) et le nom complet (dn) car son contenu est plus complexe et pose un soucis dans le mécanisme de l'agent de synchronisation
Agent de synchronisation des services Un agent de synchronisation des services, peut alors être paramétré. Il utilise le filtre précédemment créé. Ses paramètres n'ont aucune particularité, pas d'attributs, pas d'action à exécuter
Filtre AD pour lecture des users (équivalences AD / Process Studio) Le filtre utilisé pour rechercher les utilisateurs dans l'AD doit être enrichi d'un attribut qui sera exploité pour rechercher le service (cf. explications ci après)
- il s'agira d'un attribut Process Studio précisément appelé
[department]ou[Departement]ou[memberof]
Agent de synchronisation des users L'agent de synchronisation des users est planifié après l'agent de synchronisation des services
Dans l'agent de synchronisation des users, prévoir 2 actions à lancer en fin de traitement "Affectation_service_nouvelles_personnes" & "Modification_service_personnes_existantes" Ces 2 actions n'acceptent aucun paramètres (Params) :
Que font ces actions ? :
- elles cherchent si le user que l'on importe possède l'attribut [departement], si trouvé elles s'arrêtent de chercher, sinon elles cherchent un attribut [Departement] et enfin sinon, elles cherchent un attribut [memberof] L'attribut recherché doit contenir un nom de service (ou des noms de services dans le cas de memberof)
L''information récupérée de l'AD est généralement multivaluée et formattée d'une manière particulière (CN=..., OU=..., DC=...)
Ex: CN=G_DEV,OU=Avanteam,DC=corp,DC=avanteam,DC=fr; CN=G_COM,OU=Avanteam,DC=corp,DC=avanteam,DC=fr;
Les 2 actions à lancer en fin de traitement exploitent l'attribut en éclatant les valeurs (séparateur point virgule) Puis, de chaque valeur est extrait la composante CN= Résultat du traitement pour notre exemple : G_DEV; G_COM
- À partir de l'information trouvée en priorité, elle cherche si une ressource de type Service existe dans l'application Avanteam
- Si un service existant est trouvé, elle crée la relation (cas du traitement de Department) ou les relations (cas du traitement de memberof) Si le service n'existe pas, la relation ne se crée pas et ne pourra pas se créer postérieurement tant qu'aucune modification n'aura lieu sur l'attribut (cf. point b) ci après)
Dans le cas de l'action Modification_service_personnes_existantes :
a) l'action n'est exécutée qui si la personne a subi une modification au niveau de l'un de ses attributs (peut importe lequel mais il faut un écart)
b) si l'action ne constate ne aucun changement pour le contenu de l'attribut traité (avant / après) : aucune mise à jour ne se produit sur les relations
c) si il existait un précédent attribut memberof (ou Department) pour le user traité (issu d'une précédente synchro) il y a d'abord suppression des anciennes relations qui sont définies dans l'ancienne valeur de memberof (ou Department)
Synchronisation des rôles
Dans cet exemple, les rôles Process Studio correspondent à des groupes de l'AD, appartenant au groupe AD ici dénommé GEDQIM_ROLES
A la différence des services, le travail de mise en relation PERSONNE (from) ROLE (to) se fait lors de la synchronisation des rôles.
Pour la mise en relation, l'agent de synchronisation des roles utilise un attribut [Member] qui contient des noms de personnes.
L'agent de synchronisation des rôles doit donc être planifié après l'agent de synchronisation des users.
Filtre AD pour lecture des rôles (équivalences AD / Process Studio)
- l'attribut étendu
[Member]doit être paramétré dans le filtre AD de récupération des rôles
Attention : dans les attributs étendus, il est important de respecter les majuscules/minuscules (Attribut LDAP / AD : member -- Equivalent Process Studio : Member )
Dans cet exemple, le nom court (cn) et le nom complet (dn) récupèrent l'attribut [name] de l'AD. Il faudra s'assurer qu'il n'y ait pas de doublons dans l'AD.
Agent de synchronisation des rôles L'agent de synchronisation des rôles est planifié après l'agent de synchronisation des users
Dans l'agent de synchronisation des roles, prévoir 2 actions à lancer en fin de traitement "Affectation_personne_nouveau_role" & "Modification_personne_role_existant" De manière optionnelle, ces 2 actions peuvent accepter un paramètre (Params) Le paramètre correspond à un attribut des users (exemple : synchroname) que l'on a préalablement ajouté et synchronisé via le filtre de récupération des users
Que font ces actions ? :
- elles consultent le contenu de l'attribut [Member] qui doit contenir des noms de personnes
- elles traitent cette information car l'information récupérée de l'AD est généralement multivaluée et formattée d'une manière particulière (CN=..., OU=..., DC=...)
Ex: CN=Patricia CARIOU,OU=com,OU=Avanteam,DC=corp,DC=avanteam,DC=fr; CN=Alex TERIEUR,OU=com,OU=Avanteam,DC=corp,DC=avanteam,DC=fr
Les 2 actions à lancer en fin de traitement exploitent l'attribut en éclatant les valeurs (séparateur point virgule) Puis, de chaque valeur est extrait la composante CN= Résultat du traitement pour notre exemple : Patricia CARIOU; Alex TERIEUR
- a. CAS SANS PARAMETRE : elles cherchent si des users correspondent à cette information en recherchant les users sur leur dn_name
b. CAS AVEC PARAMETRE : elles cherchent si des users correspondent à cette information en recherchant les users dans leur attribut, passé en paramètre. Par exempe dans notre cas elles recherchent les users ayant l'attribut synchroname = 'Patricia CARIOU' ou 'Alex TERIEUR' - à chaque user trouvé; elles créent la relation Si un user n'existe pas, la relation relative à ce user ne se crée pas et ne pourra pas se créer postérieurement tant qu'aucune modification n'aura lieu sur l'attribut Member (cf. point b ci après)
Dans le cas de l'action Modification_personne_role_existant :
a) l'action n'est exécutée qui si la personne a subi une modification au niveau de l'un de ses attributs (peut importe lequel mais il faut un écart)
b) si l'action ne constate ne aucun changement pour le contenu de l'attribut Member (avant / après) : aucune mise à jour ne se produit sur les relations
c) si il existait un précédent attribut Member pour le user traité (issu d'une précédente synchro) il y a d'abord suppression des anciennes relations qui sont définies dans l'ancienne valeur de Member
Séquence d'exécution des agents
L'ensemble de ces paramétrages sont disponibles pour extraction Synctool dans les environnements BestPractices