locked
[AD 2003] Impossible de faire fonctionner une délégation de contrôle RRS feed

  • Question

  • Bonjour,

    Cela  fait plusieurs mois  que  je  tente  de faire fonctionner  une  délégation de contrôle sur une OU  de notre AD sans y arriver.

    J'avais déjà soumis le problème sur ce forum il y 2 mois mais les pistes qui m'ont été soumises je les ai exploré sans succès.

    Voici le contexte.

    AD 2003 forêt mono domaine avec forêt et domaine en mode natif Windows Server 2003 avec Exchange 2007, Lync server 2010
    Tous les DC sont en SP2.
    A l'origine c'est un domaine NT4 créé il y a 14 ans et  qui a subi des mises à niveau successives en AD 2000 puis 2003.

    J'ai créé une nouvelle OU directement sous la racine avec des nouveaux comptes créés exclusivement à cet effet mais le  problème persiste.

    J'ai monté un autre AD pour être sûr que c'était pas moi qui ne savait pas faire la délégation mais ça fonctionne parfaitement sur un AD neuf.

    Pouvez vous m'aider svp?


    DJ


    DJ

    jeudi 13 septembre 2012 11:29

Réponses

  • Bonsoir,

    ce n'est pas du tout lié à SYSVOL qui ne contient que les stratégies.

    Les droits et délégations sont intégrés à la base d'annuaire (NTDS). On peut retrouver et vérifier les délégations sous forme de droits en utilisant l'onglet sécurité.

    A part vérifier que les réplications de la base d'annuaire sont correctes entre les contrôleurs de domaine avec la commande REPADMIN et les options /replsummary puis /showrepl, je ne pense pas que les autres commandes t'aideront beaucoup.

    Il doit manquer un droit sur l'objet ou le type d'objet que l'on souhaite modifier.

    Si ce n'est pas encore fait, je te conseille de modifier le fichier DSSEC.DAT (http://support.microsoft.com/kb/296490).

    Vérifie aussi et compare les droits avec la maquette, il doit y avoir une différence... peut être sur un droit hérité de la racine.

    Attention aussi au fait que les utilisateurs qui ont des délégations, n'ont PAS le droit de modifier les comptes font ou ont fait partie d'un groupe d'administration!!! Ces comptes ont la case "héritage des droits" décochées et le champ ADMIN égal = 1.

    A bientôt,


    Thierry DEMAN. Exchange MVP. https://mvp.support.microsoft.com/profile=CE2B565B-B13D-4C24-B04D-F0D5766D14A1 http://www.faqexchange.info

    samedi 15 septembre 2012 22:25

