locked
Suppresion du groupe "Utilisateurs" de la stratégie locale d'une machine(gpedit.msc) RRS feed

  • Question

  • Bonjour,

    Je souhaite mettre en place une GPO pour des restrictions d'accès sur un domaine Active Directory, j'ai trouvé le paramètre: Config Ordi--> paramètre de sécurité -->Stratégie Locale-->Attribution des droits utilisateur--> Permettre l'ouverture Ouverture une session en local, je l'ai appliqué et autorisé l'admin du domaine et l'administrateur local , mais le souci que je rencontre c'est qu'au niveau local des machines je trouve le groupe "Utilisateurs" au niveau de la stratégie locale: Gpedit.msc-->Attribution des droits utilisateur-->Ouvrir une session localement, ce qui empêche l'application de la GPO,

    Est ce qu'il y a la possibilité de supprimer/et ou ajouter par GPO ou par script ce groupe "Utilisateurs" au niveau local des machines?

    Merci pour votre aide.

    jeudi 3 janvier 2013 16:34

Réponses

  • Bonsoir,

    comment se manifeste la non-application de la GPO ?

    Il est très dangereux de toucher aux groupes de ce type sans voir toutes les implications !

    Le groupe local "utilisateurs" contient le groupe "Utilisateurs du domaine". Le groupe "Utilisateurs du domaine" contient donc tous les utilisateurs du domaine y compris les administrateurs! Lui appliquer des restrictions peut apporter de nombreux soucis.

    En terme de stratégies, il est tout à fait possible d'utiliser ou de retirer le groupe local "Utilisateurs", tout simplement en utilisant le groupe local correspondant du domaine. Ce groupe a un ID unique !

    A bientôt,


    Thierry DEMAN. Exchange MVP. MCSA Windows Server 2012 (73 MCPs). https://mvp.support.microsoft.com/profile=CE2B565B-B13D-4C24-B04D-F0D5766D14A1 http://www.faqexchange.info

    jeudi 3 janvier 2013 17:01
  • Bonjour

    ce que Thierry indique est qu'il y aura des effets de bord conséquent en appliquant ce type de paramétrage.

    Par ailleurs, même s'il s'agissait d'un besoin en terme de sécurité, cette solution n'est au contraire pas sécurisé.

    Quel est le but de l'opération ?

    Maintenant si vous voulez absolument réaliser cette opération, créez un groupe restreint au niveau de votre GPO, le groupe restreint étant BUILTIN\Utilisateurs (ou BUILTIN\Users si la GPO est édité depuis un poste avec une langue Anglaise).

    Indiquez alors que les membres de ce groupe sont "BUILTIN\Administrators" et "DOM\Domain Admins" (et également Utilisateurs authentifiés pour que les GPO fonctionnent au niveau des ordinateurs).

    Ainsi le groupe Utilisateurs local ne sera pas vide mais rempli que des groupes nécessaires.

    Je ne recommande cependant pas cette configuration.

    A bientôt


    Freddy ELMALEH aka "bigstyle" - Consultant Freelance pour Active IT (Active IT)
    MVP Windows Server - Directory Services
    MCITP Enterprise Administrator (2008) - MCSE 2000/2003 Security - MCSA Messaging 2000/2003
    Bibliographie (Administration avancée sous Windows 2008 R2, La sécurité sous Windows 7, etc.)
    FaceBook Twitter LinkedIn

    vendredi 4 janvier 2013 08:27
  • Bonjour,

    En effet, Après plusieurs vérifications, j'ai trouvé un souci local au niveau des machines (modèle de sécurité appliqué) que j'ai réglé.

    Donc, plus besoin de supprimer le groupe utilisateurs local pour interdire l'ouverture de session domaine sur les machines,

    Actuellement, le Rsop indique que la GPO est bien appliquée, pas de message d'erreur,
    Cependant,le souci qui se pose maintenant : j'applique la GPO avec le paramètre: permettre l’ouverture d'une session locale-->admins domaine + admin local comme groupe et user-->le résultat: au niveau de la machine aucune session ne s'ouvre, y compris admins domaine et locale(msg : la stratégie locale ne vous permet pas d'ouvrir une session d'une manière interactive), PAR CONTRE, quand je me connecte en bureau distant: les sessions admins domaine et admin locale s'ouvrent correctement??

    Avez-vous svp une idée sur l'origine de cette anomalie?

    Merci.


    lundi 7 janvier 2013 20:59

