Comment évaluer les autorisations effectives pour les ressources sur des ordinateurs distants

Symptômes et causes

Lorsque vous vérifiez les autorisations effectives d’un utilisateur sur une ressource distante, vous voyez parfois des résultats ou des erreurs incorrects.

Les détails de ce comportement et de sa résolution dépendent de la façon dont vous obtenez les autorisations effectives, comme suit :

• Si vous utilisez une application Windows existante, vous pouvez utiliser l’onglet Accès effectif de la boîte de dialogue Sécurité avancée pour la ressource.

• Si vous utilisez l’INTERFACE de programmation d’applications (API) du moteur d’exécution Authorization Manager (Authz.dll), vous pouvez appeler les fonctions suivantes :

  • AuthzInitializeContextFromSid
  • AuthzInitializeRemoteResourceManager
  • AuthzAccessCheck
  • AuthzCachedAccessCheck

Windows Server 2012 R2 a introduit des modifications de la façon dont Windows évalue les autorisations effectives, en particulier pour les ressources distantes.

Utilisation de l’onglet Accès effectif

Si vous utilisez l’onglet Accès effectif, l’onglet peut afficher des erreurs ou des avertissements.

Pour plus d’informations sur la résolution de ces problèmes, consultez les ressources distantes, notamment SMB.

Utilisation des appels d’API Authz

Vous pouvez observer ce problème lorsque vous utilisez les appels d’API si l’une des conditions suivantes est remplie :

• L’application effectue les appels à distance à partir du serveur de ressources.
• Le compte d’utilisateur qui exécute l’application n’est pas dans le même domaine que la ressource.

Dans ce cas, certaines autorisations d’autorisation peuvent être manquantes, ou certaines autorisations Refuser peuvent apparaître en tant qu’autorisations GrantedAccessMask .

Voici un exemple de scénario :

• Il existe un groupe global dans le domaine A et un groupe local de domaine dans le domaine B. La ressource se trouve dans le domaine B.
• Le groupe local de domaine a un accès complet à la ressource. Cet accès inclut les autorisations De suppression .
• Le groupe global est membre du groupe local de domaine. Le groupe global n’a pas d’accès direct à la ressource.
• À l’aide d’un compte d’utilisateur de niveau administrateur et d’un ordinateur dans le domaine A, vous récupérez à distance les autorisations de ressource d’un utilisateur membre du groupe global.

Dans les résultats que vous récupérez, l’utilisateur n’a pas l’autorisation Supprimer pour la ressource. Toutefois, l’utilisateur dispose effectivement d’autorisations Delete .

Authz.dll utilise un service Kerberos pour une transaction Utilisateur (Kerberos S4U) pour obtenir un jeton pour l’utilisateur. Toutefois, ce jeton est relatif à la station d’administration ou à la station où l’application serveur s’exécute. Le jeton n’est pas relatif au serveur de ressources. Par conséquent, le jeton n’inclut pas les groupes locaux de domaine de l’ordinateur qui héberge la ressource si la ressource répond à l’une des conditions suivantes :

• La ressource se trouve dans un domaine différent de la station d’administration ou de l’utilisateur administratif.
• La ressource dispose d’autorisations affectées à des groupes intégrés. Les groupes intégrés peuvent être mal utilisés.

Obtenir des autorisations effectives à l’aide d’appels d’API Authz

Pour résoudre ce problème, utilisez l’une des méthodes suivantes :

• Utilisez la fonction AuthzInitializeRemoteResourceManager pour inclure un handle dans la ressource distante lorsque vous appelez la fonction AuthzInitializeContextFromSid .

• Contexte d’authentification local :

  • Si votre configuration active Kerberos S4U, vérifiez que le compte d’utilisateur administratif se trouve dans le même domaine que la ressource.
  • Si vous vérifiez les autorisations effectives pour un objet Active Directory, exécutez les outils d’administration sur un contrôleur de domaine qui a une copie complète de l’objet (contexte d’affectation de noms de configuration( NC), nc de domaine ou nc d’application).
  • Si vous vérifiez les autorisations effectives pour une ressource en cluster, vous pouvez exécuter les outils d’administration à partir de n’importe quel nœud de cluster. Vous pouvez également exécuter les outils d’administration à partir du serveur de ressources.

