1 votes

Les règles dynamiques de Windows 10 AppLocker pour les groupes d'utilisateurs ne fonctionnent pas

J'essaie de créer des règles de blocage d'applications dynamiques avec AppLocker. La configuration est la suivante : j'ai des règles AppLocker prédéfinies (par exemple, Allow windows user group 'Chrome' access 'chrome.exe' (pas le nom du groupe ou le chemin d'accès réel)) et affecte ensuite les utilisateurs aux groupes lors de l'ouverture de session à l'aide d'un service Windows.

Cela a bien fonctionné au début, mais après un certain temps, cela s'est arrêté (AppLocker lui-même fonctionnait, mais les règles spécifiques aux groupes d'utilisateurs ne s'appliquaient pas - en d'autres termes, tout était bloqué). J'ai testé toutes les politiques combinées via les commandes PowerShell, et selon elles, l'utilisateur qui appartient au groupe d'utilisateurs Chrome doit être autorisé à accéder aux chrome.exe mais en réalité, j'obtiendrais un message d'alerte bloquant l'application.

J'ai ensuite essayé de créer une règle spécifique pour l'utilisateur afin d'autoriser chrome.exe qui a bien fonctionné, mais dès que je l'ai supprimée (la règle de groupe existe toujours), j'ai été à nouveau bloqué. Ou encore, le simple fait de modifier la politique de groupe d'utilisateurs existante pour qu'elle pointe vers un utilisateur spécifique a permis de faire fonctionner les choses, puis le fait de revenir à une règle de groupe d'utilisateurs n'a pas permis de faire fonctionner les choses à nouveau.

Ce qui est amusant, c'est qu'après quelques redémarrages de la VM, cela a fonctionné à nouveau, et le lendemain, lorsque j'ai voulu faire une démonstration à un collègue, j'ai eu à nouveau le même problème, qui a été résolu à nouveau par de multiples redémarrages de la VM.

Un problème évident pourrait être "l'utilisateur appartient-il vraiment au groupe ?" et la réponse est oui : chaque fois que la politique ne fonctionnait pas, j'entrais dans la section lusrmgr et vérifier que.

Pour plus de contexte - la VM est hébergée sur Azure, fonctionnant sous Windows 10 multi-session 21H1, AppLocker est configuré au niveau de la machine locale (pas de politiques à l'échelle du domaine ou quoi que ce soit de ce genre pour l'instant).

1voto

SamErde Points 3134

La raison de l'échec de l'application automatisée de cette règle est que des utilisateurs sont ajoutés à des groupes après qu'ils se sont connectés.

Lorsque vous ajoutez un utilisateur à un groupe, son appartenance à ce groupe ne prend effet qu'à sa prochaine connexion (tant que son compte reste dans ce groupe). À l'ouverture de la session Le jeton Kerberos d'un utilisateur est généré sur la base d'une combinaison du SID de son compte et des SID de tous les groupes dont il est membre. Lorsque des opérations basées sur les groupes sont vérifiées pour un utilisateur (ACL, politiques AppLocker, etc.), c'est le jeton Kerberos qui est vérifié.

Il existe de nombreuses solutions différentes, qui dépendent d'un grand nombre de facteurs dans votre environnement. Deux solutions pourraient être envisagées :

  • Utiliser des groupes de sécurité basés sur le domaine pour attribuer aux utilisateurs l'accès aux applications. Ceux-ci seraient présents avant qu'ils ne se connectent, et leur jeton Kerberos serait complet. Cette approche est de loin préférable à la "solution" ci-dessous.
  • Si vous ne pouvez pas utiliser les groupes basés sur le domaine, vous pourrait exécuter un script après que votre service Windows a ajouté l'utilisateur à un groupe. Pour mettre à jour manuellement le jeton Kerberos d'un utilisateur en fonction des changements d'appartenance à un groupe après qu'ils se sont connectés, et sans leur demander de se déconnecter ou de se reconnecter, exécutez la commande klist purge . Cela forcera la régénération de leur jeton Kerberos, qui inclura alors leur nouvelle appartenance à un groupe. À ce stade, vos politiques AppLocker dynamiques fonctionnent.

klist : https://docs.microsoft.com/en-us/Windows-server/administration/Windows-commands/klist

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X