(Attention cela n’empêche pas de mieux sécuriser son serveur LDAP pour par exemple interdire la consultation du champ du mot de passe dans le LDAP par tout autre utilisateur que lui-même)

Les objectifs de ce nouveau tutoriel sont :

• Montrer comment parcourir les enregistrements d’un LDAP avec JMeter
  • Pour cela avec un contrôleur Pour chaque
• Faire une action conditionnelle avec un contrôleur Si, en fonction d’une valeur de variable
• Monter la manipulation de données (variables JMeter) dans une utilisation avec Pré-processeur BeanShell

La capture suivante l’arbre JMeter de ce tutoriel.

On commence bien entendu par ajouter un élément Groupes d’unités (en 1-1-1) pour permettre par la suite l’exécution du scénario. Ensuite on attaque avec l’ajout de la première Requête LDAP étendue, elle va se charger de la connexion avec le serveur LDAP.

Le type de test est « Unité liée » (bind en anglais) correspondant à une connexion sur le serveur LDAP.

On complète les champs suivants :

• Nom du serveur, par le nom ou l’adresse IP du serveur LDAP
• Port, en général le port 389
• DN : nom du suffixe d’annuaire
• Identifiant, par le « login » de connexion à l’annuaire LDAP.
• Mot de passe associé

La requête LDAP suivante va permettre de faire la recherche dans le LDAP de la liste des utilisateurs. On sélectionne le périmètre de recherche au niveau du champ Search base, en indiquant « ou=Users » (qui sera suffixé par dn=milamberspace,dn=net), le filtre de recherche (Search Filter) est « (uid=*) », où l’étoile indique « tous ». Cette requête LDAP signifie donc : « On cherche toutes les fiches de l’annuaire du groupe d’utilisateurs ou=Users,dn=milamberspace,dn=net. »

L’extracteur d’expression régulière, ajouté en tant que fils de la requête LDAP de sélection des fiches utilisateurs, va permettre de créer une grande liste des UID (identifiants des utilisateurs) provenant des résultats de recherche. La RegExp va créer un ensemble de variables JMeter ayant le format suivant « VAR_UID_xx » où xx correspond à un indice de liste.
On note que c’est la valeur « -1 » dans le champ « Correspond au num. » qui permet d’indiquer à JMeter qu’il faut créer une liste de variables VAR_UID_xx pour toutes les occurrences trouvées avec l’expression régulière.

Histoire de vous aider à matérialiser la chose, la capture suivante montre les fameuses variables VAR_UID_xx qui vont être créées lors de l’exécution.

On reviens aux éléments du scénario avec le contrôleur Pour chaque :

Ce contrôleur Pour chaque qui va permettre de parcourir la liste des variables VAR_UID_xx récupérées dans la requête précédente. Pour chaque valeur de variable, on va faire le traitement suivant :

1. Une requête LDAP de recherche pour récupérer le mot de passe en clair
2. Si besoin, une requête LDAP de mise à jour afin de remplacement ce mot de passe par sa version SHA-1 (empreinte SHA)
3. Si besoin, une requête LDAP de recherche pour s’assurer que la mise à jour s’est bien passée.

Donc pour la requête de recherche du mot de passe d’un utilisateur donné, on va remplacer l’étoile dans le champ Search Filter par la valeur de la variable ${UID} qui correspondra à l’utilisateur courant dans la boucle Pour chaque.

Le champ Size Limit sera placé à 1 (on ne cherche que 1 seul élément. Enfin c’est pas vraiment obligatoire de remplir ce champ, on est censé toujours avoir 1 élément en retour). On place la limite de temps de réponse à 10 000 ms, et surtout on place « userPassword » dans le champ Attributes afin que le serveur LDAP nous revoie seulement la valeur de ce champ pour l’utilisateur.

On n’oubliera pas de cocher la case « Examiner les résultats de recherche ? » afin de l’on puisse avoir, dans les données de réponses, les valeurs demandées (ici le userPassword).

Ensuite, commence une série de trois extracteurs d’expression régulière. Le premier va permettre la récupération du mot de passe, ce dernier se situe entre deux balises userPassword dans la réponse.

