none
Problème d'authentification Kerberos Outlook2003 SP3 / Exchange 2007 RRS feed

 > 

  • Discussion générale

  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    Je rencontre depuis peu un problème avec Outlook 2003. Je suis dans un environnement multiforêt(2) multidomaine(3).

    Si des utilisateurs loggé disons sur le domaine A mais depuis un site B lorsqu'ils tentent d'ouvrir outlook ils ont le message suivant :

    "Impossible d'ouvrir vos dossiers de messagerie par défaut. L'ordinateur Microsoft Exchange n'est pas disponible. Soit des problèmes réseaux sont apparus. Soit l'ordinateur est arrêté pour maintenance."

    celà fonctionnait très bien jusqu'a il y'a un mois environ.

    la seule solution que j'ai trouvé pour que celà fonctionne est de modififer le mode d'authentification et le passer sur authentification NTLM en cryptant les données entre outlook et exchange (dans les paramètres avancés du compte de messagerie déclaré dans Outlook)

    Quelqu'un a-t-il une idée concernant ce problème de refus d'authentification Kerberos ?

    Merci de votre aide


    • Modifié Jonathan Foot vendredi 28 octobre 2011 09:49
    • Type modifié Florin Ciuca vendredi 4 novembre 2011 09:02 attente de feedback
    vendredi 28 octobre 2011 09:49
    |