Toutes les réponses

  • Bonjour,

    la délégation c'est vague!

    Quel droit  souhaitez vous donner? qu'est ce qui marche? Qu'est ce qui ne fonctionne pas?

    Quel outil donnez-vous aux utilisateurs qui ont des délégations?

    Habituellement, je passe par l'assistant pour donner des délégations. Ensuite, il faut parfois ajouter "manuellement" quelques droits supplémentaires sur l'OU pour que cela se passe au mieux.

    Ensuite, l'utilisateur qui a une délégation, doit avoir l'outil d'administration installé sur son ordinateur, ou bien accès à un serveur sur lequel il faudra lui donner les droits d'ouvrir une session.

    A bientôt,


    Thierry DEMAN. Exchange MVP. https://mvp.support.microsoft.com/profile=CE2B565B-B13D-4C24-B04D-F0D5766D14A1 http://www.faqexchange.info

    vendredi 14 septembre 2012 12:06
  • Bonjour,

    Je t'invite à regarder cette vidéo explique comment et quand on utilise le délégation de contrôle :Delegation of Control 


    Best regards Bourbita Thameur Microsoft Certified Technology Specialist: Windows Server 2008 R2,Server Virtualizaton

    vendredi 14 septembre 2012 12:22
  • Bonjour Thierry

    Ce qui ne fonctionne pas c'est  modification des attributs (upn,tel,company,st etc...) et la réinistialisation comptes se trouvant dans les sous OU de l'OU sur laquelle j'ai fait la délégation.

    La méthode utilisé pour faire la délégation c'est l'assistant délégation en faisant un clic droit sur l'OU concerné, plus exactement je fais point par point comme dans la vidéo qu'indique Thameur Bourbita dans sa réponse ci dessous.

    Aucune erreur n'apparait durant la création de la délégation et rien ne semble indiquer que ça ne fonctionne pas.

    Les utilisateurs bénéficiaires de la délégation possèdent tous un poste Windows XP SP3 membre du domaine avec l'adminpack.msi installé dessus.

    J'ai tenté de faire la même manipulation en  créant un nouvelle OU directement à la racine du  domaine ( comme celle sur laquelle je veux le faire) mais le même problème se produit.

    Je soupçonne une corruption des ACL sur le  SYSVOL mais je ne sais pas comment vérifier.

    Est-ce qu'un DCDIAG et un NETDIAG pourrait vous être utile et si oui faut il le faire sur un DC qui possède un rôle FSMO particulier?

    Je précise que la même manipulation exécutée sur un AD de test, fonctionne parfaitement.

    Merci de votre aide


    DJ




    • Modifié G-Orwell vendredi 14 septembre 2012 12:58
    vendredi 14 septembre 2012 12:52
  • Bonjour Thameur,

    Merci pour la vidéo  c'est  exactement la même méthode que j'applique, hélas sans succès.

    Merci de votre aide


    DJ

    vendredi 14 septembre 2012 12:53
  • Bonsoir,

    ce n'est pas du tout lié à SYSVOL qui ne contient que les stratégies.

    Les droits et délégations sont intégrés à la base d'annuaire (NTDS). On peut retrouver et vérifier les délégations sous forme de droits en utilisant l'onglet sécurité.

    A part vérifier que les réplications de la base d'annuaire sont correctes entre les contrôleurs de domaine avec la commande REPADMIN et les options /replsummary puis /showrepl, je ne pense pas que les autres commandes t'aideront beaucoup.

    Il doit manquer un droit sur l'objet ou le type d'objet que l'on souhaite modifier.

    Si ce n'est pas encore fait, je te conseille de modifier le fichier DSSEC.DAT (http://support.microsoft.com/kb/296490).

    Vérifie aussi et compare les droits avec la maquette, il doit y avoir une différence... peut être sur un droit hérité de la racine.

    Attention aussi au fait que les utilisateurs qui ont des délégations, n'ont PAS le droit de modifier les comptes font ou ont fait partie d'un groupe d'administration!!! Ces comptes ont la case "héritage des droits" décochées et le champ ADMIN égal = 1.

    A bientôt,


    Thierry DEMAN. Exchange MVP. https://mvp.support.microsoft.com/profile=CE2B565B-B13D-4C24-B04D-F0D5766D14A1 http://www.faqexchange.info

    samedi 15 septembre 2012 22:25
  • Bonjour Thierry,

    Je vais tester les réplications avec repadmin.

    Concernant ta dernière remarque j'avais regardé à l'époque de ma première question à ce sujet les comptes utilisateurs à modifier et ils avaient effectivement l'attribut AdmiCount = 1 (Si c'est de cet attribut que tu parles) , je les avais alors tous réinitialisé à non défini.
    Par contre en ce qui concerne "l'héritage des droits" je ne vois pas où  se trouve cette propriété sur un compte utilisateur dans la console DSA?
    Ca pourrait être la clé du problème...

    Merci pour ton aide.


    DJ


    • Modifié G-Orwell dimanche 16 septembre 2012 00:56
    dimanche 16 septembre 2012 00:54
  • Bonjour,

    Mon problème n'est toujours pas résolu, et je constate des comportements étonnants que je n'explique pas.

    En effet voici ce que j'observe.

    Dans une OU que j'avais créé directement à la racine du domaine afin de faire des tests en dehors des OU de prods, j'ai créé 4 comptes utilisateurs + un groupe global de sécurité dans lequel j'ai mis un des 4 comptes.

    A l'aide de l'assistant délégation j'ai créé une délégation pour ce groupe sur les comptes utilisateurs de cette OU et la délégation ne fonctionne que pour un seul des comptes administrés.

    Autrement dit je ne peux modifier qu'un seul des 3 autres comptes de cette OU et rien d'autre.

    Par ailleurs j'ignore si c'est normal mais dans la default domain policy sous "Ordinateur>paramètres Windows>paramètre de sécurité>attribution des droits utilisateurs>"  il y a un paramètre qui s’appelle "Permettre à l’ordinateur et aux comptes d’utilisateurs d’être approuvés pour la délégation" et celui ci  n'est pas défini.

    Merci de votre retour si vous avez une idée. 


    DJ

    jeudi 4 octobre 2012 16:17
  • Bonsoir,

    sur les 3 autres comptes de cette OU, sont-ils membres d'un groupe d'administration quelconque?  ont-ils été créés ou simplement déplacés depuis une autre OU?

    A suivre...


    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

    samedi 6 octobre 2012 20:17
  • Bonsoir Thierry,

    Les 3 autres comptes ont été créé ( et non copiés ou déplacés) uniquement dans le but de diagnostiquer mon problème.

    Ils ne sont membres que de "utilisateurs du domaine" et n'ont jamais été membres d'aucun groupe d'administration.

    Pour chacun de ces trois comptes lorsque j"édite leurs propriétés avec ADSIedit, j'ai l'attribut AdminCount=<non défini>.

    Quant aux ACL sur l'OU de prod où j'avais constaté le problème initialement, je ne pourrais pas dire si elles sont correctes il y 'en a tellement en raison de nombreux produits MS et tiers qui sont venu les modifier (Lync,Forfront,Symantec,Exchange etc).

    Par contre à l'époque où j'ai constaté le problème pour la première fois, tous les comptes avaient au moins une fois été membres indirects du groupe "administrateurs de l'entreprise", et certains l'étaient encore.

    J'avais d'ailleurs repositionné l'attribut AdminCount à non défini pour tous les comptes qui ne devaient pas être admin.

    Dans  le  cadre d'un déploiement massif, un de mes collègues avait créé un groupe global de sécurité dans lequel il avait placé tous les comptes des utilisateurs concernés par le déploiement.

    Il avait ensuite imbriqué ce groupe dans un autre qui lui même était membre de "administrateurs de l'entreprise", octroyant de fait les pleins pouvoirs à la moitié des utilisateurs du parc.

    Et d'après ce qu'il m'a dit il faisait comme ça à chaque projet de déploiement ...

    Voilà pour la petite histoire.


    DJ



    • Modifié G-Orwell samedi 6 octobre 2012 20:49
    samedi 6 octobre 2012 20:42