locked
Filtrage de sécurité ne s'applique pas sur nos serveurs RRS feed

  • Question

  • Bonjour à tous,

    je me permet de revenir vers vous encore une fois sur un sujet qui concerne les GPO.

    On une OU qui contient tous nos serveurs de production sur laquelle  on a attaché pas mal de gpo sans problème ( pas de filtrage).

    On a besoin de créer une nouvelle GPO pour changer certain paramèter uniquement sur quelques serveur ce cette OU. Donc on a créé une nouvelle GPO et nouveau group active directory qui contient les comptes ordinateurs des serveurs en question. On a choisit d'attacher cette GPO à cette OU et ajouter un filtrage de sécurité pour l'appliquer uniquement sur les membres de ce groupe. Jusqu'à il me semble qu'on a rien oublié au niveau la config de la GPO. Malgré cela elle ne s'applique pas.

    On a créé la même chose dans notre environnement de teste et on a eu le même comprtement , sauf qu'après le redémarrage la GPO s'est appliquée. 

    Est ce que quelqu'un a rencontré ce comportement et comment vous avez pu le résoudre?  

    Merci d'avance pour vos aides.


    lundi 25 septembre 2017 16:52

Réponses

  • Bonjour,

    Ce comportement je l'ai eu si le serveur conserve en cache les anciens tickets kerberos lié au compte ordinateur de la machine en question qui incluent les SID des groupes aux quel le serveur appartient.
    Si ce ticket n'a pas été renouvelé après la modification de l'appartenance du groupe, elle ne sera pas prise en compte par le serveur. Dans ce cas il faut purger les tickets

    la commande klist purge permet de supprimer les ticket kerberos lié au compte utilisateur , mais pour votre cas vous avez besoin de supprimer les ticket lié au compte ordianteur vue que le groupe de filtrage contient des compte ordinateur des serveurs en question.

    Selon la description de votre cas ,je pense que vous avez le même comportement, pour avoir plus de détails je vous invite à consulter ce lien : L'appartenance à un groupe et les tickets Kerberos

    Essayer de lancer les commandes ci-dessous et vérifier si votre GPO s'applique sans redémarrage:

    #purger les tickets kerberos du compte ordianteur du serveur 
    
    klist -li 0x3e7 purge
    
    #Forcer l'application de la GPO
    
    gpupdate /force


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    • Proposé comme réponse Loïc Veirman mardi 26 septembre 2017 11:51
    • Marqué comme réponse S.FABOT mardi 26 septembre 2017 17:29
    lundi 25 septembre 2017 17:16
    Auteur de réponse
  • Bonjour Thameur BOURBITA

    Merci pour les commandes, je viens de les tester sur deux serveur et ça marche , une bonne nouvelle.

    Maintenant la question , est ce que je dois lancer les deux commandes sur tous les serveurs un par un? on a 100 machines.

    Bonjour,

    Vous ajouter une tâche planifié via GPP pour lancer la commande de suppression des ticket kerberos.

    Créer une nouvelle GPO sans aucun filtrage dessus et l'attacher à l'OU en question, c'est méthode la plus simple.


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    • Marqué comme réponse S.FABOT mardi 26 septembre 2017 17:29
    lundi 25 septembre 2017 17:47
    Auteur de réponse
    1. Vérifier que le serveur en question est bien membre du groupe.
    2. forcer la recréation du jeton kerberos (klist purge)
    3. rebooter le serveur

    Si cela ne s'applique toujours pas, faites un RSOP avec un compte disposant des privilèges admins sur le serveur.

    lundi 25 septembre 2017 17:07

