Agents

L'agent Station UserLock est conçu pour auditer, contrôler et protéger les postes de travail stations, serveurs et serveurs de terminaux. Il a pour but d'auditer toute l'activité des sessions interactives sur ce type de machines et de protéger leurs accès en appliquant les stratégies d'accès définies.

Cet agent doit être installé sur les machines et communique avec les serveurs UserLock pour réguler les demandes d'ouvertures des sessions interactives.

Depuis la version 12.2, UserLock a intégré un fournisseur d'informations d'identification qui permet au service d'interagir avec la connexion Windows avant que la session ne soit ouverte.

Le fournisseur d'informations d'identification est une DLL qui désactive le fournisseur d'informations d'identification Microsoft PasswordCredentialProvider afin qu'il ne soit pas affiché pour l'utilisateur.

Si vous utilisez d'autres fournisseurs d'informations d'identification, le fournisseur d'informations d'identification UserLock pourrait ne pas être utilisé, auquel cas la protection UserLock serait fournie par l'ancienne technologie d'agent UserLock.

• Lorsque l'utilisateur se connecte avec ses identifiants Windows, le fournisseur d'identifiants UserLock vérifie dans Active Directory si l'utilisateur est autorisé à se connecter.

• Si l'utilisateur est refusé par Active Directory, l'événement est enregistré dans UserLock.

• Si la connexion est autorisée, le fournisseur d'informations d'identification contacte le serveur UserLock pour vérifier si les politiques UserLock autorisent l'utilisateur à se connecter.

• Si l'utilisateur est refusé par UserLock, l'événement est enregistré dans UserLock et la connexion est refusée.

• Si l'utilisateur doit être inscrit à la MFA, les boîtes de dialogue d'inscription ne sont pas affichées par le fournisseur d'informations d'identification (cette technologie offre très peu de possibilités d'interface graphique), mais par la partie du processus de connexion de l'agent qui prend en charge la gestion de l'inscription.

• Si le serveur UserLock n'est pas accessible, le fournisseur d'informations d'identification gère la MFA hors ligne conformément aux paramètres définis dans Connexions hors réseau.
  

Lorsque le mot de passe d'un utilisateur expire, le processus suivant est requis si l'authentification multifacteur est configurée

1. Détection d'expiration du mot de passe : lors de la connexion, le système détecte un mot de passe expiré et demande un changement.

2. Validation de l'authentification multifacteur : si l'authentification multifacteur est activée, l'utilisateur doit valider avec succès son authentification multifacteur (par exemple, OTP, application d'authentification) avant de pouvoir modifier son mot de passe.

3. Échec de validation : si la validation de l'authentification multifacteur échoue, l'utilisateur ne peut pas procéder au changement de mot de passe.

4. Changement de mot de passe : après une authentification multifacteur réussie, l'utilisateur peut modifier son mot de passe en suivant les règles de complexité définies.

Cela garantit des mises à jour de mot de passe sécurisées lorsque l'authentification multifacteur est en place.

L'agent Station est un service Windows configuré pour s'exécuter en tant que Système local.

Lorsqu'une session a été autorisée par l'authentification Windows, le système démarre le processus UserInit pour initialiser la session. UserLock configure le système pour démarrer son propre exécutable 'ULAgentExe.exe' à la place. Ce programme demande au serveur UserLock si la session est autorisée par les stratégies d'accès définies. Si la session est autorisée, le processus UserInit sera lancé pour initialiser normalement la session. Dans le cas contraire la session est fermée.

Le serveur Principal UserLock déploie en continue son adresse réseau ainsi que celle de son serveur de Sauvegarde auprès de tous ces agents. Les agents sont alors en mesure de contacter les serveurs UserLock sans rencontrer de difficultés.

L'agent station essaie de contacter le serveur dans l'ordre des adresses suivantes :

1. Le serveur UserLock Principal (adresse déployée par le serveur).

2. L'adresse du dernier serveur ayant été contacté avec succès.

3. L'adresse du serveur de Sauvegarde (adresse déployée par le serveur) si différente du dernier serveur contacté avec succès.

