none
Problème d'authentification aléatoire avec POP sur Exchange 2013 RRS feed

  • Question

  • Bonjour,

     

    Nous avons un problème d’authentification avec POP vraiment bizarre. Honnêtement pour une fois je sens que je vais vous poser une colle.

     

    Tout d’abord voici notre environnement :

    • Exchange 2013 CU2 installé sur une VM Windows Server 2012 (sous HyperV 2012). Les rôles CAS et MBX sont sur le même serveur.
    • Une migration a été effectuée il y a 2 mois de Exchange 2007 à 2013. Les deux serveurs sont en cohabitation mais le 2007 est déconnecté du réseau afin de valider qu’il n’y ai pas de problèmes avant sa suppression de l’organisation.
    • AD/controleurs de domaine/ forêt : V 2008 R2

     

    Ensuite voilà le contexte :

    Pour des besoins spécifiques nous avons dû faire développer un logiciel personnalisé dont un processus va récupérer des mails via POP afin de les traiter 1 fois toutes les heures. Il y a environ une centaine de boites dont les mails vont ainsi être récupérés une fois toutes les heures.

    L’authentification basique est utilisée.

     

    Enfin notre problème :

    En général tout se passe bien lorsque le logiciel va se connecter en POP sur les différentes boites et récupérer les mails, mais environ une fois par jour, à un moment aléatoire, pour une seule boite (jamais la même), le logiciel ne peut pas se connecter.

    Afin de commencer le troubleshoot j’ai activé les logs POP.

    A chaque fois que notre logiciel ne peut se connecter je vois cette erreur dans les logs POP FrontEnd :

    2014-01-12T22:01:11.976Z,000000000000519C,2,192.168.X.X:110,192.168.X.X:52708,username,60099,10,56,pass,*****,"R=""-ERR Logon failure: unknown user name or bad password."";Msg=""User:username:2c3a21ff-c91d-4def-bc62-2571a7b73f7f:Mailbox Database 0147600599:servermail.domaine.fr;Proxy:servermail.domaine.fr:9955:SSL;ProxyTimeout"""

    Vous vous douterez que pour des raisons de confidentialité j’ai remplacé le nom d’utilisateur par username, le serveur de messagerie par servermail, le nom de domaine par domaine.fr et les adresses IP par 192.168.X.X.

     

    Dans les logs POP BackEnd on ne voit rien car, comme on vient de la voir ci-dessus, la connexion a été bloquée en amont par la partie Front End.

     

    Au moment où le log POP ci-dessus apparait, je constate l’erreur suivant dans l’observateur d’évènement partie Application du serveur Exchange 2013 :

     

    Journal : Application

    Source : MSExchangeFrontEndTransport

    Evenement : 1035

    Niveau : Avertissement

    Catégorie : SmtpReceive

    Échec de l'authentification entrante avec l'erreur LogonDenied pour le connecteur de réception RELAIS. Le mécanisme d'authentification est Ntlm. L'adresse IP source du client qui a tenté de s'authentifier à Microsoft Exchange est [192.168.X.X].

     

    Ensuite, systématiquement l’erreur nous parvient sur notre logiciel une heure après seulement « Erreur : Could not connect to the server » et une nouvelle alerte survient dans l’observateur d’évènement du serveur Exchange 2013 :

     

    Journal : Application

    Source : MSExchangeFrontEndTransport

    Evenement : 1020

    Niveau : Avertissement

    Catégorie : SmtpReceive

    Le compte « AUTORITE NT\ANONYMOUS LOGON » a fourni des informations d'identification valides, mais n'est pas autorisé à utiliser le serveur ; échec d'authentification.

     

     

    En voyant tout ça je suis stupéfait car déjà je vois la catégorie « SmtpReceive »…  Ca me trouble un peu qu’on me parle de SMTP alors que je me connecte juste en POP pour récupérer des mails. De plus notre logiciel utilise l’authentification basique et non NTLM… Enfin, la connexion à cette boite a marché toute la journée alors je ne vois pas pourquoi d’un coup cela aurai changé.

     

    Concernant le connecteur de réception RELAIS :

    • C’est un connecteur de réception frontend destiné à effectuer du relais SMTP depuis l’interne  pour des périphériques où il n’y a pas possibilité d’entrer un nom d’utilisateur tel que les imprimantes…
    • Il est configuré afin d’autoriser les utilisateurs anonyme. Pour info cette commande a été tapée : Get-ReceiveConnector “RELAIS” | Add-ADPermission -User “AUTORITE NT\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient.
    • L’adresse IP du serveur qui fait tourner notre logiciel fait partie de la plage autorisée à utiliser ce connecteur.
    • Sur ce connecteur niveau authentification tout est coché sauf « Sécurisé de l'extérieur (par exemple avec IPsec) »
    • Niveau groupe d’autorisation tout est coché sauf « Partenaires »

     

    Selon vous le problème pourrait-il venir du fait que la demande parvient à ce connecteur de réception relai au lieu du connecteur par défaut ? 

    J’avoue n’avoir aucune idée pour la résolution du problème et mes recherches sur le net ne m’ont pas permis d’y voir plus clair…

     

    Merci d’avance !

    mardi 14 janvier 2014 16:12

