none
Problème de pivilèges lors de la création d'un cluster de basculement

    Question

  • Bonjour,

    j'ai une soucis "simple", lorsque j'essaye de créer un cluster de basculement, il vérifie les deux serveur (dont lui même) et bloque sur le deuxieme pendant 2 minutes (en marquant l'opération prend plus de temps que prévu) avant de me sortir que je n'ai pas les "Vous n'avez pas de privilèges d'administration sur le serveur XXXXXXX".

    Sauf que les deux serveurs sont sur le même domaines, dans le même UO et sur le même réseau, et je me suis connecté sur les deux avec le compte administrateur de l'entreprise et du domaine... D'ailleurs j'ai déjà fait cette manip dans les mêmes conditions il me semble et ça ne m'a jamais posé problème...

    J'ai essayé de rajouter sur les administrateurs locaux le compte admin du domaine sans succès...

    Redémarrage des deux serveurs : idem

    Les serveurs se ping bien

    Merci pour votre aide !

    MLA

    lundi 12 février 2018 15:34

Réponses

  • Bon, après quelque recherches sur les erreurs, j'ai réfléchis.

    Pendant mes test précédents j'avais déjà utilisé les mêmes noms de serveurs. Du coup il doit subsister quelque chose quelque part sur l'AD mais je ne sais pas où.

    J'ai changé les noms des deux serveurs et le problème a disparut.

    Si vous avez une idée d'où se trouve cet enregistrement "résiduel" je suis preneur !

    Merci

    mardi 13 février 2018 08:57

Toutes les réponses

  • Bonjour,

    Avez vous des messages d'erreur dans le journal d'événement?


    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/

    lundi 12 février 2018 16:07
    Modérateur
  • Bonjour,

    alors j'avais déjà regardé mais surement mal car en regardant de nouveau après un essai j'ai effectivement deux erreurs :

    1- Le client Kerberos a reçu une erreur KRB_AP_ERR_MODIFIED du serveur SERVEUR$. Le nom cible utilisé était RPCSS/ServeurXXX.domaine.local. Cela indique que le serveur cible n’a pas réussi à déchiffrer le ticket fourni par le client. Cela risque de se produire lorsque le nom principal du serveur (SPN) cible est inscrit sur un compte différent de celui utilisé par le service cible. Assurez-vous que le SPN cible est inscrit uniquement sur le compte utilisé par le serveur. Cette erreur peut aussi se produire si le mot de passe du compte de service cible diffère de ce qui est configuré sur le centre de distribution de clés Kerberos pour ce service cible. Assurez-vous que le service sur le serveur et le centre de distribution de clés Kerberos sont tous deux configurés pour utiliser le même mot de passe. Si le nom de serveur n’est pas complet, et que le domaine cible (domaine.local) diffère du domaine client (domaine.local), vérifiez s’il existe des comptes de serveur de même nom dans ces deux domaines, ou utilisez le nom complet pour identifier le serveur.

    2- DCOM n’a pas pu communiquer avec l’ordinateur SERVEUR à l’aide des protocoles configurés ; demande du PID      ba4 (C:\Windows\system32\mmc.exe).

    mardi 13 février 2018 08:56
  • Bon, après quelque recherches sur les erreurs, j'ai réfléchis.

    Pendant mes test précédents j'avais déjà utilisé les mêmes noms de serveurs. Du coup il doit subsister quelque chose quelque part sur l'AD mais je ne sais pas où.

    J'ai changé les noms des deux serveurs et le problème a disparut.

    Si vous avez une idée d'où se trouve cet enregistrement "résiduel" je suis preneur !

    Merci

    mardi 13 février 2018 08:57