UserLock Documentation
UserLock Documentation
Vous êtes ici: Cas d'utilisation > Cas d'utilisation avancés > Sécuriser l'accès à distance à une boîte aux lettres Exchange (modules HTTP)

Comment sécuriser l'accès à distance à une boîte aux lettres Exchange avec UserLock (à l'aide de modules HTTP)

L’accès non autorisé à la boîte aux lettres Exchange des utilisateurs est un problème de sécurité majeur pour de nombreuses organisations.

Dans cet article, nous expliquerons comment UserLock protège l'accès à la boîte aux lettres Exchange 2013 et offre le contrôle et la visibilité sur les sessions IIS (Internet Information Sessions) pour aider à mettre un terme aux violations de sécurité.

Cette procédure s'applique également à Exchange 2010 et Exchange 2016. Pour Exchange 2016, vous trouverez une spécificité à la fin de cet article.

Déployer l'agent IIS pour surveiller et auditer l'accès aux boîtes aux lettres

Comme précédemment, nous allons effectuer notre démonstration sur un petit environnement Active Directory: Le serveur VES1 est le contrôleur de domaine sur lequel UserLock est installé. Exchange 2013 est installé sur le serveur VES2 avec le rôle d'accès client. Nous utiliserons également un poste de travail VEW1 pour accéder à une boîte aux lettres avec Outlook 2013 et OWA.

  1. Dans la vue ‘Distribution d’agents’, nous pouvons installer l’agent IIS sur le serveur VES2.

  2. La première différence que vous remarquerez est que nous devons terminer l'installation en enregistrant le filtre ISAPI (comme nous l'avons fait dans notre précédent article) ou en enregistrant le HttpModule.

  3. UserLock HttpModule est un nouvel agent permettant de contrôler les sessions IIS. L'objectif principal de ce nouvel agent est d'améliorer la compatibilité globale avec la plupart des applications Web. Avec Exchange 2013, nous obtenons un meilleur résultat avec HttpModule, nous allons donc continuer notre démonstration avec cela.

    Ensuite, basculez vers la console de gestion IIS sur le serveur VES2. À la racine du serveur, nous ouvrons les modules.

  4. Cliquez sur Configurer des modules natifs.

  5. Cliquez ensuite sur Inscrire.

  6. Spécifiez le chemin d'accès au module UserLock HttpModule situé dans le chemin suivant: c:\Windows\System32\UlHttpModule.dll.

  7. Une fois que nous avons cliqué sur OK, le module est sélectionné dans la liste des modules natifs. Si nous laissons le module sélectionné, il sera actif sur l’ensemble du serveur pour toutes les applications IIS. Nous vous recommandons de le désélectionner et de l'activer uniquement sur les applications sélectionnées.

  8. Supprimez maintenant l'agent UserLock de la liste des modules à la racine IIS. Le module restera enregistré et disponible pour la sélection dans les applications enfants.

  9. Ensuite, activez-le uniquement dans les applications OWA et Microsoft-Server-ActiveSync.

Détecter lorsqu'un utilisateur se déconnecte d'OWA

Ensuite, faisons en sorte que Bob se déconnecte d’OWA.

Si nous regardons la vue de session dans la console UserLock, nous pouvons voir que la session a disparu et que Bob n'a que sa session de poste de travail sur VEW1 toujours ouverte. UserLock peut détecter le moment où un utilisateur se déconnecte d'OWA.

Détecter les accès aux boîtes aux lettres non autorisés et fermer les sessions IIS

Maintenant, si nous laissons Bob ouvrir une session sur OWA avec les identifiants d’Alice, vous pouvez voir clairement dans la console UserLock que la session OWA d’Alice est générée à partir de l’adresse IP du poste de travail VEW1 sur lequel Bob est connecté.

Si nous sommes l’administrateur de UserLock, nous serions légitimement suspicieux en voyant Bob accéder à la boîte aux lettres d’Alice. Dans ce scénario, l'administrateur peut simplement sélectionner la session suspecte identifiée et cliquer sur fermer la session pour fermer l'accès suspect.

Restreindre l'accès aux boîtes aux lettres par adresse IP

Par mesure de précaution, l'administrateur peut créer une règle de compte protégé pour permettre à Alice de refuser les sessions IIS à partir de l'adresse 10.2.2.11.

Quel est le résultat? Lorsque Bob essaie de faire quelque chose dans OWA, il sera automatiquement redirigé vers la page de connexion:

Et si Bob essaie de se reconnecter avec les informations d'identification d’Alice sur OWA, il recevra le message de refus suivant.

Comme vous pouvez le constater, avec UserLock, un administrateur peut rapidement réagir et déconnecter un utilisateur d’une boîte aux lettres grâce à la nouvelle fonctionnalité de déconnexion de session IIS.

À propos d'Exchange 2016

La même procédure fonctionnera également sur Exchange 2016. Vous ne devez vous préoccuper que d'un seul point pour Exchange 2016.

Si vous effectuez cette procédure jusqu'à la fin, l'agent IIS sera configuré uniquement pour les applications «OWA» et «Microsoft-Server-ActiveSync».

Avec Exchange 2016, le problème est que, après toute mise à jour, tous les modules HTTP (y compris l'agent IIS) configurés uniquement dans les applications (et non au niveau racine d'IIS) seront automatiquement désactivés.

Solution de contournement

  1. Configurez l'agent HTTP UserLock IIS du module HTTP au niveau racine IIS (comme indiqué au début de l'article).

  2. Spécifiez les pools d'applications IIS à surveiller:

    • Par défaut, lorsque vous configurez l'agent IIS sur un site Web IIS, toutes les applications de ce site sont surveillées indépendamment du pool d'applications sur lequel elles s'exécutent.

    • Si nécessaire, vous pouvez choisir de surveiller uniquement les applications Web exécutées sur des pools d'applications spécifiques en créant la valeur de registre suivante (type REG_MULTI_SZ) sur le serveur IIS:

      HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock\IIS\ProtectedApplicationPools
    • Ensuite, entrez la liste de tous les pools d'applications que vous souhaitez superviser (un par ligne).

    • Sur un serveur Exchange, par exemple, de nombreuses applications Web sont créées sur le site Web "IIS Default". Si vous configurez l'agent IIS UserLock pour ce site, UserLock affichera de nombreuses sessions IIS.

    • Dans la plupart des cas, vous souhaitez uniquement contrôler les sessions à partir d'Outlook Web Access et ignorer les autres applications Web. Vous pouvez le faire en spécifiant uniquement «MSExchangeOWAAppPool» comme pool d'applications à surveiller.

    • Si Active Sync vous intéresse, ajoutez «MSExchangeSyncAppPool».

    • Exemple avec les pools d'applications «MSExchangeOWAAppPool» et «MSExchangeSyncAppPool»:

À propos des filtres ISAPI

Enfin, qu'en est-il des filtres ISAPI? La réponse est oui, avec UserLock, il est également possible de contrôler les sessions sur OWA et ActiveSync à l’aide de filtres ISAPI au lieu de modules HTTP.

S'il vous plaît voir cet article (en anglais).

Réglages avancés
Comme expliqué dans "Limitations connues et configuration additionnelles" si vous souhaitez exclure les sessions générées par des comptes Health Mailbox, veuillez configurer les paramètres avancés "IgnoredLocalUsers" et / ou "IgnoredUsers".