La deuxième est pour récupérer l’identifiant de l’utilisateur en cours. Ce n’est pas obligatoire, mais cela permet de vérifier si on a eut le bon utilisateur.

La troisième est pour récupérer le mot de passe au format SHA dans le cas où l’utilisateur a déjà un mot de passe au format SHA. Donc cela voudra dire qu’il ne faut pas convertir son mot de passe.

Le contrôleur Si va justement permettre de déterminer si c’est nécessaire ou non de faire la conversion. Pour cela on compare si la variable cible de l‘extracteur d’expression régulière MOT_DE_PASSE_SHA a reçu la valeur par défaut (ici il s’agit d’un texte arbitraire qui est stocké dans la variable ${MDP_NON_SHA}).

Donc si c’est la valeur par défaut, c’est que le mot de passe n’est pas en SHA, il convient donc de procéder à la conversion.

Cette requête LDAP est donc celle de la modification. On choisi le type de test « Modification test », et dans le tableau, on définit l’attribut userPassword, sa nouvelle valeur (voir ci-dessous) et le code d’opération « replace ».

Le Pré-Processeur BeanShell est rattaché en tant que fils à la requête LDAP de modification. C’est lui qui va faire la conversion du mot de passe en clair vers un mot de passe en SHA, le tout en code de programmation Java. Il permet donc de créer (définir) la nouvelle valeur du mot de passe qui sera insérée par la requête de modification.

La requête suivante est pour faire une nouvelle recherche de l’utilisateur courant. On va, en effet, re-demander son mot de passe afin de vérifier qu’il a bien été changé.

La vérification du bon changement, est assurée par un élément Assertion Réponse. Le motif à tester est le nouveau mot de passe (le SHA), et attention, le type de correspondance est « Commence par ». La traduction en français induit en erreur, car en fait, cela « ne commence pas par » mais plutôt « Contient (sans expression régulière) », car dans le nouveau mot de passe, il peut y avoir des caractères spéciaux d’expressions régulières qui risquent d’être mal interprétés avec le type « Contient ». (je vais proposer une nouvelle traduction pour la prochaine version de JMeter)

La dernière requête LDAP est celle de la déconnexion (Délier les unités).

Et voilà, il ne reste plus qu’à faire une exécution du test (une et une seule), tout en vérifiant dans l’arbre de résultat que tout s’est bien passé.

Le récepteur d’Assertion, dans l’arbre JMeter, permettra, quant à lui de capter d’éventuels problèmes lors de l’exécution. Il est préférable de cocher la case « Uniquement (les) Erreurs » dans ce récepteur, afin de ne voir que les problèmes survenus.

Voilà pour ce deuxième billet sur JMeter et les LDAP. Bon courage.

./

Ce tutoriel a pour objectifs :

1. Rappeler l’utilisation de Requête JDBC pour accéder à une base de données, et récupérer dans un ensemble de variables les résultats de requête JDBC
2. Montrer comment effectuer l’ajout d’une fiche Utilisateur dans un serveur LDAP via une Requête LDAP étendue de JMeter
3. Montrer le fonctionnement du Contrôleur Pour chaque dans JMeter
4. Montrer un petit exemple de Pré-Processeur BeanShell

Voici le plan de de test final.

On observe deux sections :

1. Base de données : qui est un Contrôleur Simple regroupant les éléments nécessaires à la partie JDBC afin d’accéder à la base et faire la requête SQL qui va permettre de récupérer les utilisateurs à créer.
2. LDAP : qui est aussi un Contrôleur Simple regroupant les éléments permettant la connexion au serveur LDAP et effectuer la requête d’ajout dans le LDAP des utilisateurs.

Concernant la partie Base de données, je vous revois vers ce billet pour avoir plus de détails sur sa mise en place. Ci-dessous, je vais seulement commenter certains éléments de cette partie.

L’élément Requête JDBC correspond à la requête SQL que JMeter va effectuer pour obtenir une liste de noms et de prénoms qui seront utilisés dans la section LDAP.

