HowTo : Activer le Mode « Restricted Admin » pour les Connexions Bureau à distance

S’applique à : RDS Windows Server 2012 R2, RDS Windows Server 2016, Windows 8(.1), Windows 10

Microsoft a apporté plusieurs améliorations en matière de sécurité au couple d’OS {Windows Server 2012 R2 & Windows 8.1} pour les protéger contre les attaques PtH (Pass-the-Hash). Les mots de passes des comptes utilisateurs ainsi que leur Hashes sont généralement stockés sur le Disque et la Mémoire du Poste de travail /Serveur, si votre machine est compromise, vos informations d’identification peuvent être réutilisées par un Hacker pour accéder à d’autres systèmes /plateformes /services critiques sans que vous soyez au courant.

Introduit avec Windows Server 2012 R2, la fonctionnalité « Restricted Admin Mode » ou « Mode d’Administration Restreinte » a été conçu pour protéger les comptes Administrateurs (locaux et du domaine) contre ce type d’attaque en s’assurant que les informations d’identification saisies lors d’une connexion Bureau à distance ne soient mémorisées et stockées dans la mémoire de la machine distante, qui peut potentiellement être compromise.

Quelques scénarios typiques

Equipe Help Desk utilisant un compte « Administrateur » pour effectuer du support N1/N2 à distance (via RDP) sur les machines des utilisateurs du réseau

Equipe IT Admins utilisant un compte « Administrateur du Domaine » pour effectuer du support N3 à distance (via RDP) sur des serveurs Membres.

Processus d’ouverture de Session RDP

Lorsque vous établissez une Connexion Bureau à distance sur une machine distante, vous êtes invités à vous authentifiez : Apparition de la fameuse boite de dialogue « Sécurité de Windows« :

L’authentification se fait dans un premier temps avec le service local RDP via le Process « Remote Interactive Logon ». Dans ce contexte, le mot « Interactive » signifie que l’utilisateur saisi « physiquement » son nom d’utilisateur et son mot de passe associé.

Le Service RDP tente ensuite d’ouvrir une Session Réseau sur la machine distante pour vérifier si l’utilisateur est autorisé à s’y connecter/accéder ou pas. Lors de cette phase, aucune information d’identification n’est requise. En effet, le ticket Kerberos ou Hash NTLM ayant été créés lors de l’ouverture de session initiale peuvent être utilisés pour l’authentification via réseau.

Une fois authentifié par le service RDP de la machine distante, les informations d’identification de l’utilisateur sont envoyées à travers un canal sécurisé vers la machine distante, l’ouverture de session « Interactive » a lieu ce qui permet à l’utilisateur distant de voir et accéder au Bureau à distance.

Prérequis

La fonctionnalité « Restricted Admin Mode » est supportée uniquement par les OS suivants :

OS Server : Windows Server 2012 R2 et Windows Server 2016

OS Client : Windows 8.1 et Windows 10

Donc avant de lancez une Connexion Bureau à distance en mode « Restricted Admin », assurez-vous que celle-ci est établie depuis et vers un des OS cités ci-dessus.

Dois-je utiliser le mode « Restricted Admin » ?

Si vous souhaitez restreindre les accès Bureau à distance sur des machines pouvant présentées un problème (machine présentant des problèmes de stabilité, potentiellement compromise, infectées par des virus…), vous pouvez envisager l’activation du mode « RestrictedAdmin », car comme expliqué ci-haut, vous pouvez être sûre que vos infos d’identifications ne peuvent être réutilisées par un programme malveillant ou un Hacker pour s’introduire sur d’autres machines du réseau jugées « critiques » comme les DC, BDD, Filers …

Cependant, certaines « Best Practices » de l’éditeur soulignent une préférence pour le « Hardening d’OS » incluant la mise en place de stratégies de sécurité pour renforcer la sécurité des comptes Administrateurs (locaux et du domaine), comme par exemple :

Le compte « Administrateur du Domaine » doit uniquement être utilisé pour s’authentifier sur les DCs pour gérer et administrer l’infrastructure AD et JAMAIS pour administrer les serveurs membres, les machines des utilisateurs du réseau …

Chaque machine du réseau doit avoir un compte « Administrateur » et mot de passe unique pour les besoins de gestion, d’administration et support

…

Comment utiliser le mode « Restricted Admin » ?

Le mode « Restricted Admin » est représenté par un paramètre de l’outil MSTSC.exe (Application Cliente : Connexion Bureau à distance).

Cette fonctionnalité correspond au paramètre /RestrictedAdmin, lancez MSTSC /? depuis l’invite de commande (CMD.exe) ou le Menu Démarré et constatez la disponibilité du mode « /RestrictedAdmin »:

Activer ou Désactiver le mode « Restricted Admin » 

Le Mode « Restricted Admin » est désactivé par défaut.

Pour activer cette fonctionnalité, une nouvelle clé doit être créée au niveau du BDR (Base de Registre), voir les paramètres suivants:

