Vérifier qu'un utilisateur donné a un privilège donné

Étant donné une paire d'utilisateurs et un privilège, je dois déterminer si un utilisateur a le privilège sur le serveur. Ce qui suit est vrai dans ma configuration:

Le serveur fait partie d'un domaine mais pas un contrôleur de domaine
Il existe plusieurs domaines avec une relation de confiance dans l'infrastructure
Parfois, les utilisateurs (local, domaine ou d'un autre domaine) peuvent appartenir à un groupe local en raison de leur mérite d'être dans un autre groupe (domaine ou local) qui appartient à un groupe local, par opposition à appartenir directement au groupe.

Exemple de scénario pour le dernier point:

L'utilisateur 1 appartient au groupe TeamA dans le domaine A
DomaimA \ TeamA est membre de DomainB \ SpecialAccess
DomainB \ SpecialAccess est membre de DomainB \ DomainAdmins
Enfin, DomainB \ DomainAdmins appartient au groupe Administrateurs local
Le groupe Administrateurs locaux a le privilège SeRemoteInteractiveLogonRight

Maintenant, si j'ai sur l'entrée DomainA \ User1 et SeRemoteInteractiveLogonRight, je dois arriver à une réponse Oui ou Non. Donc j'ouvre la stratégie locale sur la machine, note quels groupes sont listés contre la droite, je m'intéresse aussi, puis va aux gestionnaires de serveurs et vois ce que les membres du groupe et puis j'ai besoin de voir quels membres de n'importe quel groupe dans ces groupes etc.

J'ai l'intuition que cela peut être plus facile. J'étais vraiment excité quand j'ai trouvé l' utilitaire AccessChk. Cela a duré trois minutes entières, ce qui m'a pris pour découvrir qu'il ne répertorie que les relations directes, donc l'utilisateur au sein d'un groupe ne sera pas répertorié.

Maintenant, je suppose qu'il serait possible de combiner les résultats d'AccessChk pour que je puisse vérifier si un utilisateur appartient à l'un des groupes renvoyés par AccessChk, mais étant donné qu'il ne s'agit pas d'un seul domaine mais de plusieurs d'entre eux, je suis ne sais pas comment aborder cela. La sortie AccessChk ne semble pas non plus faire la distinction entre un groupe et un utilisateur.

EDIT : Dans l'esprit de ne pas tomber dans le piège des problèmes XY, ce que je dois vraiment faire est de m'assurer que sur un groupe de serveurs aucun compte d'utilisateur spécifique utilisé comme identités de pool d'applications IIS ne dispose des privilèges SeInteractiveLogonRight ou SeRemoteInteractiveLogonRight. Je n'ai aucun problème avec la partie IIS, mais la dernière étape de vérification d'un compte par rapport à un privilège est quelque chose que j'ai du mal à trouver un moyen simple de vérifier. Je voudrais également automatiser la vérification car c'est quelque chose qui devra être fait régulièrement.

— Andrew Savinykh
source

Cela ressemble à un travail pour ... Ensemble de politiques résultant (RSoP)! technet.microsoft.com/en-us/library/cc758010%28v=WS.10%29.aspx

— Davidw

@zespri - Ma réponse était une ordure et je l'ai supprimée. Les droits d'utilisateur SeInteractiveLogonRight et SeRemoteInteractiveLogonRight sont traités différemment des privilèges "normaux" et il semble que leur communication va être problématique. Si je trouve une solution pour vous, je posterai une autre réponse mais, pour l'instant, je n'ai rien.

— Evan Anderson

@Davidw - RSoP est problématique dans la mesure où les valeurs par défaut de la stratégie de sécurité locale ne seront pas reflétées dans la sortie. Ainsi, toutes les entrées «non configurées» s'afficheront simplement comme «non configurées» et vous ne verrez pas réellement quels principaux sont accordés le droit par la politique de sécurité locale. Enfin, même si vous obtenez une liste des principaux de la stratégie de groupe, vous serez bloqué en étendant les appartenances aux groupes (potentiellement inter-domaines également) pour répliquer les fonctionnalités du système d'exploitation. Cela s'est avéré être une question beaucoup plus difficile que je ne pensais.

— Evan Anderson

@EvanAnderson Exactement! Quand on m'a demandé d'estimer combien de temps cela allait me prendre, cela semblait être une tâche simple. Et après quelques jours à googler et à essayer différentes choses ... rien. Actuellement, mon plan est d'exploiter GetTokenInformation avec la classe d'informations de jeton TokenPrivileges Bien sûr, je dois d'abord trouver comment obtenir le jeton lui-même. Cette route semble pour l'instant la plus prometteuse.

— Andrew Savinykh

@zespri - NtOpenProcessToken () est probablement le meilleur moyen d'obtenir le jeton. (Jetez un œil sur leeholmes.com/blog/2006/07/21/… )

— Evan Anderson

Les jetons d'accès n'ont pas d'informations sur les droits, mais uniquement sur les privilèges.

Ce que vous devez faire est le suivant:

Recherchez le processus de travail IIS qui correspond à votre pool d'applications. Puisque vous connaissez l'identité du pool d'applications, cela devrait être facile en énumérant tous les processus avec le nom du processus de travail et en filtrant celui qui a l'identité. S'il y en a plusieurs, vous pouvez en utiliser n'importe lequel.
Utilisez GetTokenInformation avec la classe d'informations TokenGroup, pas le TokenPrivilege sur le jeton de processus. Le résultat vous donnera également tous les groupes transitifs auxquels appartient l'identité. Cela signifie même indirects.
Vous pouvez maintenant parcourir ces groupes et appeler LsaEnumerateAccountRights sur chacun d'eux et rassembler les informations. Cela vous donnera ce que vous voulez.

Ce qui précède repose sur l'existence du processus (et du jeton) correspondant à l'identité du compte. Dans votre scénario, cela ne devrait pas poser de problème. Dans les scénarios où cela pose problème, vous pouvez essayer d'utiliser la recherche Active Directory pour l' attribut calculé Token-Groups . Cet article répertorie quelques approches pour résoudre ce problème.

— Andrew Savinykh
source