MFA sur les serveurs Windows indépendants avec UserLock

À une époque où Active Directory (AD) est considéré comme la norme, il est facile d’oublier que de nombreuses organisations utilisent encore des serveurs « indépendants » ou « en groupe de travail » pour certains cas d’usage spécifiques. Les raisons principales sont généralement la sécurité, la simplicité ou une combinaison des deux.

Exemples d’utilisation courants :

• Supporter des réseaux de petite taille (généralement moins de 50 utilisateurs) qui n’ont pas besoin de la complexité et des coûts d’un domaine AD complet. Dans certains cas, le serveur indépendant est le seul serveur de l’organisation.

• Fonctionner dans un réseau isolé ou segmenté (air-gapped), comme dans les systèmes de contrôle industriel ou de développement logiciel. L’organisation utilise AD, mais le serveur indépendant est volontairement séparé.

• Héberger une application dédiée, comme un serveur RDS (Remote Desktop Services, anciennement Terminal Services), destiné à une fonction spécifique. Un serveur indépendant permet d’isoler l’interface RDS, souvent ciblée, du reste du réseau.

Le point commun à tous ces cas est l’isolement. Héberger une application sur un serveur et un réseau dédiés permet de protéger le reste de l’environnement en cas de compromission du serveur indépendant, et inversement.

Sécuriser un serveur indépendant fonctionne différemment de la sécurisation d’un serveur AD traditionnel. Dans un environnement AD, l’authentification et l’application des stratégies sont gérées par un contrôleur de domaine (DC). Sur un serveur indépendant, tout cela se fait localement via le Security Accounts Manager (SAM) ou le Registre Windows, pour gérer les mots de passe, les comptes locaux et les groupes.

Cette gestion est forcément plus fastidieuse, car chaque serveur doit être configuré individuellement. Malgré cela, l’isolation reste parfois un avantage suffisamment important pour justifier cet effort supplémentaire.

Comme pour les serveurs AD, les comptes utilisateurs sur serveurs indépendants nécessitent une MFA pour atteindre un niveau de sécurité élevé. Mais comme Windows ne propose pas de MFA intégré, les organisations doivent se tourner vers une solution tierce.

Trois grands défis se posent :

• Coût : La majorité des solutions MFA repose sur une connexion à un service cloud tiers, ce qui peut être coûteux.

• Indépendance : Pour les réseaux sur site, certaines organisations refusent de dépendre d’un fournisseur externe ou d’une connexion Internet.

• Complexité : Certaines solutions nécessitent un second serveur pour l’authentification, ce qui est contradictoire avec la logique d’un serveur Windows autonome.

UserLock est souvent utilisé pour la gestion des accès dans des environnements AD on-premises. Mais ses fonctions de sécurité — MFA, SSO, contrôle d’accès utilisateur — sont également compatibles avec les serveurs indépendants.

Cela inclut la protection de serveurs totalement isolés, non connectés à un domaine AD, comme un serveur RDS/Terminal Services fonctionnant dans son propre groupe de travail.

Normalement, sécuriser un tel serveur est complexe. Windows Server ne propose pas de MFA natif, alors qu’il est pourtant essentiel. Heureusement, UserLock peut fonctionner en mode indépendant, sans agent, via un compte local et le SAM de Windows. Il s’installe directement sur le même serveur que le service RDS.

Lors de l’installation, l’assistant de configuration de UserLock propose trois options :

• Serveur principal

• Serveur de secours

• Terminal autonome

L’option « terminal autonome » prend en charge toutes les versions de Windows Server depuis 2012. Sélectionnez-la pour déployer UserLock en mode serveur indépendant.

Une explication détaillée des rôles serveur est disponible sur la page des types de serveurs UserLock.