UTM Authentification

Introduction

Pourquoi ?

Ce chapitre se concentre sur la configuration des différentes méthodes d’authentification des utilisateurs avec l’UTM. Les trois piliers fondamentaux pour la gestion des accès aux systèmes et ressources d’un SI repose sur le concept AAA (Authentication, Authorization and Accounting). Ce concept centralise les points suivants :

Point d’accès (Hotspot)

Pourquoi ?

Les points d’accès (hotspots) sont généralement utilisés pour contrôler les accès des utilisateurs ne faisant pas partie de votre SI (communément appelés les invités ou guests). Cette fonction permet d’afficher un portail captif sur l’interface sélectionnée de l’UTM (filaires ou Wi-Fi). Le portail dit captif s’ouvre automatiquement quand un utilisateur veut se connecter sur Internet avec un navigateur. Deux réglages sont possibles pour l’authentification :

L’option Walled Garden du hotspot permet à l’utilisateur de naviguer sur des sites (des listes d’IP, des noms de domaine) validés par l’administrateur, cela sans avoir à s’authentifier au préalable.

Informations

Vous trouverez ci-dessous les choses à savoir avant le déploiement du hotspot.

Mise en place du portail captif

Sur chaque interface de votre UTM (sauf externe) vous pouvez placer un hotspot. Cependant, nous vous recommandons de ne pas placer de hotspot sur l’interface Trusted mais plutôt d’utiliser des interfaces personnalisées ou optionnelles. Une fois appliqué sur l’interface de l’UTM, le portail s’applique à toutes les connexions.

Si vous utilisez Utilisateur avec informations d’authentification, il faut créer un compte Admin invité pour :

Par défaut, il y a une limite max de deux mille utilisateurs invités sur le portail (possibilité de configurer jusqu’à 6000).

Comportement une fois la mise en place du portail captif avec stratégie Allow Hotspot-Users

Une fois le hotspot activé sur une interface, l’utilisateur doit obligatoirement valider un agreement ou un ID + mot de passe guest...

Serveurs d’authentification

Pourquoi ?

La cybersécurité du SI passe par une infrastructure de sécurité du type AAA. Cela consiste à centraliser les comptes utilisateurs ou identités (ID) du système d’information (SI) dans un annuaire (ADDS) ou encore une base de données (firebox-DB) afin d’améliorer la gestion des ID, notamment en ce qui concerne l’Authentification (AuthN), les Autorisations (AuthZ) et l’Audit (Accounting).

Dans notre contexte, l’idée de placer un UTM dans le SI est de pouvoir authentifier, autoriser et auditer les accès utilisateurs entre zones. Lors de l’utilisation d’un UTM WatchGuard, vous pouvez utiliser plusieurs types de serveurs d’authentification pour centraliser les identités (ID) et procéder à leurs authentifications (AuthN). Une fois l’utilisateur identifié, les stratégies (contenant les comptes/groupes utilisateurs identifiés) permettent d’appliquer les autorisations (AuthZ) sur les « five tuples » utilisés par les flux. L’audit est ensuite réalisé par l’activation des journaux (logs) sur les différents éléments de l’UTM. La console Traffic Monitor permet de consulter en temps réels le flux et Dimension permet de le conserver pour analyse et reporting ultérieur.

Mais pour ne rien oublier concernant l’authentification, il faut parler du SSO (Single Sign-On), ou authentification unique en français. C’est le mécanisme qui permet aux utilisateurs de s’authentifier une seule fois pour accéder à plusieurs ressources réseau, sans avoir à saisir à chaque fois leurs identifiants. Cela simplifie le processus de connexion et améliore l’expérience utilisateur en évitant d’avoir à se souvenir et à saisir des identifiants différents pour chaque application. Chez WatchGuard, il y a plusieurs approches :

Dans un premier temps, on peut contrôler l’accès à Internet des utilisateurs de votre système d’information...

Single Sign-On (ADDS + SSO)

Pourquoi ?

Le SSO (Single Sign-On) permet à un utilisateur d’un domaine Active Directory Domain Services (ADDS) de s’identifier une seule fois lors de l’ouverture de Windows et d’accéder à Internet ou aux différents réseaux du SI. Dans ce cas de figure, il n’y a pas de portail captif pour entrer des identifiants et mots de passe utilisateurs.

En revanche, cela nécessite le déploiement d’un agent (SSOagent) sur le contrôleur de domaine et d’un agent (SSOclient) sur les postes clients en Windows. Lors de l’installation des agents, des ports en entrée sont ouverts automatiquement sur le contrôleur de domaine et sur les postes clients.

Une fois cela fait, l’UTM peut procéder aux étapes d’authentification, d’autorisation et d’audit (AAA).

Informations

En réalité, il y a quatre méthodes pour le SSO sur ADDS :

Cela fait beaucoup de méthodes pour pas grand-chose… Pour faire simple, toutes les méthodes impliquent d’utiliser un agent SSO agent sur le contrôleur de domaine (ADDS) pour avoir du SSO.

La méthode 1 SSO agent (mode AD) est désactivée par défaut car elle ne permet pas réellement de faire de l’authentification. La méthode 1 SSO agent (mode AD) utilise le compte de service de l’agent SSO agent pour toutes les connexions, ce qui n’est pas pertinent pour de l’authentification.

WatchGuard vous recommande donc la méthode 2 et d’installer un agent SSO agent sur le contrôleur de domaine (ADDS) et un agent SSO client sur les postes clients. Comme il est possible de cumuler plusieurs méthodes d’authentification afin d’améliorer la résilience de l’authentification, les méthodes...

Terminal Services (TO Agent)

Pourquoi ?

Dans votre réseau, l’UTM authentifie un utilisateur par corrélation ID + mot de passe et l’IP de son poste client. Cela fonctionne bien la plupart du temps, cependant cela pose un problème lors de l’authentification des utilisateurs sur des serveurs RDS (Remote Desktop Services).

Sur un serveur RDS, plusieurs utilisateurs différents peuvent ouvrir une session en même temps. En revanche, ils partagent tous la même IP (celle du serveur RDS). Pour l’autorisation et l’audit, c’est un problème à prendre en considération.

Pour solutionner ce problème, WatchGuard utilise un agent Terminal Services Agent (TO agent) à installer sur le ou les serveurs RDS. L’agent inclut deux éléments :

Informations

Le TO agent (SSO Terminal Services), qui permet le SSO avec Active Directory sur des serveurs RDS, est autonome et ne fonctionne pas en complément avec les autres agents comme SSO agent, SSO client, ELM ou EM…

Ainsi, les utilisateurs sur le serveur RDS avec TO agent (SSO Terminal Services) ne vont pas avoir besoin de passer par un portail captif pour naviguer sur Internet.

Dernier point important : il est possible d’utiliser...