Toutes les réponses

    1. Vérifier que le serveur en question est bien membre du groupe.
    2. forcer la recréation du jeton kerberos (klist purge)
    3. rebooter le serveur

    Si cela ne s'applique toujours pas, faites un RSOP avec un compte disposant des privilèges admins sur le serveur.

    lundi 25 septembre 2017 17:07
    1. Vérifier que le serveur en question est bien membre du groupe.
    2. forcer la recréation du jeton kerberos (klist purge)
    3. rebooter le serveur

    Si cela ne s'applique toujours pas, faites un RSOP avec un compte disposant des privilèges admins sur le serveur.

    Bonjour Loic,

    Merci pour votre retour.

    J'ai lancé la commande klist purge mais toujours le même souci.

    Selon le test que j'ai effectué dans mon environnement de test , le reboot permet de résoudre le problème, mais dans l'environnement de production je peut pas redémarrer tous les serveurs en même temps. Je cherche une solution sans aucune interruption de service si possible.

    Merci encore pour votre retour

    lundi 25 septembre 2017 17:13
  • Bonjour,

    Ce comportement je l'ai eu si le serveur conserve en cache les anciens tickets kerberos lié au compte ordinateur de la machine en question qui incluent les SID des groupes aux quel le serveur appartient.
    Si ce ticket n'a pas été renouvelé après la modification de l'appartenance du groupe, elle ne sera pas prise en compte par le serveur. Dans ce cas il faut purger les tickets

    la commande klist purge permet de supprimer les ticket kerberos lié au compte utilisateur , mais pour votre cas vous avez besoin de supprimer les ticket lié au compte ordianteur vue que le groupe de filtrage contient des compte ordinateur des serveurs en question.

    Selon la description de votre cas ,je pense que vous avez le même comportement, pour avoir plus de détails je vous invite à consulter ce lien : L'appartenance à un groupe et les tickets Kerberos

    Essayer de lancer les commandes ci-dessous et vérifier si votre GPO s'applique sans redémarrage:

    #purger les tickets kerberos du compte ordianteur du serveur 
    
    klist -li 0x3e7 purge
    
    #Forcer l'application de la GPO
    
    gpupdate /force


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    • Proposé comme réponse Loïc Veirman mardi 26 septembre 2017 11:51
    • Marqué comme réponse S.FABOT mardi 26 septembre 2017 17:29
    lundi 25 septembre 2017 17:16
    Auteur de réponse
  • Bonjour Thameur BOURBITA

    Merci pour les commandes, je viens de les tester sur deux serveur et ça marche , une bonne nouvelle.

    Maintenant la question , est ce que je dois lancer les deux commandes sur tous les serveurs un par un? on a 100 machines.

    lundi 25 septembre 2017 17:35
  • Bonjour Thameur BOURBITA

    Merci pour les commandes, je viens de les tester sur deux serveur et ça marche , une bonne nouvelle.

    Maintenant la question , est ce que je dois lancer les deux commandes sur tous les serveurs un par un? on a 100 machines.

    Bonjour,

    Vous ajouter une tâche planifié via GPP pour lancer la commande de suppression des ticket kerberos.

    Créer une nouvelle GPO sans aucun filtrage dessus et l'attacher à l'OU en question, c'est méthode la plus simple.


    Please don't forget to mark the correct answer, to help others who have the same issue. Thameur BOURBITA MCSE | MCSA My Blog : http://bourbitathameur.blogspot.fr/

    • Marqué comme réponse S.FABOT mardi 26 septembre 2017 17:29
    lundi 25 septembre 2017 17:47
    Auteur de réponse
  • d'accord merci.

    je teste cela demain et je vous tiendrai au courant.

    Encore une fois merci pour vos aides.

    lundi 25 septembre 2017 18:03
  • Ou en remote-powershell, ca évitera une GPP :)

    mardi 26 septembre 2017 11:52
  • Bonjour à tous,

    Problème résolu, une partie de nos serveurs ont appliqué le settings de la GPO après un redémarrage forcé après l'installation des mises à jour, et pour le reste on a créé une tâche planifié à travers une GPO après avoir testé dans notre environnement de test.

    je vous remercie encore une fois pour vos aides.

    Je ferme ce post .

    mardi 26 septembre 2017 17:29