• Le champ Nom de liaison fait référence au ‘pool’ JDBC configuré dans l’élément Configuration de connexion JDBC
• Le type de requête est Select Statement, on fait donc une requête SQL commençant par SELECT :
  • SELECT ID, NOM, PRENOM from BOXERS
• Dans le champ Noms des variables, on donne les variables (JMeter) qui vont recevoir les données. Pour nous, cela sera VAR_ID, VAR_NOM, VAR_PRENOM.

A l’exécution, la requête SQL retournera une liste de noms et les placera dans les variables correspondantes, avec un suffixe _X où X est le numéro de la ligne retournée.

Pour la section suivante, LDAP, on utilisera donc ces variables pour faire l’ajout dans le LDAP.

Ainsi voici la partie LDAP : le premier élément est une Requête LDAP étendue qui va permettre de faire la connexion avec le serveur LDAP.

Pour cela, on choisi le type de test « Unité liée », et on complète les différents champs nécessaires :

• Nom du serveur (ou adresse IP)
• Port : 389 (correspondant au port par défaut pour le protocole ldap)
• DN : nom du suffixe de l’annuaire
• Identifiant : un compte disposant des droits pour modifier l’annuaire (ici c’est l’administrateur LDAP)
• Mot de passe associé au compte ci-dessus
• Délai d’attente de connexion : paramètre optionnel qui permet de faire échouer l’échantillon (de connexion) si jamais la connexion n’est pas ouverte
• La case à cocher permet de faire une connexion via le protocole LDAPS (via SSL donc) (accompagné par le port 636 en général)

Ensuite, on en profite pour faire l’opération inverse de la connexion : la Déconnexion. Pour cela, on choisit tout simplement le type de test « Délier les unités ». Cette requête sera placée en fin du scénario.

Passons aux éléments qui vont nous permettre d’ajouter les fiches annuaires dans le LDAP.

Le contrôleur ci-dessus, Pour chaque va tout simplement (efficacement je dirais), parcourir une à une les variables VAR_NOM_x où x est le numéro de ligne des résultats de la requête SQL précédente. À chaque itération, il va affecter à la variable NOM la valeur de VAR_NOM_x. (on notera la correspondance entre VAR_NOM de la requête JDBC Select et le VAR_NOM_x du contrôleur)

Ici, on ajoute un Compteur JMeter qui nous permet de connaître (suivre) le numéro de ligne, afin que nous puissions l’utiliser dans la prochaine requête pour générer des variables.

Nous voilà dans la requête « costaude », il s’agit d’une Requête LDAP étendue qui va traiter l’ajout. Ainsi, on choisit le type de test « Add test ».

Puis le champ Entry DN nous permet d’indiquer l’identifiant unique de la fiche dans l’annuaire.

Le tableau suivant, permet d’ajouter les couples « clé: valeur » suivant le principe du fichier LDIF (importation de comptes LDAP).

On notera les points suivants :

• ${__V(VAR_PRENOM_${CPT})} permet de générer la variable « ${VAR_PRENOM_x} pour chaque itération du Contrôleur Pour chaque
• ${NEW_NOM} et ${NEW_PRENOM} sont des variables définies dans un Pré-processeur BeanShell (ci-dessous)

Dans la requête d’ajout, il est important de ne pas oublier les éléments « objectclass » qui vont définir la structure de la fiche annuaire.

En fils de la requête d’ajout, on place donc un Pré-processeur BeanShell, qui va permettre d’effectuer quelques actions (ou préparations) sur les données avant leur utilisation.

Tout d’abord, on récupère la variable CPT (via vars.get( »GET »)), puis avec une concaténation, on récupére la valeur de la variable VAR_PRENOM_x. On supprime les points et enlève les guillemets (car certains noms dans la base des boxers ont des pseudonymes entre guillemets). Puis on refait la même chose avec le NOM.

Pour finir, on génère l’adresse email via un petit passage en minuscule et une concaténation du domaine de messagerie.

A chaque fois, on utilise le vars.put pour déposer des nouvelles variables dans JMeter.

