none
Black listé un compte admins du domaine sur certain postes RRS feed

  • คำถาม

  • Bonjour à tous,

    Voici la question du weekend !

    J'hérite d'un SI qui dispose de plusieurs comptes administrateurs du domaine historique fortement couplé avec tout un tas de service et d'applications. Il sera long et difficile de revenir sur cette situation. Pour limité le risque, je souhaiterai pouvoir isoler ces comptes et les black lister sur les part du SI ou je suis sur qu'ils ne sont pas nécessaire.

    En gros existe-t-il un mécanisme ou une couche de sécurité pour refuser qu'un utilisateur administrateur du domaine puisse se connecter à une partie du parc ?

    Qu'en pensez vous ?

    A+

    13 กันยายน 2562 12:48

ตอบทั้งหมด

  • Bonjour, 

    Je pense que l'ideal de créer un nouveau groupe et ajouter ces comptes et donner par example seulement le droits d'un administrateur local sur une partie du parc (via GPO: Restricted groups)

    Mais tant que ces utilisateurs sont dans le groupe administrateur de domaine par défaut ils gardent toujours les droits admins.


    Vote or mark as answer if you think useful

    13 กันยายน 2562 13:01
  • Bonjour,

    La solution, c'est de créer un GPO appliqué aux machines concernées et dans lequel vous ajustez les paramètres suivants :

    Ordinateur > Paramètres Windows > Paramètres de Sécurité > Stratégies Locales > Attribution de droits d'utilisateur  :

    • Interdire l'accès à cet ordinateur à partir du réseau 
    • Interdire l'ouverture d'une session locale
    • Interdire l'ouverture de session en tant que service
    • Interdire l'ouverture de session en tant que tâche
    • Interdire l'ouverture de session par les services Bureau à distance



    Cordialement,

    Sylvain (MCP, MCTS Windows Server 2008 R2 Server Virtualization, MCTS Exchange 2010)

    WWW : http://snsv.consulting | Blog : http://sylvaincoudeville.fr

    "Aléatoire" et "Mystérieux" sont des qualificatifs inventés par l'Homme pour éviter de dire qu'il n'a pas trouvé la root cause du problème...

    13 กันยายน 2562 13:01
  • En gros existe-t-il un mécanisme ou une couche de sécurité pour refuser qu'un utilisateur administrateur du domaine puisse se connecter à une partie du parc ?

    C'est un peu le principe de l'administration en silo  et l'authentification composés (voir vers la 20 minutes) :

    https://www.sstic.org/2017/presentation/administration_en_silo/

    Il y a deux éléments qui sont intéressants à étudier :

    - le cloisonnement physique du réseau en différente zone de sécurité

    - la limitation de l'utilisation des protocoles d'authentification pour les comptes à privilège (comme NTLM ancien). Voir entre autre : http://www.pbarth.fr/node/334

    L'étape la plus délicate et de faire le point sur l'existant, j'utilise des scripts PowerShell qui me liste sur tous les serveurs par exemple les services qui tournent sur un compte spécifique ainsi que les tâches planifiées. Cela donne déja une idée de la situation.

    14 กันยายน 2562 6:42
  • Bonjour à tous,

    Merci pour vos pistes :) !

    La GPO locale me semble une super idée, avec un groupe AD dédié au compte à exclure cela  doit pouvoir déboucher sur un résultat super intéressant.

    Les autres pistes sont en cours (zoning réseau, protocole, etc...), mais ne seront pas applicable avant un certain temps !

    N'hésitez pas si vous avez d'autres idées

    A bientôt.

    16 กันยายน 2562 14:15
  • Si jamais, en 5 minutes avec les stratégies d'authentification, comment limiter l'utilisation des comptes admins :

    http://www.pbarth.fr/node/339

    Bon c'est possibile de faire encore mieux en utilisant les revendication et les silos.
    11 ตุลาคม 2562 14:43
  • Bonjour,

    je pense qu'il y un autre moyen de gérer cela, peut être d'une manière plus facile… sans stratégie ni modification des droits sur toutes les machines du réseau.

    Au lieu de définir là où un compte n'a pas le droit d'aller, ce qui peut être assez complexe (et mouvant), il est plus simple de gérer l'ensemble des machines sur lesquelles il peut ouvrir une session.

    En effet, sur chaque compte AD, il est possible de définir par défaut jusqu'à 10 "noms" de machine où une session est autorisée. Si cela ne suffit pas, il est possible de modifier cette valeur limite:

    https://support.microsoft.com/en-us/help/243327/default-limit-to-number-of-workstations-a-user-can-join-to-the-domain

    A bientôt,


    Thierry DEMAN-BARCELO. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2016(87 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate https://base.faqexchange.info

    12 ตุลาคม 2562 15:27
  • Bonjour,

    Mon point de vue :

    • La solution de Thierry tiens la route, mais à des limitations qu'il donne lui-même (10 machines max). Ne peut-être appliquée partout.
    • La solution de Philippe restreint les ouvertures de session, mais on peut effectuer des gestes d'administration sans ouverture de session (Remoter Shell, Remote Management). Pas adpaté dans cette situation.
    • La proposition de Sylvain est totalement adaptée mais elle requiert de bien identifier les groupes qui doivent avoir les droits d'accès, puis d'alimenter les 5 propriétés citées pour la GPO.
    • La solution de F. ABASSI mais complétée me parait la plus adaptée, mais il faut que la dite GPO soit exclusive ("This Group is member of")
    1. - Totalement adaptée : Si tu n'est pas membre du groupe Administrators local, fini le RemoteShell, le RemoteManagement, le RDP, les tâches planifiées, les services.
    2. - C'est la plus simple à mettre

    En pratique

    • Identification des groupes d'Administration qui doivent rester dans le groupe Administrator local
    • Création d'une GPO "Groupe Restreint mais exclusive (c'est à dire que tout ce qui n'est pas dans les groupes qui sont définis par la GPO pour peupler le groupe Administrators local, va dégager. Utiliser "this group is member of").

    https://social.technet.microsoft.com/wiki/contents/articles/20402.active-directory-group-policy-restricted-groups.aspx

    • Lier la GPO à 1 serveur pour tester. Un petit GPupdate /force sur la machine en question, suivi d'un oeil sur les membres du groupe Administrators local. Ca marche ? OK, on passe à l'étape suivante.
    • Extension à une ou plusieurs OUs. On ne touche plus à la GPO, elle est validée, on étend juste son scope.

    Nota 1 : Cela n'empêchera jamais quelqu'un qui dispose des droits Admin sur la machine d'ajouter un compte directement dans le groupe Administrators local, mais dès la réapplication de la GPO - soit tous les 90 Min plus ou moins 30 min - ca va remettre tout d'équerre.

    Nota 2 : Bien faire attention aux groupes (d'administration bien sur) qui doivent rester dans le groupe Administrators local, ça serait ballot de se couper l'herbe sous le pied.

    Nota 3 : Que ceux qui accordent des droits - qui plus est d'admin - directement à des comptes utlisateurs  au lieu de groupes comme il se devrait, soient pendus haut et court jusqu'à ce que mort s'en suive. Et si c'est un admin qui l'a fait, qu'il se pende lui-même. Non, mais quoi ! On a le droit de faire n'importe quoi si on veut, mais en rève seulement !

    Olivier

    < Comment ça je m'énerve ? >

    < Je m'énerve pas, Simone, j'explique au Monsieur,>

    12 ตุลาคม 2562 18:15
  • La solution de Philippe restreint les ouvertures de session, mais on peut effectuer des gestes d'administration sans ouverture de session (Remoter Shell, Remote Management). Pas adpaté dans cette situation.

    Non elle ne restreint pas l'ouverture de session mais l'authentification ... Ce n'est pas pareil du tout.  

    13 ตุลาคม 2562 21:19
  • Bonsoir,

    La solution de Thierry tiens la route, mais à des limitations qu'il donne lui-même (10 machines max). Ne peut-être appliquée partout.

    => Non, comme je l'ai indiqué, on peut très facilement modifier la valeur limite !

    A bientôt


    Thierry DEMAN-BARCELO. Offce Apps&Services MVP. MCSE:Messaging 2016,MCSE:Server Infrastructure 2016(87 MCPs). MCSA Office 365,Microsoft 365 Certified: Messaging Administrator Associate,Modern Desktop Administrator Associate https://base.faqexchange.info

    13 ตุลาคม 2562 21:45