Authentification du webmail à Nantes : ce qui bloque

Trois services distincts répondent au nom de « webmail Nantes » et ils n’utilisent pas la même authentification : la messagerie académique en @ac-nantes.fr, celle de Nantes Université, et la messagerie interne de l’ENT e-lyco. La plupart des refus de connexion se rangent dans trois cases : mauvais service, client de messagerie incapable de gérer le second facteur, ou filtrage réseau.

Sommaire

Trois services derrière la même recherche

« Webmail Nantes » ne désigne pas un service mais au moins trois, opérés par des organisations sans lien entre elles. Le rectorat de l’académie de Nantes gère la messagerie des personnels de l’éducation nationale, en @ac-nantes.fr, accessible par un webmail de la forme webmail.ac-nantes.fr ou via le portail Arena. Nantes Université gère la sienne pour ses étudiants et ses personnels, avec son propre serveur d’authentification centralisé. Les collèges et lycées publics des Pays de la Loire, eux, passent par l’ENT e-lyco, dont la messagerie interne n’est pas un webmail au sens classique : elle ne parle ni IMAP ni SMTP vers l’extérieur.

Se tromper de porte produit exactement le même écran qu’un mot de passe erroné.

Le premier réflexe utile n’est donc pas de retaper le mot de passe. C’est de regarder quel domaine figure après l’arobase dans l’adresse que vous essayez de relever, puis de repartir du portail officiel de l’organisme correspondant. Un signet posé il y a deux ans pointe souvent vers une ancienne interface qui refuse tout sans rien expliquer.

Contexte	Adresse type	Ce qui sert d’identifiant
Personnel de l’académie de Nantes	prenom.nom@ac-nantes.fr	Identifiant académique, mot de passe initial dérivé du NUMEN (13 caractères)
Étudiant de Nantes Université	prenom.nom@etu.univ-nantes.fr	Compte SSO de l’université, validé par un serveur CAS
Personnel de Nantes Université	prenom.nom@univ-nantes.fr	Même SSO, périmètre d’applications différent
Élève ou parent d’un établissement public	messagerie interne e-lyco	Compte ENT, souvent via EduConnect

Ce que fait vraiment la page de connexion

Sur les deux webmails institutionnels, le formulaire ne s’exécute pas sur le webmail.

Vous arrivez sur l’adresse du webmail, qui vous redirige aussitôt vers un serveur d’authentification centralisé (le protocole CAS, très répandu dans l’enseignement supérieur français). Vous saisissez vos identifiants sur ce serveur, et sur lui seul. En retour, il vous renvoie vers le webmail avec un paramètre du type ?ticket=ST-xxxxx dans l’URL. Ce jeton est à usage unique et sa durée de vie est très courte : dans la configuration par défaut d’Apereo CAS, un service ticket expire en une dizaine de secondes. Le webmail le présente au serveur CAS, obtient en réponse votre identité, puis ouvre sa propre session.

En parallèle, le serveur CAS dépose sur votre navigateur un cookie de session baptisé CASTGC. C’est lui qui vous évite de ressaisir votre mot de passe en passant du webmail à l’intranet.

Redirection vers le serveur d’authentification, avec l’URL du service en paramètre
Saisie des identifiants sur le domaine officiel du SSO, jamais ailleurs
Retour vers le webmail avec un ticket ST- à usage unique
Validation du ticket de serveur à serveur, puis ouverture de la session applicative

Le mot de passe passe sur le web mais pas dans Thunderbird

Cas classique : la connexion fonctionne dans le navigateur, et le même compte est rejeté en boucle dans un logiciel de messagerie. Rien d’anormal. Le webmail parle HTTPS et sait afficher un formulaire, une redirection, un second facteur. Le client parle IMAP et SMTP, deux protocoles qui n’ont aucun moyen d’afficher quoi que ce soit à l’utilisateur pendant l’authentification.

Quand un compte est protégé par un second facteur, le serveur refuse donc l’authentification simple par mot de passe et attend un mot de passe d’application, généré depuis l’interface web du compte. Les messages d’erreur à repérer sont normalisés : côté envoi, un « 535 5.7.8 Authentication credentials invalid » signale un rejet à l’étape d’authentification SMTP ; côté réception, une réponse « NO [AUTHENTICATIONFAILED] » désigne le même problème en IMAP (code défini par la RFC 5530). Un « 421 » ou une déconnexion brutale, en revanche, pointe vers une limite de connexions simultanées, pas vers vos identifiants.

Vérifiez aussi le nom d’utilisateur attendu, qui n’est pas toujours l’adresse complète.

Usage	Port	Chiffrement	Remarque
IMAP	993	TLS implicite	Réglage recommandé par la RFC 8314 (2018)
IMAP historique	143	STARTTLS	À réserver aux serveurs qui n’ouvrent pas le 993
Envoi (submission)	587	STARTTLS	RFC 6409, authentification obligatoire
Envoi TLS implicite	465	TLS implicite	Longtemps déconseillé, réhabilité par la RFC 8314
POP3	995	TLS implicite	Peut vider le serveur si l’option « laisser une copie » est décochée

Quand c’est le réseau, pas le mot de passe

