I. Présentation
Vous recherchez un gestionnaire de mots de passe on-premise capable de se synchroniser avec Entra ID (Azure AD) pour faciliter le partage des identifiants ? Nous avons une solution à vous proposer, elle se nomme LockPass !
Cet article doit être considéré comme une suite au premier article intitulé “LockPass : le gestionnaire de mots de passe souverain conçu pour les entreprises !” où nous avions présenté le gestionnaire de mots de passe de la société française LockSelf.
Cette fois-ci, nous prendrons un cas d’usage bien spécifique que nous pouvons résumer en plusieurs points :
LockPass sera déployé en local (on-premise) sur une machine Linux, à l’aide de Docker
LockPass sera connecté à Entra ID, lui-même associé à un tenant Microsoft 365
Les groupes Entra ID, et leurs membres, seront synchronisés dans LockPass, ce qui facilite le partage des informations. Par exemple, tous les membres du groupe Entra ID nommé “Marketing” auront accès automatiquement à un ensemble d’identifiants partagés.
La connexion unique (SSO) à l’application LockPass pour les utilisateurs Entra ID, avec la prise en charge du MFA
Nous commencerons par évoquer l’installation de LockPass et son intégration à Entra ID avant d’évoquer l’exploitation de cette interconnexion. Le déploiement on-premise de LockPass et son intégration avec Entra ID nécessite 1 heure, à condition de disposer d’un serveur prêt à l’emploi et d’un environnement Entra ID. Il conviendra d’ajouter le temps nécessaire pour sécuriser, sauvegarder et superviser le serveur LockPass, au même titre que vos autres actifs.
Ici, nous effectuerons une intégration de LockSelf avec Entra ID (Azure AD), le service de gestion des identités de Microsoft. D’autres scénarios sont pris en charge, dont :
L’intégration avec l’Active Directory, via AD FS
Les services de Google
Les services d’Okta
Le mécanisme Shibboleth
Remarque : le scénario décrit dans cet article s’applique sur les environnements Cloud et hybrides où l’Active Directory pourrait être synchronisé avec Entra ID.
👉 Vous pouvez tester gratuitement LockSelf en visitant cette page !
II. Installation on-premise de LockSelf (LockPass)
L’installation de LockPass sur une infrastructure on-premise repose sur l’utilisation de Docker. La solution LockSelf s’appuie sur 2 conteneurs, l’un correspondant à l’application en elle-même et l’autre correspondant à l’instance MySQL pour le stockage des données.
Pour effectuer ce déploiement, les administrateurs peuvent effectuer la configuration manuellement ou utiliser un script prêt à l’emploi et qui facilite grandement la tâche. Ce script Bash fait office de programmation d’installation pour automatiser le déploiement, mis à part :
L’installation du moteur Docker en lui-même (vous pouvez suivre ce tutoriel pour installer Docker).
La création du certificat TLS pour disposer d’un accès sécurisé à l’application, via HTTPS. Vous devez disposer du certificat, de la clé privée et de la chaîne de certification.
Dans le cadre de cette démonstration, le serveur est sous Debian 12. L’application LockSelf est accessible via l’adresse https://lockself.it-connect.local et le certificat TLS a été délivré par une autorité de certification d’entreprise AD CS. Il est tout à fait possible d’utiliser un nom de domaine public et d’acheter un certificat.
A. Importer l’image Docker de LockSelf
L’image Docker de l’application LockSelf est fournie par votre responsable de compte chez LockSelf. Cette image n’est pas publique, ce qui est compréhensible. Elle doit être ajoutée à votre instance Docker à l’aide de la commande docker load.
Une fois que vous aurez en votre possession l’image Docker (ou plutôt l’archive tar.gz correspondante) et qu’elle sera sur votre serveur, vous pourrez l’importer. Voici la commande à exécuter pour accomplir cette tâche :
sudo docker load –input lockself-api-1.26.12.tar.gz
Vous pouvez ensuite valider la présence de l’image via cette commande :
sudo docker image ls
Ce qui donne :
B. Lancer l’installation de LockSelf
L’installation est facilitée par le script prêt à l’emploi mis à disposition par LockSelf. Au-delà de permettre l’installation en elle-même, ce script sert aussi à relancer facilement les conteneurs ou à vérifier l’état des composants. Il a été mon allié tout au long de la mise en place de la solution.
Il est nécessaire de répondre à plusieurs questions pour accomplir l’installation, mais celle-ci est automatisée. Par exemple, vous devrez définir l’adresse URL de l’application, ainsi que les informations pour le SMTP (envoi des e-mails de l’application).
C. Obtention du certificat
Au bout d’un moment, l’installation sera “bloquée” car vous devrez déposer les fichiers de certificat. Elle peut être relancée à tout moment via le script évoqué précédemment, sans que ce soit problématique (le script a été pensé en conséquence).
L’obtention du certificat nécessite d’utiliser OpenSSL pour générer une clé privée et la demande de certificat (CSR). Nous utilisons aussi un fichier de configuration pour déclarer le SAN à inclure dans le certificat.
Voici comment générer la clé privée RSA (nécessaire pour cette application) :
openssl genrsa -out lockself.it-connect.local.key 2048
Puis, les propriétés du certificat sont inscrites dans le fichier lockself-san.cnf :
[ req ]
prompt = no
distinguished_name = dn
req_extensions = req_ext
[ dn ]
CN = lockself.it-connect.local
O = IT-Connect
L = Caen
C = FR
[ req_ext ]
subjectAltName = DNS: lockself.it-connect.local
Puis, générez le CSR (Certificate Signing Request) :
openssl req -new -key lockself.it-connect.local.key -nodes -out lockself.it-connect.local.csr -config lockself-san.cnf
Depuis le serveur distant (CA), récupérez le CSR :
scp [email protected]:/home/flo/lockself.it-connect.local.csr C:\TEMP\
Après avoir configuré le modèle de certificat sur votre autorité de certification (si vous utilisez AD CS intégrée à AD), effectuez une demande de certificat. Ici, nous utilisons le modèle publié sous le nom IT-Connect-ServeurWeb-v1 dans AD CS.
certreq -Submit -Attrib “CertificateTemplate:IT-Connect-ServeurWeb-v1” C:\TEMP\lockself.it-connect.local.csr C:\TEMP\lockself.it-connect.local.cer
Puis, envoyez le certificat sur le serveur LockSelf :
scp C:\TEMP\lockself.it-connect.local.cer [email protected]:/home/flo/
Il convient de copier également un fichier représentant la chaine de certification, c’est-à-dire un fichier CRT avec le certificat racine de l’autorité de certification et le certificat de l’application.
Ensuite, les différents fichiers doivent être copiés dans le répertoire de LockSelf. Les commandes suivantes sont donc à exécuter sur le serveur LockSelf.
# Certificat de l’application lockself.it-connect.local
sudo cp /home/flo/lockself.it-connect.local.cer /usr/local/var/lockself/ssl/sp.crt
# Clé privée associée au certificat lockself.it-connect.local
sudo cp /home/flo/lockself.it-connect.local.key /usr/local/var/lockself/ssl/ssl-certificate.key
# Chaine de certification (concaténer le certificat racine de la CA et le certificat de l’application)
sudo cp /home/flo/ssl-certificate.crt /usr/local/var/lockself/ssl/
Une fois cette opération effectuée, il est nécessaire de relancer le script d’installation pour valider la prise en charge et lancer les conteneurs. Le mode Doctor sert notamment à vérifier l’état des composants et prérequis.
D. Finaliser l’installation
Pour finir l’installation, vous devez vous connecter à l’application sur une URL spécifique dans le but de créer un compte administrateur. Ce sera aussi l’occasion de renseigner et valider votre licence LockSelf. Ensuite, vous n’aurez plus qu’à commencer à profiter de votre instance LockSelf.
III. LockSelf : mise en place du SSO avec Entra ID
L’instance LockSelf est déployée sur l’infrastructure on-premise, mais il manque encore une partie de la configuration : la synchronisation et l’authentification unique avec Entra ID (Azure AD).
A. Quels sont les bénéfices du SSO ?
L’authentification unique dans le contexte de LockSelf permet d’optimiser la gestion des accès tout en renforçant la sécurité globale de la solution.
La mise en place du Single Sign-On (SSO) permet aux utilisateurs de s’authentifier à LockSelf via leurs identifiants habituels (compte Entra ID / Microsoft 365). Ainsi, les utilisateurs n’ont pas à gérer un mot de passe supplémentaire. Cela garantit une authentification centralisée et cohérente avec les politiques de mots de passe du service de gestion des identités (complexité des mots de passe, rotation périodique, etc.). Mieux encore, la connexion via Entra ID permet d’hériter de l’authentification multifacteurs (MFA) si elle est activée et configurée (nous pouvons même imaginer 2 niveaux de MFA, si la configuration est effectuée aussi au niveau du compte LockSelf).
L’accès à l’application LockSelf devient donc implicitement conforme aux exigences internes tout en réduisant les risques liés à la gestion individuelle des identifiants.
Par ailleurs, LockSelf étant également capable de synchroniser les groupes Entra ID, cela simplifie l’administration. Un groupe présent dans Entra ID peut remonter dans LockSelf et peut se voir associer des permissions, de quoi gérer finement les accès partagés sans réinventer votre organisation.
Cette association entre les deux services a des avantages dans plusieurs scénarios :
Gestion des mouvements internes : en cas de mobilité (changement de service, promotion, etc.), les modifications de droits sont propagées automatiquement vers LockSelf, évitant les erreurs manuelles ou les oublis.
Déploiement à grande échelle : cette approche permet de gérer efficacement plusieurs centaines, voire milliers d’utilisateurs, avec un pilotage centralisé via le service de gestion des identités utilisés par l’entreprise.
Amélioration du processus d’onboarding : le provisioning des utilisateurs et des groupes simplifie l’arrivée d’un nouvel utilisateur, car son compte est automatiquement créé dans LockSelf. Il hérite directement de droits et affectations de groupes alignés sur ceux définis dans Entra ID. Ce mécanisme assure une cohérence des permissions dès le premier jour : l’utilisateur peut accéder aux catégories partagées dans LockSelf dès sa première connexion à la solution.
Passons à la mise en œuvre pratique du SSO entre LockSelf et Entra ID.
B. Entra ID : créer une nouvelle application LockSelf
À partir de l’interface d’administration Azure, vous devez déclarer une nouvelle application. Rendez-vous sur cette page et cliquez sur le bouton prévu à cet effet.
L’application LockSelf n’étant pas présente dans le catalogue de Microsoft Entra, nous allons créer une application personnalisée. Cliquez sur le bouton “Créer votre propre application” (1), attribuez-lui un nom, par exemple “LockSelf” (2), et choisissez le type “Intégrer une autre application que vous ne trouvez pas dans la galerie (non galerie)” (3). Validez avec le bouton “Créer” (4).
Dans les paramètres de l’application, cliquez ensuite sur “Authentification unique” (1), puis choisissez “SAML” (2). Vous l’aurez compris, le SSO entre les deux services sera effectué via le protocole SAML 2.0.
Vous devez commencer par indiquer les bonnes adresses pour chaque champ. Adaptez ces valeurs selon votre domaine.
Identificateur (ID d’entité) : https://lockself.it-connect.local/saml2/metadata
URL de réponse (URL Assertion Consumer Service) : https://lockself.it-connect.local/saml2/response
URL de connexion : https://localself.it-connect.local/?sso
Enregistrez quand c’est fait.
Vous devez ensuite ajouter de nouvelles revendications. Une revendication (ou claim en anglais) est une information transmise dans le jeton d’authentification émis par Entra ID lorsqu’un utilisateur s’authentifie. Ici, nous ajoutons les informations attendues par LockSelf, notamment pour l’identifiant, le nom et le prénom.
Vous devez obtenir un résultat strictement identique à celui-ci (supprimez les URL dans les revendications – La revendication “groups” est expliquée plus loin dans l’article).
Si vous envisagez de synchroniser les groupes entre Entra ID et LockSelf, vous devez ajouter une revendication de groupe en cliquant sur le bouton portant ce nom. Vous allez alors choisir “Groupes attribués à l’application” et choisir “Noms d’affichage de groupe cloud uniquement” comme attribut de la source. Ceci permet de remonter les groupes Cloud vers LockSelf (pour les groupes AD, dans un contexte hybride, la configuration est différente).
Vous devez personnaliser le nom de la revendication pour associer le nom “groups”. Ainsi, vous obtenez un résultat tel que celui-ci présenté précédemment avec la liste de tous les champs.
Vous venez de créer l’application et de configurer l’authentification unique.
C. Entra ID : sélectionner les groupes d’utilisateurs
Cette étape consiste à préciser quels sont les groupes (ou les utilisateurs) à accéder à cette application. Autrement dit, quels sont les utilisateurs autorisés à se connecter à LockSelf, et donc à créer un compte. Si vous spécifiez des groupes, ce qui est une bonne pratique, les membres de ces groupes seront pris en compte.
Toujours dans la gestion de votre application, cliquez sur “Utilisateurs et groupes” (1) à gauche, puis sur le bouton “Ajouter un utilisateur/groupe” (2).
Dans le cadre de cette démonstration, trois groupes sont sélectionnés : Service_IT, Service_Marketing, Service_RH. Nous verrons par la suite si la synchronisation est opérationnelle.
D. Configurer le SSO dans LockSelf
La suite des opérations s’effectue sur l’interface de LockSelf. Via la section “Paramètres”, il convient de lancer l’assistant de configuration du SSO. L’accès à cette fonctionnalité implique que ce soit activé dans votre licence.
Vous devez alors copier l’URL permettant de solliciter l’authentification basée sur SAML, à partir des détails de votre application Azure.
Cette URL, correspondante à l’IdP, doit être collée dans le champ prévu à cet effet avant de poursuivre. L’IdP, ou Identity Provider (fournisseur d’identité en français), est un composant ou un service qui gère l’authentification des utilisateurs et fournit les informations nécessaires (revendications) à une application tierce lors du processus de connexion. En l’occurrence dans notre contexte, l’IdP est Entra ID tandis que l’application est LockSelf.
Un connecteur sera créé (ce qui fait écho à l’URL configurée précédemment côté Azure). Cliquez simplement sur le bouton “Étape suivante”.
Voilà, désormais, c’est l’heure de vérité ! Cliquez sur le bouton “Lancer le test”. Cela va ouvrir un nouvel onglet dans votre navigateur.
La page de connexion Microsoft apparaît à l’écran. Connectez-vous avec un compte Entra ID membre d’un groupe autorisé. Ici, l’utilisateur Guy Mauve membre du groupe Service_RH (et cobaye habituel) est utilisé pour faire le test. La réponse SAML est très explicite et montre bien que les informations ont été récupérées. Il est important de vérifier que la propriété lockself_errors ne contiennent pas d’erreurs (ce qui peut être le cas si vos revendications sont mal configurées).
L’authentification unique est correctement configurée !
E. Le SSO en pratique
La configuration peut désormais être testée en conditions réelles, dans la peau d’un utilisateur. Nous reprendrons le même utilisateur que précédemment, mais cette fois-ci, nous allons tenter une connexion à l’application LockSelf en mode “SSO”.
Nous sommes redirigés vers la page de connexion de Microsoft. Il convient alors de saisir les identifiants du compte.
Puis, nous revenons sur l’interface de LockSelf. Puisqu’il s’agit de la première connexion, l’utilisateur doit créer un code PIN.
Quelques secondes plus tard, l’utilisateur dispose d’un accès à son coffre-fort LockSelf, grâce à son compte Entra ID. Libre à lui de commencer à stocker ses premiers identifiants dans son espace personnel.
F. La synchronisation des groupes
Suite à sa connexion à LockSelf, l’utilisateur Guy Mauve a bien été provisionné dans l’application. Néanmoins, ce n’est pas le cas du groupe Service_RH auquel il appartient. En effet, la configuration actuelle n’est pas suffisante pour configurer les groupes.
Sur le serveur LockSelf, vous devez éditer le fichier de configuration /usr/local/var/lockself/env pour ajuster 2 directives :
intercoAd=1 : le fait de passer cette option à 1 au lieu de 0 sert à activer la synchronisation des groupes.
intercoAdPrefix=’Service_’ : le fait de configurer cette option sert à spécifier que nous autorisons uniquement la synchronisation des groupes dont le nom contient le préfixe Service_.
Quand c’est fait, il est nécessaire d’exécuter le script de gestion de LockSelf (utilisé pour l’installation initiale) dans le but de relancer le conteneur applicatif via l’option 5.
Lors de la prochaine connexion / déconnexion de l’utilisateur Guy Mauve, le groupe Service_RH sera synchronisé avec LockSelf. Voyez par vous-même :
Ce comportement s’explique par la présence de cet utilisateur dans le groupe Service_RH. Maintenant, en tant qu’administrateur, vous pouvez associer des permissions sur Service_RH, au niveau de l’espace partagé.
IV. La gestion des accès
La synchronisation des groupes Entra ID dans LockSelf facilite la gestion des permissions. En effet, les administrateurs peuvent appliquer des permissions directement sur les groupes synchronisés, sans avoir à recréer des configurations manuellement dans LockPass. Cela permet de simplifier l’administration des accès, notamment en offrant une gestion centralisée des autorisations d’accès aux catégories partagées.
Par exemple, si nous créons une catégorie partagée nommée “Service_RH” dans LockPass et que nous donnons l’accès au groupe éponyme sur cette catégorie, alors les utilisateurs membres de ce groupe y auront accès. Un groupe (ou bien une personne spécifique) peut être nommé en tant qu’utilisateur simple ou en tant que gestionnaire de catégorie (disposant de droits de suppression / modifications des accès de la catégorie).
Suite à la configuration évoquée ci-dessus, l’utilisateur Guy Mauve dispose bien d’un accès à la catégorie partagée Service_RH puisqu’il est membre du groupe Service_RH. À noter : le nom de la catégorie ne doit pas forcément correspondre au nom du groupe, vous êtes libre d’indiquer la valeur que vous souhaitez.
Lorsqu’un utilisateur est supprimé, désactivé ou verrouillé dans Entra ID, il perd immédiatement l’accès à l’application LockSelf. Cette gestion dynamique des accès renforce la sécurité en garantissant que les utilisateurs sortis du système (ou victime d’une tentative de compromission de compte) ne puissent plus utiliser l’application. Néanmoins, il est toujours possible d’avoir des comptes locaux sur LockSelf, ce qui sera utile pour avoir un compte bris de glace ou encore pour certains comptes (prestataires externes, par exemple).
Vous pouvez suivre facilement les accès des utilisateurs et générer des rapports détaillés sur les droits d’accès via l’interface de LockSelf. En complément, vous pouvez compter sur les journaux d’Entra ID pour savoir quand un utilisateur s’est authentifié via l’application LockSelf. Cela assure une traçabilité des événements et des actions pour répondre aux besoins de sécurité.
Cette gestion cohérente des accès renforce l’intérêt d’effectuer une intégration avec un service de gestion des identités.
V. Conclusion
L’authentification unique (SSO) et la synchronisation native avec Entra ID démontrent que LockPass est un gestionnaire de mots de passe conçu pour répondre aux exigences et aux besoins des entreprises. Cette intégration simplifie le déploiement de LockSelf au sein d’un système d’information existant, tout en offrant à l’utilisateur une expérience unifiée : il accède à la plateforme avec ses identifiants habituels, sans avoir à gérer un compte supplémentaire.
Dès sa première connexion, l’utilisateur est immédiatement opérationnel : il accède automatiquement aux catégories partagées qui lui sont destinées, sans intervention manuelle de l’administrateur.
Ici, nous avons pris l’exemple d’Entra ID (Azure AD), mais je tiens à rappeler que d’autres services sont pris en charge : Active Directory (via AD FS ou en mode hybride avec Entra ID), Google, Okta et Shibboleth.
Pour aller plus loin : cet article étant centré sur l’installation on-premise de LockSelf et son intégration avec Entra ID, je vous recommande vivement de consulter notre premier contenu dédié à LockSelf afin d’obtenir une vue d’ensemble des fonctionnalités proposées.
Cet article contient une communication commerciale pour LockSelf.
Ingénieur système et réseau, cofondateur d’IT-Connect et Microsoft MVP “Cloud and Datacenter Management”. Je souhaite partager mon expérience et mes découvertes au travers de mes articles. Généraliste avec une attirance particulière pour les solutions Microsoft et le scripting. Bonne lecture.