Cet article examine comment LimitLogin et UserLock limitent les connexions utilisateur simultanées dans un domaine Active Directory.
Il se concentrera sur la fonction de restriction de connexion simultanée fournie par chaque solution et discutera de la manière dont elles aident une organisation à sécuriser l'accès des utilisateurs pour les environnements Windows Active Directory.
LimitLogin
LimitLogin est un outil qui est sorti en 2005. Il a été écrit par un spécialiste Microsoft Partner Technology et un consultant en développement d'applications. Le but de LimitLogin était d'ajouter la possibilité de suivre et de limiter les connexions utilisateur concurrentes sur les postes de travail et les terminaux dans un domaine Active Directory.
UserLock
UserLock est une solution logicielle d'entreprise qui contrôle, audite et surveille l'accès des utilisateurs à un réseau Active Directory. UserLock permet, refuse ou limite l'accès en fonction d'une gamme de critères; par exemple, empêcher les connexions simultanées via une seule identité, limiter l'accès à certains types d'appareils et limiter les méthodes d'accès au réseau. UserLock surveille également toutes les sessions en temps réel fournissant des alertes et des informations pour répondre aux événements suspects et un journal des informations d'accès pour l'audit et les investigations légales.
UserLock est développé par IS Decisions, une société Microsoft Partner fondée en 2000, spécialisée dans les solutions de protection et de sécurisation des infrastructures Microsoft Windows et Active Directory.
Télécharger maintenant un essai gratuit entièrement fonctionnel de UserLock. Version complète de 30 jours sans limite d'utilisateur.
LimitLogin vs UserLock. Une comparaison
| Caractéristiques | LimitLogin | UserLock |
| Technologie d'agent | Scripts d'ouverture de session | Service Windows* |
| Modification du schéma AD | Oui | Non |
| Demande de serveur Web | Oui | Non |
| Système d’exploitation poste de travail pris en charge | Windows 2000 SP4, Windows XP SP1 | Windows XP, Windows Vista, Windows 7, Windows 8, Windows 8.1, Windows 10 |
| Système d’exploitation serveur pris en charge | Windows Server 2003, Windows Server 2008 | Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016 |
| Prise en charge du système d'exploitation 64 bits | Non | Oui |
| Agent client | Oui | Oui |
| Déployeur intégré | Non | Oui |
| Sessions Poste de travail | Oui | Oui |
| Sessions terminales | Oui | Oui |
| Sessions Wi-Fi | Non | Oui |
| Sessions VPN | Non | Oui |
| Sessions IIS | Non | Oui |
| Audit des événements de connexion et de déconnexion | Oui | Oui |
| Audit des événements de verrouillage et déverrouillage | Non | Oui |
| Limite par utilisateur | Oui | Oui |
| Limite par groupe | Non | Oui |
| Restrictions de localisation | Non | Oui |
| Restrictions de connexion horaire | Non | Oui |
| Fonctions de quota temporel | Non | Oui |
| Messages personnalisables | Non | Oui |
| Notifications par e-mail | Non | Oui |
| Notifications pop-up | Non | Oui |
| Base de données des activités de la session | Non | Oui |
| Rapport imprimable et personnalisable | Non: Uniquement CSV / XML | Oui |
| Solution prise en charge | Non, même par son fournisseur Microsoft | Oui, par son éditeur IS Decisions |
Service Windows*: à l'exception des anciens serveurs Windows XP et 2003 pour lesquels la technologie du micro agent est une GINA DLL.
Exigences et spécifications
LimitLogin n'est pas compatible avec Windows Server 2008 R2, 2012 et 2012 R2.
UserLock est certifié pour la conformité et le support avec Windows Server 2016, 2012 R2, 2012, 2008 et 2008 R2.
LimitLogin ne prend pas en charge les systèmes 64 bits. UserLock oui.
Similaire au statut des outils du kit de ressources et / ou des outils de support, LimitLogin n'est pas officiellement supporté par Microsoft.
- Systèmes d'exploitation Windows Server
|
2000 |
2003 |
2008 |
2008 R2 |
2012 |
2012 R2 |
2016 |
| LimitLogin |
|
|
|
|
|
|
|
| UserLock |
|
|
|
|
|
|
|
- Systèmes d'exploitation poste de travail Windows
|
2000 |
XP |
Vista |
Windows 7 |
Windows 8 |
Windows 8.1 |
Windows 10 |
| LimitLogin |
|
|
|
|
|
|
|
| UserLock |
|
|
|
|
|
|
|
Types de session limitées avec LimitLogin
Les capacités LimitLogin sont limitées à la surveillance uniquement des sessions de postes de travail et de terminaux. UserLock d'autre part prend en compte l'accès de tous les types de session (postes de travail, terminal, interactif, Internet Information Services et Wi-Fi / VPN). En savoir plus.
|
Poste de travail |
Terminal |
Wi-Fi |
VPN |
IIS |
| LimitLogin |
|
|
|
|
|
| UserLock |
|
|
|
|
|
Architecture et déploiement
Voici un résumé comparant l'architecture requise pour surveiller et limiter le nombre de connexions au poste de travail et au terminal:
| LimitLogin | UserLock |
| L'architecture est construite autour de 3 éléments principaux: |
Une application client / serveur:- Un serveur UserLock sur un serveur Windows.
- Un micro-agent sur machine protégée.
|
- Un service Web qui gère le traitement back-end sur le serveur.
- Une partition d'annuaire d'application qui contient les informations de connexion.
- Des scripts VBS de connexion et déconnexion
|
|
| LimitLogin nécessite la création d'une nouvelle partition dans Active Directory sur un contrôleur de domaine Windows. | UserLock peut être installé sur n'importe quel membre du réseau. Il n'est pas nécessaire d'utiliser un serveur de contrôleur de domaine. |
| LimitLogin effectue une modification du schéma Active Directory. Cette opération est irréversible et ne peut être annulée. | UserLock n'effectue aucune modification Active Directory. |
| LimitLogin requiert des scripts de connexion et de fermeture de session. | Le micro-agent peut ensuite être automatiquement déployé via la console UserLock ou en tant que package MSI. |
| LimitLogin nécessite un serveur Web configuré pour l'authentification Kerberos déléguée pour la communication des scripts et le traitement des règles. | La communication cryptée entre le serveur et les agents nécessite uniquement des protocoles Partage des Fichiers et Imprimantes. |
| Les informations sur les sessions de connexion sont stockées dans des fichiers qui ne sont pas cryptés. | Les activités de sessions sont stockées dans une base de données qui peut être une édition SQL Express ou Server (une base de données gratuite est fournie). |
Déploiement de LimitLogin
Microsoft LimitLogin a été conçu pour aider les administrateurs à appliquer des limites de connexion sur leur réseau. Il est cependant complexe à implémenter et dangereux à cause de la modification du schéma Active Directory dont il a besoin.
Bill Boswell (Microsoft Certified Professional Magazine) a écrit cette analyse très méticuleuse et précise sur la façon de déployer LimitLogin:
"LimitLogin nécessite un peu d'effort pour être déployé. D'une part, il effectue une modification de schéma. D’autre part, il crée une nouvelle partition dans Active Directory. Cela nécessite également de configurer un serveur Web avec .NET Framework et ASP.NET et de le configurer pour effectuer l'authentification Kerberos déléguée. Enfin, il nécessite la distribution de paquets clients prenant en charge la communication avec le serveur Web via SOAP (un protocole léger pour l'échange d'informations structurées dans un environnement distribué). Whoa. N'arrêtez pas de lire. C'est compliqué, mais pas impossible. Vraiment."
Déploiement de UserLock
UserLock s'installe en quelques minutes sur un serveur Windows standard. L'installation peut être effectuée sur n'importe quel membre du serveur du domaine. Il n'y a aucune obligation d'utiliser un serveur de contrôleur de domaine. Une fois installé, UserLock doit déployer un micro agent sur chaque poste de travail membre de la zone réseau sélectionnée. Cela peut être fait via la console UserLock qui contient un déployeur d'agent avec des modes manuels ou automatiques. UserLock lit les informations Active Directory mais ne modifie rien concernant les comptes ni le schéma.
Télécharger maintenant un essai gratuit entièrement fonctionnel de UserLock. Version complète de 30 jours sans limite d'utilisateur.
Le besoin de gérer les connexions simultanées
La plupart des organisations qui travaillent dans un environnement Windows utilisent Microsoft Active Directory pour authentifier et contrôler tous les utilisateurs. Toutefois, Active Directory n'est en aucun cas une solution de sécurité complète. Oui, il gère les mots de passe et confirme que le nom d'utilisateur correspond au mot de passe, mais cela n'empêche pas plusieurs utilisateurs de se connecter avec le même mot de passe, en même temps.
Ce défi de limiter les connexions simultanées dans un environnement Windows évite l'une des situations les plus dangereuses pour un réseau Windows Active Directory.
Prévenir ou limiter les sessions simultanées:
- Arrête les utilisateurs partageant leurs mots de passe. Les utilisateurs réfléchiront à deux fois au partage des informations d'identification, car ils ne pourront pas accéder au système si quelqu'un d'autre est connecté.
- Empêche les utilisateurs malveillants d'utiliser des informations d'identification valides en même temps que leur propriétaire légitime.
- S'assure que l'accès aux données importantes est attribué aux employés individuels.
- Nécessaire pour qu’un système d'information soit conforme aux principales normes réglementaires, y compris NIST 800-53, SOX, PCI-DSS, HIPAA et les exigences nouvellement mises à jour de CJIS.
Autres restrictions nécessaires pour gérer l'accès au réseau
L'application LimitLogin permet à une organisation de gérer uniquement le nombre de connexions utilisateur.
Avec UserLock, le contrôle de connexions simultanées n'est qu'une partie d'une stratégie de contrôle d'accès granulaire. UserLock définit et applique le contrôle de connexion basé sur plusieurs critères dans une matrice de règles d'accès; qui est défini en fonction de l'utilisateur, d’un groupe d'utilisateurs ou d’une unité organisationnelle.
Contrôler à partir d’où un compte protégé peut se connecter. Restreindre les utilisateurs du domaine à une station de travail ou un périphérique, à la plage IP, au service, à l'étage ou au bâtiment. En savoir plus.
Contrôler les heures et les jours pendant lesquels les utilisateurs protégés peuvent se connecter au réseau. Définissez les heures de travail et / ou le temps de session maximum. En savoir plus.
Conclusion
Microsoft LimitLogin était un outil gratuit pour aider l'administrateur dans le passé à appliquer des limites de connexion sur leur réseau. Il était cependant complexe à implémenter et dangereux à cause de la modification du schéma Active Directory nécessaire.
Dans le monde d'aujourd'hui, LimitLogin est incapable de répondre aux besoins critiques de nombreuses organisations. Les systèmes d'exploitation apparus au cours des six dernières années ne sont pas pris en charge, seul le nombre de sessions utilisateur peut être contrôlé, sans restriction supplémentaire en fonction de l'emplacement ou de l'heure, et limité aux sessions de poste de travail et terminal.
La définition et l'application d'une stratégie d'accès utilisateur complète pour garantir la sécurité de votre accès réseau et la protection de vos données nécessitent la prise en compte de plusieurs variables contextuelles.
Le nombre d'accès simultanés n'est pas suffisant. Vous devez savoir, analyser et contrôler qui, comment, quand, combien de fois et d'où un accès à un réseau d'entreprise est demandé, si cette requête est effectuée sur une machine, via le VPN, grâce à une connexion sans fil ou via un réseau application ou un intranet.
UserLock répond à ces besoins avec un outil de gestion d'accès réseau efficace, très simple à gérer et facile à utiliser. Une stratégie d'accès personnalisée peut être définie et appliquée pour autoriser ou refuser les connexions utilisateur. Les sessions simultanées peuvent être évitées et l'accès limité à des postes de travail ou à des périphériques, des heures et des types de connexion spécifiques (y compris le Wi-Fi).
Avertissement: La comparaison juxtapose les caractéristiques de UserLock IS Decisions et LimitLogin sur la base des informations disponibles publiquement en date du 11 février 2014.