Chemin : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Valeur DWORD (32-bits) : DisableRestrictedAdmin

Données de la valeur : 0

Vous pouvez également activer cette fonctionnalité d’une manière centralisée sur un ensemble de serveurs /postes de travail via GPO, et ce via l’utilisation du paramètre de Stratégie de groupe suivant :

Chemin : Configuration Ordinateur | Stratégies | Modèles d’administration | Système | Délégation d’informations d’identification

Paramètre : Limiter la délégation d’informations d’identification à des serveurs distants

Valeur du paramètre : Activé

Une fois activé, si vous établissez une Connexion Bureau à distance (en mode Normal sans le paramètre /RestrictedAdmin) sur un serveur distant, le message suivant apparaît:

Maintenant, essayez de vous connecter à votre machine distante via l’utilisation de la commande : MSTSC /RestrictedAdmin

Note : Cette commande peut être lancée depuis le Menu Démarrée ou l’Invite de commande (CMD.exe)

Comme illustré dans l’image ci-après, la connexion Bureau à distance avec le mode « RestrictedAdmin » renforcé permet l’ouverture de la Session Bureau à distance :

Limitations du mode « Restricted Admin »

Comme expliqué précédemment, quand le mode « Restricted Admin » est activé, l’utilisateur authentifié sur la machine distante n’a pas la possibilité de se connecter sur d’autres machines ni ressources du réseaux,
En effet, la délégation étant restreinte, les connections vers les autres machines s’effectuent via le compte d’ordinateur local.

Vous risquez (par exemple) de ne pas pouvoir vous connecter à un lecteur réseau depuis une Session Bureau à distance.

Dans l’exemple suivant, une Connexion Bureau à distance (en mode Restricted Admin) a été ouverte sur le DC. Le Gestionnaire de Serveur du DC a été lancé et une tentative de Connexion sur le serveur distant RDS01 a échouée (pas de délégation d’informations d’identification):

Cette fois ci, une Connexion Bureau à distance (en mode normal : sans le Mode Restricted Admin) a été ouverte sur le DC. Le Gestionnaire de Serveur du DC a été lancé et une tentative de Connexion sur le serveur distant RDS01 a réussie (délégation d’informations d’identification ):

Publicité

HowToFix : Crash de la console « Gestionnaire de Passerelle des Services Bureau à distance » avec l’Update « .NET Framework 4.6.1 »

S’applique à : RDS Windows Server 2012 R2 uniquement

Si un ou plusieurs de vos serveurs RDG 2012 R2 (Remote Desktop Gateway : Passerelle des Services Bureau à distance) ont récupéré la mise à jour « KB3102467« , celle-ci peut causer un crash de la console « Gestionnaire de Passerelle des Services Bureau à distance » (ou « RD Gateway Manager » pour les OS en EN).

La KB3102467 décrit la mise à jour « .NET Framework 4.6.1 » pour Windows Server 2012 R2.

J’ai essayé de reproduire le problème sur mes LABs RDS (OnPrem & Cloud), le problème parvient au niveau d’un serveur RDG sur 2.

Microsoft vient de publier un « Fix » pour corriger ce bug post-install de l’Update .NET Framework 4.6.1

Un reboot post-application du Fix est requis, donc pensez à planifier l’application de ce correctif sur vos serveurs RDG de Prod.

Découvrez le « Group Policy caching » sous Windows Server 2012 R2 et Windows 8.1

Hello everyone,

Aujourd’hui, nous allons parler des GPO (Group Policy Objects), et plus précisément d’une nouvelle fonctionnalité introduite aux Stratégies de Groupe sous Windows Server 2012 R2 et Windows 8.1 : Group Policy Caching

Group Policy Caching ?! Qu’est-ce que c’est ?

Quand une machine du réseau exécutant « Windows 8.1 » ou « Windows Server 2012 R2 » récupère des paramètres de Stratégies Groupes depuis un DC (Domain Controller), les valeurs de ces paramètres de stratégies de groupes sont stockées localement sur la machine où l’utilisateur AD s’est authentifié, et ce dans l’emplacement suivant :

C:\Users\<UserName>\AppData\Local\GroupPolicy\DataStore\0\SysVol\<domain name>\Policies

Chaque GPO récupérée est représentée par un dossier portant son IDentifiant Unique (GUID : Globally Unique IDentifier)

Le principe du « Policy Caching » consiste à lire /charger le contenu le plus récent des paramètres de stratégies de groupe téléchargé et stocké localement depuis l’emplacement (local) indiqué précédemment au lieu de contacter un DC à chaque Logon.
Ceci réduit le temps requis pour chaque actualisation du moteur de stratégie de groupe local et chargement des paramètre GP depuis le réseau (depuis un DC du réseau).

Notez que le « Group Policy Caching » est une fonctionnalité activée par défaut sur les OS Windows Server 2012 R2 et Windows 8.1

