Limitations connues et configuration additionnelles
Fermeture d'une session IIS
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 règles d’accès de son compte protégé 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 dans les Comptes protégé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 la vue 'Sessions utilisateur'.
Limite de durée d'inactivité des Sessions IIS
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.
Important ! Si vous diminuez de manière trop importante cette valeur, de nombreux événements d'ouverture et de fermeture de session seront générés dans l'historique des sessions dans UserLock.
Spécifier le Pool d'application IIS à surveiller avec l'agent UserLock IIS utilisant les Filtres ISAPI
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.
Remarque : En utilisant la version HttpModule de l'agent IIS UserLock, il n'est pas nécessaire d'avoir recours à cette configuration avancée. La technologie utilisant HttpModule permet une plus grande granularité dans la configuration de la protection que la technologie basée sur les Filtres ISAPI. Cette configuration est directement effectuée au niveau de l'application Web, rendant cette configuration avancée inutile.
Ignorer des comptes spécifiques
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 template "*HealthMailbox*", toutes les Exchange HealthMailboxes seront ignorées (ce template est actif par défaut, pas besoin de l'ajouter spécifiquement).
- 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.
Pools d'Application, Site Web IIS, cookies et navigateurs Web
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).
Formulaires et authentification Windows à l'aide du module HTTP
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.