• Désactivez Kerberos S4U : basculez le moteur d’authentification de l’approche Kerberos S4U vers active Directory (AD) Lightweight Directory Access Protocol (LDAP) et les requêtes SAM (Server Security Account Manager) de serveur autonome pour collecter la liste des groupes de l’utilisateur.

  Important

  Suivez attentivement les étapes décrites dans cette section. De graves problèmes peuvent se produire si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegardez le Registre en cas de problèmes.

  Pour ce faire, procédez comme suit pour configurer l’entrée de Registre UseGroupRecursion :

  1. Ouvrez l’Éditeur du Registre, puis accédez à la sous-clé HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Authz .
  2. Sélectionnez Modifier>la nouvelle>valeur DWORD.
  3. Entrez UseGroupRecursion.
  4. Cliquez avec le bouton droit sur UseGroupRecursion, puis sélectionnez Modifier.
  5. Entrez 1, puis sélectionnez OK.

     Note

     Si la valeur est 0 (valeur par défaut), Authz utilise la méthode Kerberos. Si la valeur est 1, Authz utilise les requêtes SAM de serveurs AD LDAP et autonomes.

  6. Fermez l’Éditeur de Registre.

  Note

  • UseGroupRecursion n’est pas efficace si vous utilisez l’indicateur AUTHZ_REQUIRE_S4U_LOGON lorsque vous créez le contexte Authz.
  • L’utilisateur de l’application doit disposer d’autorisations de lecture pour l’attribut TokenGroups et pour les groupes locaux de domaine du domaine de ressources.
  • L’application doit pouvoir utiliser le protocole SAM RPC lorsqu’elle appelle les API. Cela est dû au fait que les groupes locaux serveur sont récupérés à l’aide d’API SAM. Vous pouvez définir une liste de contrôle d’accès (ACL) sur l’interface RPC SAM à l’aide de la stratégie de sécurité RestrictRemoteSAM .

Obtenir des autorisations effectives sur les ressources distantes, y compris les partages SMB

Windows Server 2012 R2 a ajouté une interface RPC Authz au processus LSASS. Cette interface est gérée par le service Netlogon. Avec l’aide de cette interface RPC, vous pouvez évaluer les autorisations effectives par rapport au serveur de ressources réel.

Cette mise à jour a également ajouté la possibilité d’évaluer les autorisations définies au niveau du système de fichiers et du partage. Lorsque vous utilisez cette fonctionnalité, vous voyez quelle partie de la vérification d’accès limite l’accès.

Lorsque vous évaluez l’accès effectif aux ressources, tenez compte des facteurs suivants :

• Autorisation sur le serveur distant
  • Pour évaluer les autorisations effectives d’une ressource sur un serveur distant, un utilisateur doit appartenir au groupe Opérateurs d’assistance du contrôle d’accès. Ce groupe intégré permet de déléguer plus facilement l’accès aux personnes qui n’ont pas d’accès administratif aux serveurs de ressources. Dans le cas contraire, les utilisateurs doivent disposer d’un accès administratif au serveur distant et au partage ou à une autre ressource.
• Accès aux informations de partage SMB

  • Autorisations permettant de récupérer le descripteur de sécurité pour le partage
    L’utilisateur peut également avoir un accès administratif aux descripteurs de sécurité de partage SMB. Par défaut, de nombreuses versions du système d’exploitation sur le marché n’accordent pas de tels accès. Pour recevoir une mise à jour qui fournit cette fonctionnalité, contactez Support Microsoft. La solution pour les versions du système d’exploitation sur le marché n’est pas disponible publiquement.

  • Accès au serveur (si la ressource utilise le contrôle d’accès au niveau du partage)
    Pour évaluer les autorisations effectives d’une ressource sur un serveur distant qui utilise le contrôle d’accès au niveau du partage, vous devez utiliser un chemin de partage UNC pour accéder à la ressource. N’essayez pas d’utiliser une lettre de lecteur mappée pour accéder à la ressource. Par exemple, n’utilisez pas de chemin qui ressemble au chemin suivant :

    f:\year2022\quarter2\
    

    Remarque : Dans cet exemple, f: correspond à \\fileserver01.contoso.com\finance-data.

    Utilisez plutôt un chemin qui ressemble au chemin suivant :

    \\fileserver01.contoso.com\finance-data\year2022\quarter2\
    

Si vous n’utilisez pas d’autorisations de partage pour restreindre les utilisateurs, vous pouvez ignorer en toute sécurité l’avertissement des autorisations de partage.