Sessions protégées

Une session interactive est une session avec un bureau. Vous pouvez ouvrir une session interactive sur un ordinateur soit directement sur la console de l'ordinateur soit à distance via un bureau à distance.

UserLock ne protégera les sessions interactives que sur les machines avec l'agent Station installé. Les sessions interactives sur des machines sans cet agent ne seront pas surveillées par UserLock.

Si vous souhaitez protéger les sessions terminales, il vous suffit d'installer cet agent Station sur les serveurs de terminaux. Aucune installation supplémentaire n'est requise sur les clients légers (terminaux).

Veuillez noter que, par défaut, seules les sessions distantes ciblant des systèmes d'exploitation serveur seront considérées comme des sessions de terminal (une session distante ciblant un système d'exploitation de poste de travail sera considérée comme une session de poste de travail). Ce comportement peut être modifié en modifiant la valeur du paramètre avancé mode VDI :

UserLock peut auditer, contrôler et appliquer une politique de contrôle d'accès utilisateur des sessions utilisant le protocole RADIUS sur un Serveur Microsoft Network Policy Server (inclus dans Windows Server).

• L'agent NPS doit être installé sur ce serveur.

• Les clients RADIUS (Microsoft RRAS, routeurs matériels) doivent être configurés pour contacter le serveur NPS pour l'authentification RADIUS et la technologie RADIUS accounting.

• Généralement, le protocole RADIUS ne permet pas de récupérer le nom du client. Par conséquent, vous ne pourrez pas appliquer des Restrictions de machines avec le nom du client. Le seul cas connu où ce nom est disponible est si votre serveur RRAS est configuré avec l'Authentification RADIUS et l'Accounting RADIUS.

• L'adresse IP du client VPN n'est pas fournie par tous les clients (routeurs matériels). Dans ce cas vous ne pourrez pas appliquer des Restrictions de machines avec l'adresse IP.

• La possibilité d'utiliser plusieurs serveurs RADIUS pour un client RADIUS (routeur matériel) n'est pas supportée car l'ouverture et la fermeture de la session peuvent être traitées par des agents NPS différents.

• Lorsqu'une session VPN est refusée, l'utilisateur est invité a saisir à nouveau son identifiant et son mot de passe. Il n'est pas technologiquement possible d'afficher un message plus intelligible à l'utilisateur.

• Les sessions VPN ne sont pas compatibles avec une déconnexion forcée.

Nous ne disposons pas actuellement de liste de routeurs compatibles avec UserLock. Nous vous invitons donc à tester préalablement le fonctionnement de votre routeur avec UserLock.

UserLock peut auditer, contrôler et appliquer des règles d'accès utilisateur sur les sessions Internet Information Services (IIS). Vous pouvez définir des stratégies d'accès pour activer l'authentification multifacteur et les restrictions d'accès contextuelles pour une application IIS spécifique comme Outlook Web Access (voir ce cas d'utilisation avancé pour les détails) ou RDWeb, SharePoint, CRM etc. par exemple, ou un site Intranet. UserLock enregistrant tous les événements de connexion utilisateur dans sa base de données. il sera donc possible de générer des rapports sur l'historique des sessions IIS.

• Pour superviser les sessions IIS, il est nécessaire de déployer l'agent IIS UserLock sur le serveur hébergeant l'application que vous souhaitez protéger. Puis de configurer les options du répertoire virtuel du Site Web pour charger cet agent IIS, en suivant cette procédure.

• L'agent IIS est compatible uniquement avec les applications IIS configurées avec les modes d'authentification Authentification intégrée Windows ou Authentification de base.

Limitations connues et configuration additionnelles : voir ici.

UserLock peut auditer, contrôler et appliquer un politique de contrôle d'accès utilisateur des sessions Wi-Fi utilisant le protocole RADIUS avec un Service Microsoft Network Policy Server (inclus dans Windows Server).

• L'agent NPS doit être installé avec ce service.

• Les clients RADIUS (routeurs matériels) doivent être configurés pour contacter le serveur NPS pour l'authentification RADIUS et la technologie RADIUS accounting.

• Généralement, le protocole RADIUS ne permet pas de récupérer le nom du client. Par conséquent, vous ne pourrez pas appliquer de Restrictions de machines avec le nom du client.

• Le contrôle des sessions Wi-Fi peut ne pas être fiable si le point d'accès Wi-Fi ne notifie pas correctement la fin de la session au serveur RADIUS, i.e. si un client Wi-Fi est mis hors tension sans déconnecter proprement la session Wi-Fi.

• Si le client Wi-Fi fait partie du domaine Active Directory, la session Wi-Fi peut être initiée par le compte de machine. Dans ce cas UserLock ne pourra pas superviser la session. UserLock ne supporte que les sessions configurées pour s'authentifier avec des comptes utilisateurs et non les sessions avec des comptes de machine.

• La possibilité d'utiliser plusieurs serveurs RADIUS pour un client RADIUS (routeur matériel ou point d'accès Wi-Fi) n'est pas supportée car l'ouverture et la fermeture de la session peuvent être traitées par un agent NPS différent.