4. Si aucun nom de serveur UserLock principal n'est déployé (dans Winlogon ou GPO), un serveur nommé UserLock. Afin d'utiliser ce dispositif, vous devez juste ajouter une entrée dans votre DNS pour lier le nom UserLock à votre serveur UserLock.

5. Si aucun nom de serveur UserLock principal n'est déployé (dans Winlogon ou GPO), un serveur nommé UserLockBackup (Cf. ligne précédente).

L'agent station essaie dans un premier temps (avant d'initier la communication) de faire un ping sur le serveur. Le protocole ICMP doit donc être autorisé entre les clients et les serveurs UserLock.

L'agent station communique avec le serveur UserLock avec le protocole Partage des fichiers et imprimantes pour les réseaux Microsoft (SMB TCP 445). Typiquement les stations clientes doivent être en mesure d'accéder aux partages sur les serveurs UserLock.

En cas d'échec de connexion en utilisant la procédure listée ci-dessus, il est possible d'utiliser une méthode alternative où l'agent contacte le service via Internet. Cette fonctionalité s'appelle UserLock Anywhere.

Vous pouvez implémenter cette option en suivant ce guide.

Sur un serveur Windows le service Network Policy Service (NPS) permet d'authentifier les utilisateurs avec le protocole RADIUS. Ce protocole est utilisé par les routeurs matériel pour authentifier les utilisateurs clients de VPN et par les points d'accès Wi-Fi pour authentifier les utilisateurs Wi-Fi.

UserLock peut auditer, contrôler et appliquer une politique de restriction utilisateur sur les sessions Wi-Fi et VPN utilisant cette architecture IAS à l'aide de l'agent UserLock NPS. Cet agent est conçu pour être chargé dans le service Microsoft NPS.

UserLock ne déploie pas automatiquement ce type d'agent. Il peut être déployer manuellement dans la console ou par copie de fichier.

L'agent NPS est une DLL d'extension du Network Policy Server Microsoft enregistrée dans le dit service.

Cette DLL est appelée à chaque fois qu'un utilisateur doit être authentifié par le service NPS (authentification RADIUS) et lorsqu'une session est ouverte ou fermée ( technologie RADIUS accounting). Vous trouverez plus d'information sur cette technologie sur la page suivante du MSDN :
http://msdn.microsoft.com/en-us/library/bb891989(VS.85).aspx

Étant donné que tous les points d'accès Wi-Fi ne sont pas entièrement conformes à la norme RADIUS et ne notifient pas toujours les déconnexions Wi-Fi, il est possible qu'une même session (le même compte d'utilisateur, le même appareil, éventuellement le même point d'accès Wi-Fi) apparaisse plusieurs fois dans les données UserLock.

Nous avons créé 2 options dans l'agent NPS UserLock pour éviter ceci:

1. Dans votre ou vos serveurs NPS, lancez RegEdit, parcourez la clé de registre suivante : HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IAS

2. Créez ensuite la valeur DWORD 32 bits AutoResetPreviousSessionSameData, mettez 0 ou 1 dans son contenu.

3. Optionnellement, définissez la valeur AutoResetPreviousSessionSameDataAndWap et mettez 0 ou 1 dans son contenu. (voir les différents comportements ci-dessous):

UserLock peut auditer, contrôler et appliquer des règles d'accès utilisateur sur les sessions Internet Information Services (IIS). Vous devez installer l'agent IIS UserLock sur le serveur hébergeant l'application Web cible pour superviser les sessions Internet Information Services (IIS) de celle-ci.

L'agent IIS a été spécifiquement conçu pour être chargé dans le service Microsoft Internet Information Services (IIS). Il est compatible uniquement avec les applications IIS configurées avec les modes d'authentification Authentification Windows, Authentification par formulaire ou Authentification de base.