Beaucoup d’établissements restreignent l’accès à certains services selon l’adresse IP source, ou bloquent des plages géographiques entières pour limiter les tentatives automatisées. Depuis l’étranger, ou derrière un VPN grand public dont la sortie est classée comme suspecte, la page de connexion peut répondre normalement puis refuser l’identifiant, ou renvoyer une erreur qui ne dit pas son nom. Un test simple lève le doute : la même saisie, au même moment, depuis le partage de connexion d’un téléphone en 4G.

Autre confusion fréquente sur les campus : le Wi-Fi eduroam et le webmail utilisent le même compte, mais pas la même forme d’identifiant. Eduroam s’appuie sur du 802.1X et un serveur RADIUS (ports 1812 pour l’authentification, 1813 pour la comptabilité), et le routage entre établissements se fait sur le realm, la partie après l’arobase. Il faut donc y saisir l’identité complète, du type nom@univ-nantes.fr, même si le webmail se contente du login court. Saisir le login court sur eduroam ne mène nulle part : la requête n’est jamais routée vers l’établissement.

Un portail captif d’hôtel ou de gare ajoute son propre étage de panne, puisqu’il intercepte les connexions avant l’authentification réelle et casse la validation du certificat. Si le navigateur signale un certificat invalide sur une adresse institutionnelle, ne cliquez pas sur « continuer ». Deux commandes suffisent à trancher entre un problème de résolution et un problème de certificat.

dig +short webmail.ac-nantes.fr pour vérifier que le nom résout bien, et vers quoi
openssl s_client -connect webmail.ac-nantes.fr:443 -servername webmail.ac-nantes.fr | openssl x509 -noout -dates pour lire les dates de validité du certificat
curl -I https://… pour lire le code HTTP renvoyé : un 401 est un refus d’authentification, un 403 un refus de droits sur un compte pourtant reconnu
Un test depuis un autre réseau, qui isole en une minute le filtrage par IP du problème de compte

Verrouiller le compte sans s’enfermer dehors

Les codes à six chiffres des applications d’authentification suivent la RFC 6238 : le code est calculé à partir d’un secret partagé et de l’heure, découpée en fenêtres de 30 secondes. Si l’horloge du téléphone dérive de plus d’une fenêtre ou deux par rapport au serveur, tous les codes sont refusés alors qu’ils s’affichent normalement. Le correctif tient en un réglage : réactiver la synchronisation automatique de l’heure sur le téléphone.

Notez les codes de secours ailleurs que dans la boîte mail qu’ils servent à récupérer.

Dernier point, plus discret, et qui compte si vous écrivez depuis chez vous : certaines plateformes de messagerie ajoutent au message envoyé un en-tête X-Originating-IP contenant l’adresse publique du poste utilisé. Le destinataire peut donc lire votre IP de connexion dans la source du message. Le comportement dépend de la solution déployée et de sa configuration, il n’est ni systématique ni documenté publiquement pour chaque établissement : le seul moyen de savoir est d’envoyer un message vers une adresse externe et d’en afficher la source complète.

Questions fréquentes

J’ai changé mon mot de passe sur le webmail et mon logiciel de messagerie ne se connecte plus

Le client conserve l’ancien mot de passe dans son trousseau et le rejoue jusqu’au blocage temporaire du compte. Supprimez l’entrée enregistrée avant de ressaisir, et vérifiez au passage les deux réglages : le serveur entrant en 993 et le serveur sortant en 587 ou 465. Si un second facteur est activé sur le compte, ce n’est pas le nouveau mot de passe qu’il faut saisir mais un mot de passe d’application généré depuis l’interface web.

Pourquoi mon code à six chiffres est-il refusé alors qu’il vient juste de s’afficher ?

Presque toujours à cause de l’horloge du téléphone. Le code dépend de l’heure découpée en tranches de 30 secondes, et les serveurs n’acceptent en général qu’une ou deux tranches d’écart. Activez la mise à l’heure automatique du réseau, le problème disparaît sans qu’il faille réenregistrer le compte.

Le webmail me déconnecte au bout de quelques minutes

Deux causes distinctes. Une durée de session courte côté serveur, sur laquelle vous ne pouvez rien, ou une session liée à l’adresse IP : passer du Wi-Fi à la 4G change l’IP source et invalide le cookie. Dans ce second cas, rester sur un seul réseau pendant la session règle le symptôme.

Puis-je consulter mon webmail depuis l’étranger ?

Cela dépend de la politique de filtrage de l’établissement, qui peut restreindre l’accès à certaines plages d’adresses. Quand l’accès direct est bloqué, la voie officielle est le VPN de l’établissement, qui vous fait ressortir avec une adresse interne. Un VPN commercial produit souvent l’effet inverse et déclenche un blocage supplémentaire.

Le mot de passe eduroam est-il le même que celui du webmail ?

Le mot de passe, oui, dans la plupart des établissements, puisque c’est le même compte. L’identifiant, non : eduroam a besoin de l’identité complète avec le domaine (nom@univ-nantes.fr) pour router la demande vers le bon établissement, là où le webmail accepte souvent le login court.

Testez vos connaissances

Quiz rapide Question 1 sur 3

Quel port correspond à IMAP avec chiffrement TLS implicite ?