Réponses

  • Bonjour, shinobitom, cawaland,

    Le thread est-il toujours actuel?
    Je vous remercie par avance de votre retour.

    Cordialement,
    Téodora


    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mercredi 15 avril 2015 11:19

Toutes les réponses

  • Je pense que vous avez deux choses différentes :

    - le problème POP, il semble y avoir un timeout côté CAS dans l'interrogation de l'AD pour vérifier le compte. Le fait qu'il utilise MSExchangeFrontEndTransport pour valider le compte en NTLM auprès de l'AD ne me choque pas plus que cela.

    Vous pouvez voir si en manipulant les timeout liés à POP cela change le comportement : http://technet.microsoft.com/en-us/library/aa997604(v=exchg.150).aspx

    Ensuite vous pouvez vérifier si les DC utilisés par le CAS sont toujours joignables et fonctionnels (tous les GC du même site AD), et si il y a des événements sur ces DC. Vous pouvez avoir une liste des DC avec la cmdlet Get-DomainController


    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    • Marqué comme réponse Florin Ciuca lundi 20 janvier 2014 19:38
    • Non marqué comme réponse shinobitom jeudi 23 janvier 2014 17:08
    mercredi 15 janvier 2014 09:56
    Modérateur
  • La deuxième erreur semble lié à l'envoi de l'alerte depuis votre application (et pas a IMAP), je peux cependant le tromper.

    • L’adresse IP du serveur qui fait tourner notre logiciel fait partie de la plage autorisée à utiliser ce connecteur.

    Attention si vous utilisez des plages, Exchange utilisera le connecteur de réception avec la plage la plus restreinte correspondant à l'IP.

    Pour illustrer le propos : si vous avez un connecteur A avec la plage 10.0.0.0/24 et un connecteur B avec la plage 10.0.0.0-10.0.0.20, c'est le second connecteur qui sera utilisé si vous avez une IP dans cette plage.


    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    mercredi 15 janvier 2014 10:00
    Modérateur
  • Merci Bruce pour les réponses.

    Tout d'abord concernant les timeout POP, les valeurs par défaut n'ont pas été touchées :

    AuthenticatedConnectionTimeout    : 00:30:00
    PreAuthenticatedConnectionTimeout : 00:01:00 Pour ce dernier paramètre, d'après ce que j'ai pu comprendre il s'agit bien des connections non authentifiés d'après la doc Microsoft ?

    Alors oui effectivement cette erreur survient bien tout pile 1 minute après l'ouverture de la connexion donc ça correspond. En fait j'ai l'impression que comme le logiciel envoie toutes les demandes de connexions en même temps, il n'a pas le temps en une minute de traiter la requête de mot de passe et de finir l'authentification. Du coup la connexion n'étant toujours pas authentifié expire.

    Je pourrais augmenter le timeout mais bon je trouve ça moche. Si le nombre de boites augmente le logiciel va nous faire du deny de service ;) Je vais donc demander à l'éditeur de modifier le logiciel afin qu'il traite les boites les une après les autres et non toutes en même temps.

    Je vous tiens au courant rapidement si cela a résolu notre problème ou non afin de valider.

    La deuxième erreur étant, j'ai l'impression, unique à ce problème ci laissons tombé car elle disparaitra avec la résolution de la première erreur.

    Par contre, par rapport à ce relais, je n'ai pas bien compris dans le chapitre concernant le routage des mails, qu'est ce qui techniquement m'assurera que ce connecteur de réception pourra en cas de besoin transmettre les mails à des boites internes ? (je ne parle pas de faire un test et de voir si ça marche mais plutôt de paramétrage)

    Merci d'avance

    mercredi 15 janvier 2014 14:44
  • Par défaut, un connecteur de réception où vous avez autorisé l'utilisateur anonyme peut recevoir les emails à destination des domaines acceptés, par contre pour l'autoriser à envoyer vers d'autres domaines (en mode relai donc), il faut ajouter le droit tel que vous l'avez fait (pour rappel : http://technet.microsoft.com/fr-fr/library/jj673053(v=exchg.150).aspx & http://technet.microsoft.com/fr-fr/library/bb232021(v=exchg.141).aspx).

    Vous pouvez avoir plusieurs connecteurs liés au même port et même adresse (par exemple 10.0.0.1:25), le choix du connecteur utilisé se ferra par rapport aux IP autorisés indiqués sur le connecteur, en prenant le connecteur qui a la plage d'IP la plus proche de l'IP se connectant.

    . Cela veut aussi dire que vous ne pouvez pas mettre la même IP ou plage sur deux connecteurs liés à la même adresse et IP.


    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    • Marqué comme réponse Florin Ciuca lundi 20 janvier 2014 19:38
    • Non marqué comme réponse shinobitom jeudi 23 janvier 2014 17:04
    mercredi 15 janvier 2014 15:08
    Modérateur
  • Désolé du temps d'attente mais j'ai laissé le serveur tourner un moment après mes modifs afin de voir ci cela résolvait mon problème ou non.

    Et bien malheureusement non.

    J'ai augmenter le timeout à sa valeure maximale pour les connexions non-authentifiées (1h) et le problème est toujours présent.

    Donc en gros niveau logs POP je vois ceci :

    1. 8h00 : Opensession()
    2. 8h00 : User
    3. 9h00 : Pass avec l'erreur :

    R="-ERR Logon failure: unknown user name or bad password.";Msg="User:machin:e2b31429-cbda-4ea5-93a5-4c3839e827e6:Mailbox Database 0147600599:serveur.domaine.fr;Proxy:serveur.domaine.fr:9955:SSL;ProxyTimeout"

    Donc effectivement le fait d'avoir augmenté le timeout d'1 minutes à 1h fait que le serveur met 1h au lieue d'une minute à me rapporter l'erreur.

    Avez vous une autre idée ?

    Merci d'avance

    jeudi 23 janvier 2014 17:18
  •  Vous pouvez chercher dans le dossier Logging si il y a des logs concernant POP3. Normalement vous devriez en avoir dans ADDriver, mais je n'ai pas étudié leur contenu.

    Vous pouvez creuser du côté applicatif via un log réseau type wireshark ou network monitor, idéalement sans SSL/TLS pour ne pas compliquer les choses.

    Enfin mettre à jour vers CU3 puis SP1 à sa sortie.


    Bruce Jourdain de Coutance - Consultant MVP Exchange http://blog.brucejdc.fr

    vendredi 24 janvier 2014 08:57
    Modérateur
  • Bonjour,

    j'ai exactement le même problème, avez vous trouvez une résolution?

    merci

    mercredi 21 janvier 2015 16:10
  • Pour le problème d'authentification POP, utilisez plutôt côté client l'UPN (user@domaine.xx)
    jeudi 26 mars 2015 13:31
  • Bonjour, shinobitom, cawaland,

    Le thread est-il toujours actuel?
    Je vous remercie par avance de votre retour.

    Cordialement,
    Téodora


    Votez! Appel à la contribution TechNet Community Support. LE CONTENU EST FOURNI "TEL QUEL" SANS GARANTIE D'AUCUNE SORTE, EXPLICITE OU IMPLICITE. S'il vous plaît n'oubliez pas de "Marquer comme réponse" les réponses qui ont résolu votre problème. C'est une voie commune pour reconnaître ceux qui vous ont aidé, et rend plus facile pour les autres visiteurs de trouver plus tard la résolution.

    mercredi 15 avril 2015 11:19