UserLock peut auditer, contrôler et appliquer des règles d'accès utilisateur sur les sessions Internet Information Services (IIS).  Cette fonctionnalité vous permet de définir un nombre maximum de sessions IIS simultanées pour une application IIS spécifique comme Outlook Web Access ou un Site Intranet. Il est également possible de générer des rapports pour ce type de session à l'aide des événements d'accès IIS enregistrés dans la base de données UserLock. Afin de contrôler les sessions de type IIS, vous devez déployer et configurer l'agent IIS sur le serveur IIS ciblé.

Le moteur de déploiement de la vue Distribution de l'agent détecte automatiquement les serveurs sur lesquels le service Internet Information Services (IIS) est installé et démarré. Pour déployer l'agent IIS, il suffit de consulter ce guide.

L'agent IIS est un module HTTP. Le module HTTP est la technologie introduite et supportée par IIS 7 et supérieur. Celle-ci permet de superviser et protéger une seule application Web ciblée.

A bien des égards, la technologie HttpModule ressemble à un amalgame des technologies utilisées par les développeurs logiciel pour créer des module HTTP ASP.NET gérés et leurs extensions dans les versions précédentes de IIS' (source MSDN).

Pour les requêtes d'authentification, l'agent IIS demande au serveur Principal UserLock si la connexion peut être autorisée ou si celle-ci doit être refusée. Dans le cas d'une réponse négative, une page d'erreur HTML spécifique est affichée à l'utilisateur. 

L'agent UserLock IIS est capable de détecter une fermeture de session IIS depuis une application Web disposant d'un bouton de déconnexion affiché dans le navigateur (e.g. Outlook Web Access). Seul ce moyen de déconnexion sera détecté par UserLock pour identifier la fermeture de session IIS: si l'utilisateur ferme brutalement le navigateur Web sans avoir au préalable cliqué sur ce bouton de déconnexion, UserLock ne pourra pas détecter la fermeture de session puisqu'aucune requête de déconnexion n'aura été transmise au serveur IIS. Par conséquent, UserLock, ainsi que le serveur IIS continueront de considérer la session comme ouverte.

L'agent IIS considèrera une session comme fermée lorsqu’une certaine limite de durée d'inactivité est atteinte. Par défaut, cette limite est définie à 5 minutes (voir la section suivante pour plus de détails).

Si un utilisateur limité à une seule session IIS par les stratégies d’accès essaie d'accéder à une application Web depuis un autre poste alors que cette limite d’inactivité n'est pas encore atteinte sur son poste précédent, UserLock verra la première connexion comme encore active et refusera donc la nouvelle connexion.

Si aucune règle de contrôle d'accès n'a été configurée concernant les sessions IIS pour ce compte utilisateur dans les comptes protégés, une nouvelle session IIS pourra être ouverte.

Nous conseillons de configurer convenablement les règles d’accès et d’ajuster la limite d’inactivité si besoin.

Il est aussi possible de fermer une session IIS directement depuis la console UserLock. Si un opérateur détecte une session IIS présentant un risque de sécurité interne, il peut initier la fermeture de celle-ci immédiatement depuis les vues Activité.

Comme indiqué précédemment, une session IIS sera automatiquement considérée comme fermée par UserLock après une certaine durée d'inactivité. Par défaut cette limite est fixée à 5 minutes, mais elle est personnalisable.

Pour la changer, créez d’abord une valeur de clé de Registre spécifique sur le serveur IIS protégé :
HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\SessionTimeout (REG_DWORD)

Saisissez ensuite la valeur souhaitée en minutes, par exemple 10.

Toutes les sessions IIS sans activité pendant 10 minutes seront alors considérées comme fermées par UserLock.

Lorsque vous configurez l'agent IIS utilisant la technologie des Filtres ISAPI sur un site Web, toutes les applications de ce Site seront surveillées par défaut, indépendamment des Pools d'application sur lesquelles elles fonctionnent.

Si cela est nécessaire, vous pouvez choisir les Applications Web que vous souhaitez superviser sur un Pool d'application spécifique. Pour cela, vous pouvez créer une valeur de clé de Registre spécifique sur le serveur IIS protégé :
HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\ProtectedApplicationPools (REG_MULTI_SZ)

