web-dev-qa-db-fra.com

Comment découvrez-vous les autorisations d'un groupe AD si vous n'avez pas de documentation?

Vous venez d'être embauché dans l'entreprise A et l'ancien administrateur n'est plus là. Les demandes commencent à passer pour ajouter des utilisateurs au groupe de restriction Internet. Lorsque vous regardez les groupes, aucun des noms n'a de sens et il n'y a pas de documentation pour expliquer à quoi chaque groupe a droit et ce qu'il fait. Cela m'inquiéterait. Pour la sécurité, comment savoir si tout le monde a les droits appropriés.

Comment découvririez-vous les droits des groupes? Existe-t-il un outil qui trouvera ces informations pour vous?

windowsaccess-controlactive-directory
20
Ambar Batista

Permettez-moi de préfacer ce qui sera probablement une réponse assez longue avec "Il n'y a pas de solution simple".
Pour résoudre ce problème, il faudra un certain travail stratégique (c'est pourquoi j'ai recommandénotle déplacer vers SF).

Je vais maintenant expliquer pourquoi.

Windows, à sa base, est principalement basé sur le modèle DAC de contrôle d'accès.
Toutdans le système d'exploitation est sécurisable avec une ACL - fichiers, dossiers, registre, canaux nommés, sockets, partages, etc. etc.

L'utilisation de groupes AD vous permet de résumer cela dans un modèle de type RBAC, mais en interne, il s'agit toujours d'un modèle DAC. (Ce que je veux dire, c'est que vous pouvez créer un ACE (entrée de contrôle d'accès) pour un groupe (c'est-à-dire un rôle), mais vous créez toujours un ACE - et c'est ce qui sera vérifié lors de l'accès).

Accent sur"principalement".
Il existe quelques exceptions distinctes à cela:

  1. Il existe une certaine implémentation de MAC - c'est-à-dire des niveaux d'intégrité (dans Vista/7/2008).
    Cependant, il s'agit généralement d'un mécanisme de protection interne du système d'exploitation et est généralementnotutilisé pour un contrôle d'accès réel (autre que l'UAC intégré). Habituellement .
  2. Privilèges au niveau du système d'exploitation. (Bien qu'il soit possible de spécifier un utilisateur spécifique auquel accorder ces privilèges, il est destiné - et fonctionne comme - un modèle RBAC).

Mais attendez, c'est juste dans le système d'exploitation lui-même ...
Windows, en tant que plate-forme, autorise et encourage les applications (tierces parties, produits MS et extensions OS) à utiliser l'appartenance au groupe AD en tant que mécanisme RBAC:

  1. Les applications tierces peuvent vérifier l'appartenance au groupe via une simple recherche AD/LDAP - ces applications peuvent stocker le nom du groupe et le résoudre, ou enregistrer le SID du groupe et interroger directement pour cela.
  2. N'oubliez pas SQL Server - ceci est principalement basé sur (plusieurs types différents de) rôles, mais les meilleures pratiques sont généralement recommandées pour ajouter ADgroupsà ces rôles, et non les utilisateurs directement.
  3. Tant que nous y sommes, COM + gère également l'accès par RBAC, mais encore une fois, la meilleure pratique consiste à ajouter des groupes, pas des utilisateurs, aux rôles COM +.
  4. Sharepoint gère également l'accès aux sites en fonction des rôles/groupes/et listes de diffusion ...

Commencer à voir mon point?
Je ne veux pas dire que c'est sans espoir, MAIS ...