Ensuite, avec l’élément suivant, une Assertion Réponse, j’anticipe sur l’exécution et la vérification que tout s’est bien passé. En effet, si l’exécution de la requête d’ajout LDAP fonctionne correctement, le résultat contient « <responsemessage>Success</responsemessage> ». L’assertion sur ce texte va nous permettre de détecter rapidement les cas en erreur (si il y en a).

Après la requête d’ajout, on place une requête de recherche dans le LDAP (type de test : Search test). C’est optionnel, c’est juste pour faire une seconde vérification du bon ajout.

On notera :

• Le champ Search Filter qui est ici le « uid » inséré
• Le champ Scope est positionné à Effectuer une recherche ‘onelevel’ (on ne recherche pas dans les sous-éléments de l’arbre LDAP)
• Le champ Size limit pour limiter à 1 le résultat retourné (on fait une recherche unitaire)
• Le champ Limite de temps à 10000 (ms) pour faire échouer l’échantillon si le serveur LDAP est trop long à répondre
• Le champ Attributes (optionnel) qui permet de choisir les champs à récupérer, ici le CN, SN et Mail
• Et pour finir, la case à cocher Examiner les résultats de recherche ? va permettre d’avoir dans les résultats du test, les valeurs des champs récupérés afin notamment de faire (par exemple) une assertion.

Ensuite (enfin) on peut passer à l’exécution du scénario JMeter.

Pour cela, on grade la configuration par défaut du Groupes d’unités, à savoir : 1 unité qui monte en charge en 1 seconde et qui faire 1 itération (1-1-1).

(c’est le Contrôleur Pour chaque qui se charge des itérations sur les utilisateurs)

Voici l’arbre de résultats :

Si tout s’est bien passé, tout est vert. Dans les données de réponses, on voit les résultats des requêtes LDAP, avec la valeur Success.

On peut également vérifier dans les données de réponses que par exemple la génération des adresses email s’est bien déroulée.

Un récepteur Résultats d’assertion, configuré pour afficher uniquement les erreurs, permet de voir les utilisateurs qui ont eu un problème lors de l’exécution. Ici, il y a eu des soucis visiblement sur les noms de boxers qui ont un caractère accentué…

Et voilà, avec ce tutoriel, on découvre que JMeter sait faire d’autre chose qu’un test de charge Web.

Vous noterez que ce type de scénario, fait de JMeter une sorte d’ETL (Extract-Transform-Load). Ainsi, on peut même imaginer d’adapter ce scénario pour maintenir une synchronisation entre une base de données et un LDAP, le tout en exécutant JMeter en mode non-gui dans une tâche programmée ou un cron.

Je prépare une suite à ce tutoriel concernant la conversion automatisée des mots de passe stockés ici en clair dans le LDAP, vers des mots de passe stockés en SHA-1.

Bons scénarios.

En annexes :
A/ Un petit SELECT de ma base de données (histoire de montrer sa structure)

mysql> select * from BOXERS limit 10;
 +----+----------+------------+
 | ID | PRENOM   | NOM        |
 +----+----------+------------+
 |  1 | Muhammad | Ali        |
 |  2 | Lou      | Ambers     |
 |  3 | Vito     | Antuofermo |
 |  4 | Jorge    | Arce       |
 |  5 | Alexis   | Arguello   |
 |  6 | Henry    | Armstrong  |
 |  7 | Abe      | Attell     |
 |  8 | Monte    | Attell     |
 |  9 | Yuri     | Arbachakov |
 | 10 | Satoshi  | Aragaki    |
 +----+----------+------------+
 10 rows in set (0.03 sec)

B/ Le format LDIF d’exemple (qui permet de connaître les champs à ajouter dans la requête LDAP d’ajout, mais entendu, il faut l’adapter pour que cela colle avec le vôtre (serveur LDAP))

dn: uid=milamber,ou=Users,dc=milamberspace,dc=net
objectclass: organizationalPerson
objectclass: person
objectclass: top
objectclass: inetOrgPerson
uid: milamber
userPassword: jmeter2009
cn: milamber
mail: milamber@milamberspace.net
displayname: Milamber
givenname: Milamber
sn: Milamber

./