Entrez ensuite la liste des Pools d'application à protéger (un par ligne).

Sur un serveur Exchange par exemple, plusieurs Applications Web sont créées dans le Site Web par défaut. Si vous configurez l'agent IIS pour ce Site, UserLock identifiera de très nombreuses sessions IIS. Pour ne contrôler que les sessions IIS de Outlook Web Access, il vous suffit alors de spécifier dans cette valeur de clé de registre seulement MSExchangeOWAAppPool comme Pool à protéger.

Par défaut, lorsque vous configurer l'agent IIS UserLock pour protéger une Application Web, tous les utilisateurs de cette application Web seront supervisés. Malheureusement certaines application Web possèdent des comptes natifs built-in utilisés lors de diagnostics ou d'opérations de maintenance internes. Ces comptes utilisateurs prédéfinis peuvent créer par le biais de leur activité un grand nombre d'entrées dans l'historique conservé en base de données, dégradant ainsi les performances et la lisibilité des rapports. Les comptes utilisateurs des Health mailboxes de Microsoft Outlook Web Access 2013 en sont un bon exemple.

Si besoin vous pouvez ignorer ces comptes utilisateurs en créant les valeurs de registre suivantes dans la clé de registre de votre serveur IIS :

HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS

• IgnoredUsers (REG_MULTI_SZ) : La liste des comptes que vous souhaitez ignorer en utilisant la syntaxe Domain\user_account (un compte par ligne). 

• IgnoredLocalUsers (REG_MULTI_SZ) : la liste des comptes que vous souhaitez ignorer uniquement pour les requêtes locales, c'est-à-dire les requêtes envoyées depuis le serveur IIS lui-même.

• IgnoredUsersPattern (REG_MULTI_SZ) : la liste des comptes avec un modèle de nom que vous souhaitez ignorer. Vous pouvez définir des modèles avec le caractère "*" comme caractère générique.
  Ce caractère peut être le premier, le dernier ou les deux. Les modèles ne sont pas sensibles à la casse.

  Exemples:

  • Avec le modèle DOMAIN\J*, tous les utilisateurs DOMAIN dont le nom commence par un "J" seront ignorés.

  • Avec le modèle *Admin, tous les comptes dont le nom se termine par Admin seront ignorés.

• ProtectHealthmailboxSessions (REG_DWORD) : définissez cette valeur à 1 pour activer l'audit des sessions HealthMailbox.

Vous devrez redémarrer les Pools d'application protégés par l'agent IIS pour que ces changements soient effectifs.

UserLock différenciera une session IIS d'une autre session IIS existantes si celle-ci est relative à :

• un Site Web différent

• un compte utilisateur différent

• une adresse IP cliente différente

• un Pool d'Application différent

Et ceci indépendamment de l'utilisation de différents navigateurs Web.

L'agent UserLock audite les sessions IIS authentifiée à l'aide de cookie. C'est pourquoi il est nécessaire d'autoriser les cookies sur tous les navigateurs clients et d'activer l'option de suppressions des cookies à la fermeture.

Le nom de la session IIS affiché dans la console UserLock est composé :

• du nome du serveur IIS

• du nom de l'application Web (si différent de l'application root du Site)

• de l'adresse IP du client

Enfin, le nom de l'application Web affiché est la première application sur lequel l'utilisateur s'est connecté. Si d'autres applications Web ont été lancées depuis, le nom de la session Web ne sera modifié (sauf si UserLock considère cette connexion comme une nouvelle session).

Le HttpModule peut désormais être utilisé à la fois pour l'authentification Windows et Forms avec des applications IIS utilisant les deux types d'authentification. Par défaut, l'authentification Windows est activée.

L'activation du nouveau mode est possible en créant une valeur de Registre spécifique de type DWORD EnableFormsAuthentication et en définissant la valeur de Registre sur 1 sur le serveur IIS protégé dans le chemin suivant:

HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\

Vous devrez redémarrer / recycler le pool d'applications pour appliquer la modification.