--- locale: "fr" updated_at: "2025-10-27T14:34:52.094Z" canonical: "https://www.isdecisions.com/fr/userlock/docs/guides/configuration/configurer-authentification-certificat-client-userlock-anywhere" --- # Configurer l’authentification par certificat client dans UserLock Anywhere Remplacer l'authentification NTLM. ## Introduction Lorsqu’un agent distant se connecte à **UserLock Anywhere**, il utilise par défaut le protocole **NTLM** pour s’authentifier, car aucun contrôleur de domaine n’est accessible en dehors du réseau, et **Kerberos** ne peut donc pas être utilisé. Cependant, NTLM est désormais considéré comme obsolète et moins sécurisé. À partir de **UserLock 13.0**, il est possible d’utiliser une **authentification basée sur certificat client**, permettant aux agents de s’authentifier de manière sécurisée grâce à un **certificat d’ordinateur** émis par votre **autorité de certification Active Directory (CA)** et déployé via **les stratégies de groupe (GPO)**. Ce guide explique comment activer et configurer cette méthode d’authentification dans IIS pour UserLock Anywhere. ## Prérequis Avant de commencer, assurez-vous que les conditions suivantes sont réunies : - ✅** **[UserLock Anywhere](/userlock/docs/reference/modules/userlock-anywhere) est déjà installé et fonctionnel. - ✅ Les [agents UserLock](/userlock/docs/reference/concepts-fondamentaux/agents) sont mis à jour en **version 13.0 ou supérieure**. - ✅ Tous les ordinateurs portables disposent d’un **certificat d’ordinateur** dans le **magasin de certificats de l’ordinateur local**. ![](https://a.storyblok.com/f/122374/638x522/c3474cbc9a/computer-certificate.png) - ✅ Si vos utilisateurs se connectent via **UserLock VPN Connect**, chacun doit également posséder un **certificat utilisateur** dans son **magasin de certificats personnel**. ![](https://a.storyblok.com/f/122374/655x522/da63738ebc/user-certificate.png) - ✅ Vous connaissez les principes de déploiement d’une autorité de certification AD et de distribution de certificats par GPO. Pour plus de détails, consultez la documentation Microsoft sur l’installation d’une autorité de certification Active Directory et le déploiement de certificats. ## Étape 1 – Imposer l’utilisation des certificats clients 1. Sur le serveur IIS hébergeant **UserLock Anywhere**, ouvrez les **paramètres SSL** de l’application **ulproxy** : - Activez **Require SSL**. - Réglez **Client Certificates** sur **Accept**. ![](https://a.storyblok.com/f/122374/705x499/876937a918/anywhere-ssl-settinqs.png) ![](https://a.storyblok.com/f/122374/649x498/b0e998602c/anywhere-accept-client-certificates.png) 2. Patientez jusqu’à ce que plusieurs connexions depuis l'extérieur (hors réseau) et sessions VPN soient ouvertes afin de générer de l’activité dans UserLock Anywhere. 3. Vérifiez le comportement des agents en accédant à la page de statistiques des certificats : `https://hostname/ulproxy/certificate-stats` (Remplacez `hostname` par le nom de votre serveur.) ![](https://a.storyblok.com/f/122374/494x188/71e9d92e15/anywhere-client-certificate-statistics.png) 4. Attendez que la valeur **Without certificate = 0** soit stable pendant une période suffisante. Vous pouvez réinitialiser les statistiques en recyclant le **pool d’applications UserLockProxyAppPool**, ou ajuster ses options de recyclage pour conserver les données plus longtemps. 5. Une fois que tous les agents envoient bien leur certificat, modifiez la configuration IIS pour **exiger le certificat client (Require)**. ![](https://a.storyblok.com/f/122374/638x460/09541c1fd6/anywhere-require-client-certificates.png) Vous êtes maintenant certain que tous les agents envoient un certificat client à UserLock Anywhere. > **Note** > > 💡 **Optionnel :** Vous pouvez aussi restreindre l’accès à UserLock Anywhere uniquement aux ordinateurs de confiance (voir la section [Configuration optionnelle](#configuration-optionnelle--restreindre-lacc%C3%A8s-aux-certificats-de-confiance)). ## Étape 2 – Installer et activer l’authentification par certificat client AD 1. Installez la fonctionnalité **Active Directory Client Certificate Authentication** dans IIS en executant la commande Powershell suivante: ``` Install-WindowsFeature Web-Client-Auth ``` 2. Dans **IIS Manager**, au **niveau du serveur**, ouvrez la section **Authentication** et activez : - **Active Directory Client Certificate Authentication** ![](https://a.storyblok.com/f/122374/477x483/1f56c2ce37/iis-root-authentication.png) ![](https://a.storyblok.com/f/122374/831x357/27f12cf6ed/iis-root-client-certificate-authentication.png) 3. Dans l’application **ulproxy** : - Ouvrez **Configuration Editor**. ![](https://a.storyblok.com/f/122374/500x627/c1748d5ea4/anywhere-configuration-editor.png) - Définissez : `system.webServer > security > authentication > clientCertificateMappingAuthentication = true` ![](https://a.storyblok.com/f/122374/471x343/9dc3c18e51/anywhere-client-certificate-mapping.png) ![](https://a.storyblok.com/f/122374/1061x478/e770c300e5/anywhere-client-certificate-mapping-enable.png) 4. Attendez de nouvelles connexions distantes pour générer des événements d’authentification. 5. Vérifiez les statistiques d’authentification : `https://hostname/ulproxy/auth-stats` ![](https://a.storyblok.com/f/122374/483x185/8e92e0d920/anywhere-authentication-statistics.png) 6. Lorsque le seul package d’authentification affiché est **SSL/PCT**, cela signifie que **NTLM n’est plus utilisé**. Vous pouvez alors : - Désactiver **Windows Authentication** dans IIS pour l’application **ulproxy**, ou - Désactiver **NTLM** globalement sur le serveur (voir la documentation Microsoft). ![](https://a.storyblok.com/f/122374/887x470/addc27fbb8/anywhere-disable-windows-authentication.png) ## Dépannage ### Problème 1 – L’authentification par certificat client ne fonctionne pas (DS Mapper Usage désactivé) Dans certains cas, la fonctionnalité **Authentification par certificat client Active Directory** ne fonctionne pas après son activation, car la **liaison SSL HTTP** n’est pas configurée avec l’option requise **DS Mapper Usage**. 1. Pour vérifier ce paramètre, ouvrez une **invite de commandes en tant qu’administrateur** et exécutez: `netsh http show sslcert` 2. Vous devriez obtenir un résultat similaire à : ![](https://a.storyblok.com/f/122374/649x388/e5797b45df/ds-mapper-usage.png) 3. Si le champ **DS Mapper Usage** est défini sur **Disabled**, activez-le manuellement avec la commande suivante (en adaptant les valeurs à votre environnement) : ```powershell netsh http update sslcert ipport=0.0.0.0:443 certhash=be642440a12cf93768ce6d269115a5ce30590c26 appid={4dc3e181-e14b-4a21-b022-59fc669b0914} certstorename=My dsmapperusage=enable ``` ⚠ **Important :** - Remplacez les valeurs `ipport`, `certhash`, `appid` et `certstorename` par celles correspondant à votre site. - Dans certains cas, des paramètres supplémentaires peuvent être nécessaires pour conserver d’autres réglages de la liaison. Pour afficher toutes les options disponibles : ``` netsh http update sslcert help ``` - Après exécution, vérifiez la configuration avec : ``` netsh http show sslcert ``` afin de vous assurer que les autres paramètres n’ont pas été modifiés. Une fois **DS Mapper Usage** activé, redémarrez **IIS** et testez à nouveau l’authentification. ### Problème 2 – NTLM apparaît encore dans les statistiques d’authentification Il est possible que **NTLM** continue d’apparaître dans les statistiques, même si l’authentification par certificat client est bien active. Cela se produit lorsque l’agent UserLock envoie encore l’en-tête NTLM, même s’il n’est plus requis. Pour vérifier ce comportement : 1. Ouvrez la **stratégie de sécurité locale** sur le serveur IIS. 2. Activez l’audit des **ouvertures de session** dans : *Paramètres de sécurité → Stratégies locales → Stratégie d’audit.* 3. Reproduisez une connexion depuis un ordinateur distant. 4. Dans le **journal de sécurité Windows**, recherchez les événements **ID 4624** associés au compte d’ordinateur accédant à UserLock Anywhere. Vous devriez observer **deux événements de connexion** pour chaque tentative : | **Package d’authentification** | **Processus de connexion** | **Description** | | --- | --- | --- | | NTLM | - | L’agent envoie encore l’en-tête NTLM standard | | Kerberos | Schannel | Authentification par certificat client active | Si ces deux événements apparaissent, cela confirme que **l’authentification par certificat client fonctionne correctement**. Vous pouvez alors désactiver **NTLM** dans IIS ou sur l’ensemble du serveur (voir la documentation Microsoft). ## Configuration optionnelle – Restreindre l’accès aux certificats de confiance Une fois l’étape 1 terminée, les clients sans certificat valide sont rejetés. Vous pouvez aller plus loin en autorisant uniquement les certificats émis par **votre autorité de certification Active Directory** (principe de « Zero Trust »). 1. Ajoutez le **certificat de votre autorité de certification (CA)** dans le magasin **Client Authentication Issuers** du serveur IIS hébergeant UserLock Anywhere. ![](https://a.storyblok.com/f/122374/689x334/dbe572b67b/client-authentication-issuers.PNG) 2. Mettez à jour la liaison IIS pour y faire référence : ``` netsh http update sslcert ipport=0.0.0.0:443 certhash= appid={} certstorename=My sslctlstorename=ClientAuthIssuer dsmapperusage=enable ``` > **Note** > > Soyez prudent lorsque vous exécutez cette commande. Lisez la section précédente consacrée au dépannage pour plus d'informations sur la manière de l'exécuter et veillez à ne commettre aucune erreur. 3. Activez le filtrage des autorités de confiance via le registre : `REG ADD "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel" /v SendTrustedIssuerList /t REG_DWORD /d 1` 4. Redémarrez le serveur IIS. Après cette configuration, seuls les ordinateurs appartenant à votre domaine Active Directory pourront accéder à UserLock Anywhere. 🔗 Voir aussi : [Présentation technique de Schannel SSP (Microsoft Learn)](https://learn.microsoft.com/fr-fr/windows/win32/secauthn/schannel-ssp-technical-overview)