Toutes les réponses

  • Bonsoir,

    comment se manifeste la non-application de la GPO ?

    Il est très dangereux de toucher aux groupes de ce type sans voir toutes les implications !

    Le groupe local "utilisateurs" contient le groupe "Utilisateurs du domaine". Le groupe "Utilisateurs du domaine" contient donc tous les utilisateurs du domaine y compris les administrateurs! Lui appliquer des restrictions peut apporter de nombreux soucis.

    En terme de stratégies, il est tout à fait possible d'utiliser ou de retirer le groupe local "Utilisateurs", tout simplement en utilisant le groupe local correspondant du domaine. Ce groupe a un ID unique !

    A bientôt,


    Thierry DEMAN. Exchange MVP. MCSA Windows Server 2012 (73 MCPs). https://mvp.support.microsoft.com/profile=CE2B565B-B13D-4C24-B04D-F0D5766D14A1 http://www.faqexchange.info

    jeudi 3 janvier 2013 17:01
  • Bonsoir,

    Si le groupe Utilisateurs local existe, même si j'applique la GPO, le résultat est négatif, j'arrive à ouvrir toutes les sessions !

    par contre quand je le supprime manuellement en administrateur, le résultat du test est positif: seulement les sessions Admin local et domaine s'ouvrent!

    Pouvez-vous svp me donner plus de détail sur comment je peux retirer ou ajouter le groupe local Utilisateurs par GPO ou bien par script si possible? j'ai essayé de le le faire par GPO mais en vérifiant en local, il existe toujours.

    Merci.

    jeudi 3 janvier 2013 22:22
  • Bonjour

    ce que Thierry indique est qu'il y aura des effets de bord conséquent en appliquant ce type de paramétrage.

    Par ailleurs, même s'il s'agissait d'un besoin en terme de sécurité, cette solution n'est au contraire pas sécurisé.

    Quel est le but de l'opération ?

    Maintenant si vous voulez absolument réaliser cette opération, créez un groupe restreint au niveau de votre GPO, le groupe restreint étant BUILTIN\Utilisateurs (ou BUILTIN\Users si la GPO est édité depuis un poste avec une langue Anglaise).

    Indiquez alors que les membres de ce groupe sont "BUILTIN\Administrators" et "DOM\Domain Admins" (et également Utilisateurs authentifiés pour que les GPO fonctionnent au niveau des ordinateurs).

    Ainsi le groupe Utilisateurs local ne sera pas vide mais rempli que des groupes nécessaires.

    Je ne recommande cependant pas cette configuration.

    A bientôt


    Freddy ELMALEH aka "bigstyle" - Consultant Freelance pour Active IT (Active IT)
    MVP Windows Server - Directory Services
    MCITP Enterprise Administrator (2008) - MCSE 2000/2003 Security - MCSA Messaging 2000/2003
    Bibliographie (Administration avancée sous Windows 2008 R2, La sécurité sous Windows 7, etc.)
    FaceBook Twitter LinkedIn

    vendredi 4 janvier 2013 08:27
  • Bonjour,

    Merci pour l'information,

    Le but de cette GPO c'est d'interdire l'ouverture de session Windows sur un domaine Active Directory depuis des machines intégrées au même domaine sauf pour l'admin du domaine et l'admine local, en spécifiant les paramètres ouverture de session locale ou interdire l'ouverture de session locale avec les bons groupes le résultat est négatif.

    Merci.

    vendredi 4 janvier 2013 08:52
  • Ce que je n'arrive pas bien à comprendre dans cette logique est le lien entre le fait de pouvoir ouvrir une session seulement si on est Administrateur local du poste; tu aurais dit l'inverse j'aurai compris mais là je ne vois pas.

    En tout cas, Si tu veux "nettoyer" ce groupe Utilisateurs local des postes, il faut passer par les groupes restreints comme indiqué plus haut, ou alors par stratégie de groupes de préférence (il y a une stratégie gérant les groupes locaux); ou bien encore via script.


    Freddy ELMALEH aka "bigstyle" - Consultant Freelance pour Active IT (Active IT)
    MVP Windows Server - Directory Services
    MCITP Enterprise Administrator (2008) - MCSE 2000/2003 Security - MCSA Messaging 2000/2003
    Bibliographie (Administration avancée sous Windows 2008 R2, La sécurité sous Windows 7, etc.)
    FaceBook Twitter LinkedIn

    vendredi 4 janvier 2013 08:59
  • Bonjour,

    En effet, Après plusieurs vérifications, j'ai trouvé un souci local au niveau des machines (modèle de sécurité appliqué) que j'ai réglé.

    Donc, plus besoin de supprimer le groupe utilisateurs local pour interdire l'ouverture de session domaine sur les machines,

    Actuellement, le Rsop indique que la GPO est bien appliquée, pas de message d'erreur,
    Cependant,le souci qui se pose maintenant : j'applique la GPO avec le paramètre: permettre l’ouverture d'une session locale-->admins domaine + admin local comme groupe et user-->le résultat: au niveau de la machine aucune session ne s'ouvre, y compris admins domaine et locale(msg : la stratégie locale ne vous permet pas d'ouvrir une session d'une manière interactive), PAR CONTRE, quand je me connecte en bureau distant: les sessions admins domaine et admin locale s'ouvrent correctement??

    Avez-vous svp une idée sur l'origine de cette anomalie?

    Merci.


    lundi 7 janvier 2013 20:59
  • Bonjour,

    Le message peut être affiché si la stratégie ''Refuser les ouvertures de sessions locales’’ est définie.

    Même si votre serveur ne se trouve pas dans la liste des produits auxquels les informations dans l’article suivant s’appliquent, merci de les consulter:

    Cordialement,

    Dan


    Dan BAJENARU, MSFT    Votez! Appel à la contribution
    Nous vous prions de considérer que dans le cadre de ce forum on n’offre pas de support technique et aucune garantie de la part de Microsoft ne peut être offerte.

    mercredi 9 janvier 2013 15:24
  • Bonjour,

    Ok, je vais vérifier,

    Merci pour votre aide.

    Cdt.

    mercredi 9 janvier 2013 20:41
  • Bonjour,

    Dans le but de renforcer la sécurité des serveurs, est-il envisageable (par stratégie) de supprimer les utilisateurs du domaine du groupe "Utilisateurs" local à chaque serveur ?

    Le but est de ne plus avoir à systématiquement modifier les ACL sur des répertoires où par défaut les utilisateurs locaux de la machine ont un droit de lecture.

    Merci par avance

    jeudi 23 novembre 2017 14:58