• Lorsqu'une session Wi-Fi est refusée, l'utilisateur est invité a saisir à nouveau son identifiant et son mot de passe. Il n'est pas technologiquement possible d'afficher un message plus intelligible à l'utilisateur.

Voici la liste de compatibilité matérielle indiquant tous les routeurs matériels et les points d'accès Wi-Fi compatibles avec UserLock:

• Points d'accès Wi-Fi:

  • Cisco Aironet 1700 (AIR-CAP1702I-E-K9).

Cette liste n'est pas exhaustive car nous n'avons pas testé tous les périphériques matériels. Nous vous suggérons donc de tester votre appareil avec UserLock.

Les sessions SaaS sont celles dont les applications sont configurées avec la SSO de UserLock.

Consultez le guide pour mettre en œuvre la SSO UserLock.

Les sessions SaaS ne peuvent pas être protégées par toutes les restrictions UserLock. En effet UserLock n’est capable de savoir qu’une session SaaS est déconnectée seulement si l’utilisateur se déconnecte manuellement de l’application avant de fermer le navigateur. Etant donné qu’il ne s’agit pas d’un comportement utilisateur fréquent, dans la plupart des cas, nous ne pouvons pas voir la déconnexion. Pour cette raison, les sessions SaaS ont les limitations suivantes :

• Les sessions SaaS ne sont pas visibles dans les vues Activité.

• Les sessions SaaS ne sont pas incluses dans les rapports suivants :

  • Historique des heures de travail.

  • Historique des sessions simultanées.

• Les stratégies d'accès suivantes ne peuvent pas être appliquées aux sessions SaaS :

  • Sessions simultanées : L’administrateur peut seulement autoriser ou refuser les sessions SaaS.

  • Restrictions horaires : Si vous sélectionnez les sessions SaaS dans vos restrictions horaires, les utilisateurs se verront refuser les connexions en dehors des heures autorisées. Cependant vous ne pouvez pas forcer la déconnexion d’une session SaaS qui dépasse le temps autorisé.

  • Restrictions de machines : Pour les connexions SaaS nous sommes dans la capacité de récupérer l’adresse IP mais pas le nom client. Pour cette raison, vous ne pouvez appliquer des restrictions que par plage IP.

  • Quotas de temps : Ne peuvent pas être appliqués aux sessions SaaS.

UserLock peut auditer et protéger les événements UAC avec les politiques d'accès MFA. Pour protéger ces événements, vous devez installer l'agent station sur les machines où la demande d'élévation des privilèges est effectuée. Vous pouvez ensuite créer une politique d'accès pour la MFA pour vos comptes privilégiés afin qu'ils soient invités à utiliser la MFA pour ces événements.

Les événements UAC seront également audités dès que l'agent sera déployé. Vous pouvez voir ces événements dans le rapport UAC et vous pouvez également configurer des notifications dans les alertes et notifications de la politique d'accès.

• L'agent station doit être installé sur la machine.

• L'UAC doit être configuré pour demander les identifiants.

Les sessions des comptes locaux sont auditées et affichées dans la console UserLock. Cependant, il n'est pour l'instant pas possible de définir des stratégies d'accès sur ce type de session.

Exception : pour les serveurs installés en mode Serveur de Terminal indépendant, les comptes locaux peuvent être protégés.

En revanche, l'ensemble des événements de sessions des comptes locaux est sauvegardé dans la base de données UserLock. Vous pourrez donc exploiter ces informations à des fins d'analyse et de reporting. Il est également possible d'interagir avec les sessions de compte local depuis les vues Activité de la même manière que les sessions interactives.

Les sessions des comptes locaux seront automatiquement supervisées dès l'installation d'un agent Station UserLock sur une machine.

Pour ces raisons, le statut utilisateur d'un compte local sera toujours Non protégé.

Les utilisateurs locaux ne sont pas pris en compte pour la consommation de licence.