Si toutefois vous voulez contrôler l’activation /désactivation de cette fonctionnalité, cela peut être fait via l’arborescence suivante :

OS en FR :

Configuration Ordinateur > Modèles d’administration > Système > Stratégies de groupe > « Configurer la mise en cache des stratégies de groupe »

OS en EN :

Computer Configuration > Administrative Templetes > System > Group Policy > « Configure Group Policy Caching »

HowTo : Configurer une adresse IP statique pour vos VMs sur Microsoft Azure

Par défaut, quand vous créez une Machine Virtuelle (VM) depuis le portail de gestion Microsoft Azure ou depuis Microsoft Azure PowerShell, vous n’avez pas besoin de lui attribuer une adresse IP, en effet, celle-ci se voit automatiquement attribuer une configuration TCP/IP incluant une adresse IP faisant parti de la plage d’adresse IP (disponible et attribuable) du réseau virtuel interne.

En outre, si vous auriez le même reflex que moi 😀 et tenteriez de configurer manuellement une adresse IP statique sur votre VM, celle-ci n’est conservée que temporairement, en effet, une fois votre VM éteinte ou redémarrée, sa configuration TCP/IP est mise à nouveau en mode « Automatique »

Le fait de redémarrer ou d’éteindre la VM implique également la perte de la configuration TCP/IP automatique, ce qui peut être problématique dans certains scénarios, comme par exemple une VM qui fait office de :

Contrôleur de domaine (DC)

Serveur d’Application

Serveur de fichiers

Serveur de base de données

et dont l’adresse IP doit être attribuée d’une manière permanente.

Heureusement que le module « Azure PowerShell » inclut une Cmd-let nous permettant de configurer (réserver) une adresse IP statique sur une VM mais aussi de vérifier sa disponibilité pour éviter tout conflit sur le réseau virtuel interne Azure, il s’agit des Cmd-lets :

Test-AzureStaticVNetIP

Set-AzureStaticVNetIP

Dans l’exemple suivant, je vais simplement utiliser la Cmd-let Get-AzureVM suivie du nom de service Cloud de ma VM (DomainController01) pour obtenir des informations sur mon DC et notamment son adresse IP :

Comme vous pouvez le constater, la VM « DC01 » est configurée actuellement avec l’adresse IP > 10.0.0.4, nous pouvons d’ailleurs le confirmer en vérifiant sa disponibilité et ce en utilisant la Cmd-let Test-AzureStaticVNetIP suivie du nom du réseau virtuel (vLABNet dans l’exemple suivant) et de l’adresse IP en question (10.0.0.4 dans notre exemple) :

Test-AzureStaticVNetIP -VNetName « vLABNet » -IPAddress 10.0.0.4

Le résultat retourné indique « False ===> Faux » devant l’attribut « IsAvailable ==> EstDisponible » ce qui confirme l’indisponibilité de l’adresse IP 10.0.0.4

Nous allons maintenant réserver cette adresse IP (d’une manière permanente) pour la VM « DC01 ».

How it Works ?

1. Tout d’abord, il faut éteindre la VM « DC01 » pour libérer son adresse IP :

Saisir la commande suivante en renseignant le nom de service pour cette VM (DomainController01 dans l’exemple suivant)

Stop-AzureVM -ServiceName DomainController01 -Name DC01

Confirmer l’arrêt de la VM en saisissant O comme Oui

Dès que la VM est arrêtée, son adresse IP est libérée, nous allons donc vérifier de nouveau la disponibilité de l’adresse IP 10.0.0.4 :

Test-AzureStaticVNetIP -VNetName « vLABNet » -IPAddress 10.0.0.4

La valeur de l’attribut « IsAvailable » est cette fois-ci « True » ce qui signifie que l’adresse IP 10.0.0.4 est désormais disponible.

1. La deuxième étape consiste à réserver cette adresse IP pour la VM « DC01 » pour ce faire, lancez les deux commandes suivantes depuis Microsoft Azure PowerShell :

$VM = Get-AzureVM -ServiceName DomainController01 -Name DC01

Set-AzureStaticVNetIP -VM $VM -IPAddress 10.0.0.4 | Update-AzureVM

L’adresse IP 10.0.0.4 est désormais réservée pour la VM « DC01 » et ce, quelque soit son statut : Éteinte, Allumée …

D’ailleurs, il suffit de vérifier la disponibilité de l’adresse IP 10.0.0.4 pour le constater

N’oubliez pas de démarrer votre VM via l’utilisation de la Cmd-let Start-AzureVM, voir l’exemple suivant (démarrage de la VM DC01) :

Start-AzureVM -ServiceName DomainController01 -Name DC01

Conclusion

La réservation d’adresse IP pour vos VMs (DC, Files Server, DB Server…) est une tâche à ajouter dans la « ToDoList » si vous envisagez par exemple de promouvoir des DCs /Files Server … sur des VMs Azure.