Toutes les réponses

  • Discussion
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonjour Jonathan,

    Vous avez lu: http://social.technet.microsoft.com/Forums/en/exchange2010/thread/9806ce65-47c5-423e-92f1-74520e909779

    http://blogs.msexchange.org/walther/2009/08/30/exchange-2010-and-outlook-2003-clients-connection-issues/

    Ce problème est expliqué aussi dans l’article KB: Problèmes de connexion d’ Outlook avec des boîtes aux lettres Exchange 2010 en raison de l'exigence de chiffrement RPC

    Cordialement,

    Roxana

    Roxana PANAIT, MSFT       Join TechNetFr on Viadeo   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.

    mardi 1 novembre 2011 16:17
    |
  • Discussion
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonsoir,

    j'ai rencontré récemment des problèmes d'authentification liés à Kerberos. Là aussi, cela fonctionnait en passant en mode NTLM.

    Mais le problème n'était lié qu'à certains utilisateurs précis, quel que soit l'ordinateur utilisé.

    Après une analyse réseau (NetMon sur le poste client), il s'avère que le ticket Kerberos dépassait les 12K de taille maximale prévue par défaut dans la stratégie. Les utilisateurs qui posaient problèmes faisaient partie de beaucoup TROP de groupes...(+ de 500). Après un nettoyage des nombreux groupes inutiles/redondants, le problème a été résolu pour ces utilisateurs.

    L'autre solution aurait été d'augmenter la taille maximale du ticket Kerberos à 64K, mais il n'était pas sur que cela suffise...

    A bientôt,

     

    Thierry DEMAN. Exchange MVP. https://www.mcpvirtualbusinesscard.com/VBCServer/MVPtdeman/profile (68 MCPs) http://base.faqexchange.info
    mardi 1 novembre 2011 18:34
    |
    Modérateur
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    bonjour,

    Roxana, j'ai effectivement lu ces articles, mais je ne pensaient pas que celà s'appliquerait comme je suis sur Exchange 2007.

    j'ai tout de même essayé le Get-RpcClientAccess | fl dans le shell d'exchange 2007 mais ça ne passe pas

    J'ai un retour comme quoi cette commande n'est pas reconnue.

     

    Thierry,

    j'avais déja vu quelque chose passé à ce sujet, mais je pensais qu'il s'agissait d'un nombre global de groupe, pas d'une affectation en particulier.

    Le fait est que mes boite aux lettres exchange sont de type liées. Je ne sais pas si ça peut avoir un rapport. (j'ai 864 groupes sur le domaine A et 295 sur mon domaine B)

    Merci

     

    Jonathan

    jeudi 3 novembre 2011 08:46
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    bonjour,

    que s'est t-il passé il y a un mois avant que cela ne marche plus ? déploiement de correctif sur les postes ? modification de la topologie AD/Exchange ?

    Quel est le type de relation d'approbation entre les forets (forest trust, external ?). Le SID Filtering est -il activé ? la relation fonctionne t-elle ?

    Lancer une trace réseau et reproduire le problème puis filtrer la trace sur le protocol Kerberos et voir quels sont les réponses et erreurs retournées lors de l'authentification du client.

    yohan

    jeudi 3 novembre 2011 09:52
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    concernant ce qui s'est passé il y'a un mois je n'ai aucune informations, puisque le principal instigateur est parti...
    La relation d'approbation existante est de type Forêt transitive et est fonctionnelle.

    J'ai fait tourné un wireshark sur 2 machines rencontrant le problème et j'obtiens en final une réponse de ce genre :

    10.1.20.12(DC) 172.20.14.49(Machine Cliente) KRB5 171 KRB Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN


    J'ai également remarqué que l'option "l'autre domaine prend en charge le chiffrement AES via kerberos" n'était pas cochée dans les propriétés des domaines et approbations, mais je ne sais pas quelle est son utilité.

    Merci

    Jonathan

    jeudi 3 novembre 2011 12:23
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

     

    avez vous introduit récemment un contrôleur de domaine Windows 2008 ?

    J'avais eu des pb d'authentification Kerberos avec une erreur similaire, peut etre que c'est similaire dans ton cas ?

    http://exchangets.fr/spip.php?article69

    Yohan

    jeudi 3 novembre 2011 12:58
    |
  • Discussion
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir,

    après vérifications, il n'ya pas eu d'ajout de DC supplémentaire depuis la mise en place de la relation d 'approbation interforêt il y'a 1 an et demi environ.

    les quelques serveurs qui ont été rajoutés depuis l'ont tous été en tant que serveur membre, il s'agissait de serveur d'application ou autres.

    jeudi 3 novembre 2011 15:57
    |
  • Discussion
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonsoir,

    Avez-vous vérifier la présence des SPN et surtout la bonne résolution des SPN depuis un autre domaine/site ?

    http://technet.microsoft.com/fr-fr/library/aa996905(EXCHG.80).aspx

    Vérifier aussi qu'il n'y a pas eu ajout de firewall entre les forets, notamment entre les DC root de chaque forêt.

     

    http://laubel.wordpress.com/
    jeudi 3 novembre 2011 20:07
    |
  • Discussion
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    Bonsoir,

    la vérification des SPNs est effectivement une bonne idée.

    A ce sujet voici un article qui explique comment résoudre ce genre d'erreur:

    Troubleshooting Kerberos Authentication problems – Name resolution issues

    Dans les grandes lignes voici ce que fait l'auteur appliqué à notre probleme Exchange:

    -Purger les caches DNS/WINS et les tickets kerberos (KList purge) du client (vérifier aussi le fichier HOST)
    -Lancer une trace réseau avec le filtre "dns || Kerberos || ip.addr==<IP serveur Exchange>"
    -Ping du FQDN du serveur Exchange (avec le FQDN utilisé dans le profile Outlook)
    -Lancement d'Outlook (configuré en negotiate) afin de reproduire le probleme puis arréter la trace
    -Analyser la trace réseau

    Ensuite vient l'analyse de la trace:

    -Résolution du nom du serveur Exchange
       o la requete DNS contient le FQDN du serveur Exchange spécifié
       o le serveur DNS retourne la bonne IP

    - Négociation de l'authentification
       o au niveau de la trame SMB Negotiate Protocol Response, vérifier le "Principal Name" annoncé par le serveur

    - Obtention du ticket Service Ticket Kerberos
       o Repérer la trame qui correspond  KRB5 TGS-REQ
       o Déplier la trame afin de vérifier le SPN demandé par le client dans la section KDC_REQ_BODY du paquet Kerberos

    A partir de la:

    Comparer le "Principal Name" annoncé par le serveur Exchange et celui présent dans la demande de ticket du client, ca correspond ?
    Le Service Principal Name demandé par le client existe t-il au niveau du serveur Exchange ? Dans le cas contraire le rajouter avec SETSPN.exe


    L'ideal c'est de prendre le temps de lire l'article

    Yohan

    jeudi 3 novembre 2011 22:21
    |