Cas d’utilisation
Certains clients souhaitent utiliser un compte administrateur uniquement pour des tâches « élevées », un peu comme la façon dont les systèmes unix prennent en charge le concept de « sudo ». De plus, les systèmes unix sont généralement configurés pour bloquer la connexion directe par les comptes d’administrateur. La procédure établie consiste à se connecter avec un utilisateur non privilégié, puis à élever les tâches avec la commande « sudo » si nécessaire.
Il n’y a pas de mappage exact de ces concepts avec l’environnement Windows. Microsoft a fait quelques pas dans cette direction avec le contrôle de compte d’utilisateur. De plus, la commande « run as » permet un modèle de comportement similaire à celui de l’unix « sudo » (mais pas identique).
Étant donné que de nombreux clients ont les meilleures pratiques pour éviter d’utiliser des comptes d’administrateur dans la mesure du possible, examinons si nous pouvons autoriser l’utilisation d’un compte avec la commande « exécuter en tant que », mais empêcher ce compte de se connecter de manière interactive au bureau.
Internes
Les authentifications sur le bureau Windows (que ce soit via la console ou l’accès au bureau à distance) sont appelées connexions » interactives « . La stratégie de groupe nous permet de restreindre qui peut se connecter de manière interactive, mais cette même stratégie contrôle également l’utilisation de la commande « exécuter en tant que ». (Windows utilise le même type d’ouverture de session lorsque vous établissez une authentification secondaire, même si aucun bureau supplémentaire n’est affiché.) Ainsi, il n’y a aucun moyen direct (via la politique) de restreindre l’un, mais pas l’autre. La stratégie de groupe
permet à un compte utilisateur d’avoir un « shell » différent spécifié (le shell normal est « Explorer.EXE »). Nous pouvons utiliser cette fonctionnalité pour forcer une session interactive à se déconnecter immédiatement au lieu d’afficher le bureau Windows.
Procédure
- Créez ou sélectionnez une unité organisationnelle qui tiendra vos utilisateurs restreints à l’ouverture de session.
- Déplacer les utilisateurs dans le groupe (si nécessaire).
- Créez un objet de stratégie de groupe et appliquez-vous à l’unité d’organisation
- Modifiez l’objet de stratégie de groupe. Naviguer vers:
User Configuration > Policies > Administrative Templates > System
et définissez la stratégie nommée » Interface utilisateur personnalisée » sur » déconnexion.exe »
- Notez que cette politique ne s’appliquera pas immédiatement; vous devrez utiliser « gpupdate » sur vos systèmes si vous avez l’intention de tester immédiatement.
Précautions
- Utilisez uniquement la stratégie de groupe true pour ce paramètre. N’appliquez pas cette stratégie à l’aide de l’objet de stratégie de groupe » Local » de machines spécifiques, car elle s’appliquera ensuite à tous les utilisateurs. En effet, aucun utilisateur ne pourra se connecter à la machine (ce qui n’est probablement pas ce que vous voulez).
- Si vous appliquez cette stratégie aux comptes d’utilisateurs admin de domaine, veillez également à modifier la stratégie qui permet uniquement aux administrateurs de s’authentifier auprès des contrôleurs de domaine. Sinon, les seuls utilisateurs autorisés à se connecter au DCs seront immédiatement déconnectés (ce qui n’est probablement pas ce que vous voulez).
Limitations
Le but de cette procédure est uniquement de guider le comportement des utilisateurs légitimes en empêchant l’utilisation par inadvertance (ou paresseuse) de leur compte élevé pour les sessions de bureau. Il ne limite pas ce qu’un attaquant ou un administrateur malveillant peut faire avec ses informations d’identification. Rappelons que l’authentification sur le bureau interactif n’est pas nécessaire pour modifier un paramètre, y compris le retour de leur shell à « explorer.EXE ».
Il est donc toujours important de sécuriser les utilisateurs administratifs avec des informations d’identification à 2 facteurs.
