Lacune Windows 1 : pas de contrôle des connexions simultanées

Windows n'offre aucune possibilité d'empêcher un compte utilisateur donné de se connecter à partir de plusieurs systèmes simultanément avec des crédences identiques (même identifiant, même mot de passe).

S'agissant de sessions interactives à partir de postes de travail ou d'ordinateurs portables, un administrateur système ne peut absolument pas empêcher un utilisateur de se connecter à un ordinateur, de laisser un autre utilisateur l'utiliser avec ses crédences ou de simplement quitter cet ordinateur pour aller se connecter à partir d'un second système.

Et cela tient à l'architecture de Windows, dans la mesure où aucune entité de ce système d'exploitation ne tient le compte des emplacements à partir desquels un utilisateur est connecté, ceci étant géré individuellement par chaque poste de travail.

Les postes de travail communiquent bien sûr avec le contrôleur de domaine, mais celui-ci n'est en fait impliqué que dans l'authentification initiale.

Une fois que le contrôleur de domaine a accepté la connexion (crédences correctes) ou l'a refusé (crédences incorrectes), il « oublie » cette connexion et ne garde aucune trace du fait que cet utilisateur est toujours connecté à partir de cet ordinateur, ce qui explique probablement l'impossibilité dans laquelle se trouve Windows de proposer une fonctionnalité de contrôle des connexions simultanées.

Microsoft a d'abord tenté de résoudre ce problème majeur en publiant un outil non supporté dénommé Cconnect, fourni avec son Windows NT/2000 Resource Kit. Mais compte tenu de sa complexité d'implémentation, de ses fonctionnalités extrêmement limitées, ainsi que des contraintes et des lacunes additionnelles (sic) générées par l'installation de ce logiciel, il ne fut que très peu utilisé.

Avec l'avènement d'Active Directory, Microsoft a revu sa copie. Mais, alors que l'on aurait pu penser que l'éditeur proposerait une solution intégrée satisfaisante, sa nouvelle initiative consista à fournir de nouveau un outil non supporté, basé sur des scripts de connexion, ne répondant que partiellement à la problématique et tout aussi compliqué à déployer et à administrer : LimitLogin.

LimitLogin est en effet particulièrement fastidieux à mettre en œuvre. Pour commencer, il génère une modification irréversible du schéma Active Directory (sic). Ensuite, il crée une nouvelle partition dans Active Directory, nécessite la configuration d'un site Web avec le NET Framework et ASP.NET, ainsi qu'une authentification déléguée Kerberos. Pour finir, il nécessite le déploiement de packages client supportant la communication avec le serveur Web via SOAP.

En bon français, cela s'appelle une usine à gaz …

Pourquoi le contrôle des connexions simultanées est-il si important ?

• cela réduit la capacité des utilisateurs à partager leurs crédences (identifiant et mot de passe) et d'éviter ainsi des cas de figure tel que celui-ci par exemple : un manager en charge de l'approbation des demandes d'achat se connecte avec ses crédences partir du poste de travail de l'un de ses subordonnés et confie ainsi à ce dernier sa tâche de vérification, sabotant ainsi la procédure de contrôle mise en place par l'organisation qui l'emploie.
• le bon fonctionnement de certaines applications dépend de l'interdiction des connexions simultanées dans la mesure où elles sont été conçues et développées à partir de l'hypothèse où un utilisateur ne peut pas ouvrir plusieurs sessions à la fois.
• il est crucial de limiter au mieux toute possibilité d'usurpation d'identité et de s'assurer que l'utilisateur des crédences de Monsieur Martin est bien Monsieur Martin.

De nombreuses enquêtes ont en effet été entravées car un utilisateur délictueux était en capacité de prétendre qu'un tiers était l'auteur du délit, en arguant du fait que ses crédences avaient été utilisées à son insu.

L'absence de contrôle des connexions simultanées crée un véritable problème d'attribution de responsabilité, ce qui explique que l'implémentation de cette fonctionnalité soit requise pour qu'un système d'information soit en conformité avec des systèmes réglementaires majeurs, tels

• le NISPOM (National Industrial Security Program Operating Manual – sections 8-303, 8-602 et 8-609)
• le DCID 6/3 (Director of Central Intelligence Issued Directive 6/3 – sections «Identification and Authentication» et «Enforcement of sessions controls»)