Récapituler:
Afin de trouver la liste définitive des autorisations dont dispose un groupe spécifique, vous (ou un outil) devez vérifier récursivement TOUS les éléments suivants (et, n'oubliez pas de demander aussi l'appartenance au groupe):

  • Pour chaque serveur de votre organisation:
    • vérifier récursivement ACL sur tous les dossiers et fichiers
    • vérifier récursivement SACL sur tous les dossiers et fichiers (listes de contrôle d'accès système - ces audits de contrôle)
    • vérifier récursivement le propriétaire sur tous les dossiers et fichiers
    • vérifier récursivement ACL, SACL et le propriétaire sur toutes les clés de registre
    • vérifier récursivement ACL, SACL et le propriétaire sur tous les canaux, processus et threads nommés, services, travaux, etc.
    • Vérifiez tous les privilèges au niveau du système d'exploitation (bien qu'il soit possible que cela soit plus facile à l'aide des GPO ...)
    • Vérifiez tous les rôles COM +, les rôles MSMQ, etc.
  • Pour chaque domaine de votre AD:
    • Vérifier tous les privilèges au niveau du domaine
    • vérifier tous les GPO (objets de stratégie de groupe)
  • Pour chaque serveur de base de données:
    • Vérifier tous les rôles de serveur
    • vérifier tous les rôles de base de données
    • vérifier tous les rôles d'application (dans MSSQL)
  • Pour chaque portail Sharepoint:
    • vérifier tous les rôles et privilèges au niveau du serveur
    • vérifier tous les rôles et privilèges au niveau du site et au niveau de la liste
  • Pour chaque application tierce:
    • Vérifiez toute utilisation des groupes AD
    • vérifiezcommentl'application utilise ces rôles:
      -> Nom de groupe vs DN vs SID de groupe vs ... par ex. GUID de groupe
      -> l'application vérifie-t-elle explicitement l'appartenance à un rôle direct ou utilise-t-elle les méthodes récursives "plus intelligentes"?
    • Notez que cela s'applique à la fois aux produits et plateformes packagés tiers (par exemple Oracle, SAP, MQSeries, WebSphere ...) et aux applications métier développées sur mesure.

Est-ce complet?
Malheureusement non. Par exemple, je n'ai pas inclus l'examen de tousdesktopsdans l'organisation, car cesshouldntont des autorisations spécifiques au niveau du groupe AD mis sur eux (sauf par exemple pour les administrateurs et HelpDesk) - mais notez qu'ils le font souvent.
Mais ce n'est pas une liste complète ...

C'est le gros inconvénient de l'utilisation d'un modèle DAC - le "D" aurait tout aussi bien pu être pour "Distributed", car il n'y a pas de place centrale pour rechercher toutes ces ACL.
Comme je l'ai noté dans Quelle est la différence entre RBAC et DAC/ACL? :

  • Les définitions DAC sont généralement attachées aux données/ressources, tandis que RBAC est généralement défini à deux endroits: dans le code/configuration/métadonnées (l'accès aux rôles) et sur l'objet utilisateur (ou la table - les rôles de chaque utilisateur).

Maintenant, un peu de solutions:

  • Il existe plusieurs outils pour collecter différentes parties des listes ci-dessus, par ex. @ Réponse d'Ian à l'aide de scripts PowerShell pour collecter les ACL de dossier. Il existe de nombreux autres outils pour cela (j'ai été connu pour utiliser CACLS dans le passé), certains sont notés ici .
    Pour demander un outil/script pour une partie spécifique de la liste, vous pourriez avoir de meilleures idées sur ServerFault. Cependant, sachez que ce n'est qu'une partie de la liste.
  • Il existe des produits de "gestion des rôles" et de "découverte des rôles", provenant de certains des grands fournisseurs, généralement dans l'espace de gestion des identités - je ne peux pas en recommander spécifiquement un, mais cela vaut la peine d'être étudié: CA (anciennement Eurekify qui était un outil décent (mais pas complet)), IBM , Oracle .
    Bien sûr, il y en a d'autres, et je pencheraisfortementvers la recherche de petits fournisseurs de premier ordre, même à partir d'une startup (d'accord, peut-être que je suis biaisé;)). Je veux dire, de ceux qui n'ont pas été rachetés par les plus gros vendeurs.
  • Vous pourriez (et probablement devriez, bien que ce soit loin d'être trivial) démarrer le processus de cartographie de l'organisation, des exigences commerciales, etc. - en visantquels privilèges ils devrait obtenir, et pas seulementquel est le statu quo en ce moment . Certains des outils mentionnés dans le point précédent pourraient aider ici.
  • Si l'analyse et la modélisation des rôles précédentes se déroulent bien, pensez à opter pour une solution IdM/IAM/EAM complète. Encore une fois, mes commentaires par rapport aux fournisseurs sont toujours valables.
  • Dans tous les cas, visez à minimiser la distribution des ACL partout, et faites pression pour un RBAC minimal, centralisé autant que possible.

Et, un dernier mot d'avertissement à ceux qui ont la chance d'êtreavantla situation désagréable dans laquelle vous vous trouvez actuellement:
Certainementrecherchez une plate-forme d'autorisation centralisée, telle que les produits IdM/IAM/EAM. (Notez que certains sontbeaucoupmeilleurs que d'autres, et certains ne résoudraient même pas cette situation non plus.)

tl; dr: Vous êtes à juste titre et vraiment fout . Voir ci-dessus. ;)
(mais tout espoir n'est pas perdu ...)

23
AviD

La réponse à cela dépend exactement de la façon dont vous souhaitez voir/gérer ces données. Ma recommandation serait PowerShell pour obtenir tout cela.

Si vous choisissez d'utiliser PowerShell, vous pouvez utiliser les applets de commande AD natives ou les applets de commande gratuites de Quest (http://www.quest.com/powershell/activeroles-server.aspx). Pour utiliser les applets de commande natives, vous devez avoir au moins un contrôleur de domaine Windows Server 2008 R2 dans votre domaine ou au moins une instance dans un jeu de configuration AD LDS qui s'exécute sur un serveur Windows Server 2008 R2 - voir http: //technet.Microsoft.com/en-us/library/ee617195.aspx pour plus de détails.

En effet, tout ce que vous avez à faire est de vérifier récursivement les listes de contrôle d'accès des dossiers pour le niveau d'accès d'un groupe particulier. Il y a quelques endroits ( ici et ici ) où les gens font des tentatives, mais étant donné que c'est probablement une quantité incroyablement grande de structure de fichiers que le script doit parcourir, il pourrait certainement prendre un certain temps. Cela devient encore plus compliqué pour les groupes imbriqués.

EDIT: @AviD est parfait sur la syntaxe de commande d'origine, et il faisait complètement la mauvaise chose! Modifié pour être plus sur le sujet.

4
Ian Pugsley

Cela peut être fait via l'invite de commande Windows comme suit:

  • Accédez au répertoire dans lequel vous souhaitez enregistrer votre rapport, si aucun n'est sélectionné, il doit par défaut être le répertoire de l'utilisateur connecté. Un exemple serait cd C:\Users\Administrator\Desktop

  • Générez un rapport à l'aide de la commande suivante:

    gpresult /s servername /user INTERNAL\user1 /h gpreport.html

  • La commande ci-dessus générera un rapport basé sur le GPOS et les règles appliquées à l'utilisateur pour lequel le rapport est sélectionné. Cet utilisateur doit être quelqu'un qui est membre d'un certain groupe ou vous pouvez créer un utilisateur de test pour tester les paramètres d'un certain groupe.

  • Vous pouvez également trouver ces informations en modifiant le GPO et sous Windows 2008, vous devriez avoir la possibilité de voir tous les paramètres et de les trier par état, vous pouvez ensuite enregistrer tous les paramètres activés du GPO.

1
Brian Winning Jr.