Un refus d’authentification sur SOGo ne signale pas toujours un mot de passe erroné. Depuis l’intégration du second facteur TOTP dans SOGo, le diagnostic d’une connexion webmail impossible a changé : le blocage peut venir d’un code temporaire non configuré, d’un cache navigateur corrompu ou d’une confusion entre identifiants de portail et identifiants de boîte mail. Nous détaillons ici les causes réelles, classées par couche technique, et les correctifs adaptés.
Authentification TOTP et blocage SOGo webmail : le facteur ignoré
SOGo propose dans ses préférences une authentification à double facteur basée sur un code temporaire TOTP. Lorsque cette option est activée, la mire de connexion affiche un champ supplémentaire après la saisie du mot de passe. Si l’application TOTP (FreeOTP, Google Authenticator, Aegis) n’est plus synchronisée ou a été réinstallée sans export du secret, le code est systématiquement rejeté.
Le piège le plus fréquent : un administrateur active le TOTP côté serveur sans que l’utilisateur ait configuré son application. La connexion échoue alors avec un message générique de type « identifiants incorrects », sans mention du second facteur. Nous recommandons de vérifier dans les préférences du compte (onglet Sécurité) si la double authentification est active avant toute autre action.
Si le TOTP a été désactivé par l’administrateur pour débloquer un compte, SOGo affiche à la reconnexion un avertissement explicite invitant à reconfigurer l’application. Ne pas ignorer cet écran : sans reconfiguration, le prochain verrouillage de session réactivera le blocage.
Réinitialiser le TOTP sans accès au compte
L’utilisateur final ne peut pas désactiver seul le TOTP depuis la mire de connexion. L’intervention passe par l’administrateur du serveur SOGo, qui supprime le secret TOTP stocké dans la base utilisateur. Sur les instances académiques, cette opération relève du support de la DSI, pas du helpdesk de premier niveau.
Cache navigateur et session expirée : diagnostic précis d’un problème de connexion SOGo
Un cache saturé ne provoque pas un simple ralentissement. Sur la mire d’authentification SOGo, il peut afficher une version périmée de la page de connexion, avec des ressources JavaScript obsolètes qui empêchent la soumission du formulaire. Le symptôme typique : le bouton de connexion ne réagit pas, ou la page recharge sans message d’erreur.
Le réflexe « essayez un autre navigateur » est insuffisant s’il ne s’accompagne pas d’un vidage complet du cache sur le navigateur principal. Voici la procédure de diagnostic que nous appliquons :
- Ouvrir une fenêtre de navigation privée (pas un simple nouvel onglet) et tenter la connexion. Si elle aboutit, le problème est confirmé côté cache ou cookies de session.
- Vider le cache et les cookies spécifiques au domaine du webmail (pas la totalité du navigateur). Sur Firefox : Paramètres > Vie privée > Cookies et données > Gérer les données > rechercher le domaine.
- Vérifier que le navigateur accepte les cookies tiers si le webmail passe par un portail SSO intermédiaire. Un blocage strict des cookies tiers coupe la transmission du jeton de session entre le portail et SOGo.
Sur les postes partagés en établissement, les stratégies de groupe (GPO) peuvent forcer la suppression des cookies à la fermeture du navigateur. La session SOGo, basée sur un cookie de session, ne survit alors pas à une fermeture de fenêtre.
Confusion entre identifiants de portail et identifiants IMAP dans SOGo
Sur les déploiements académiques ou professionnels, l’identifiant du portail SSO diffère souvent de l’adresse mail. L’utilisateur tente de se connecter avec son adresse complète ([email protected]) alors que le champ attend un identifiant court (pnom). L’inverse est tout aussi fréquent sur les instances hébergées type Gandi, où l’identifiant est l’adresse mail complète et non un login court.
SOGo lui-même ne gère pas l’authentification dans la majorité des déploiements : il délègue à un backend LDAP ou à un serveur IMAP. Le message d’erreur renvoyé est donc celui du backend, rarement explicite. Un « Authentication failed » peut signifier un mauvais format d’identifiant autant qu’un mauvais mot de passe.
Accès direct versus portail : contourner une panne de SSO
Lorsque le portail (Eduline, ENT ou autre) est en panne, l’URL directe du webmail SOGo reste parfois accessible. L’accès direct permet de distinguer un problème de portail d’un vrai blocage de compte. Si la connexion fonctionne via l’URL directe du SOGo mais échoue via le portail, le problème se situe sur la couche SSO, pas sur la messagerie.
Attention : sur certaines configurations, l’accès direct est désactivé par l’administrateur pour forcer le passage par le SSO. Dans ce cas, la tentative d’accès direct renvoie une erreur 403 ou une redirection en boucle.
Problèmes de données et dossiers IMAP après connexion SOGo
Une connexion réussie ne garantit pas un fonctionnement normal. Plusieurs dysfonctionnements post-authentification sont directement liés à la couche IMAP sous-jacente :
- Dossiers IMAP non souscrits : SOGo n’affiche que les dossiers auxquels le client est abonné. Un dossier créé depuis un autre client mail (Thunderbird, Outlook) peut ne pas apparaître tant que la souscription n’est pas activée dans SOGo via clic droit > S’abonner.
- Quota IMAP atteint : lorsque la boîte dépasse le quota, l’envoi de messages échoue silencieusement. SOGo n’affiche pas toujours un message d’erreur explicite, le brouillon reste bloqué sans explication visible.
- Identités multiples mal configurées : SOGo permet de créer plusieurs identités d’expédition pour les boîtes partagées. Si l’identité par défaut pointe vers une adresse dont le serveur SMTP refuse le relai, tous les envois échouent même si la réception fonctionne.
Vérifier la configuration des identités dans les préférences
Dans Préférences > Mail > Comptes IMAP, chaque identité associe une adresse d’expédition à un serveur SMTP. Nous observons régulièrement des identités orphelines après un changement de nom de domaine ou une migration de serveur. Supprimer les identités obsolètes et ne conserver que celles dont le serveur SMTP est actif résout la majorité des échecs d’envoi.
Le diagnostic d’une connexion SOGo webmail impossible se résume rarement à un simple oubli de mot de passe. La superposition du TOTP, du SSO, du cache navigateur et de la couche IMAP crée des combinaisons de blocages que seul un examen méthodique, couche par couche, permet de résoudre. Quand le message d’erreur est générique, tester l’accès direct au webmail en navigation privée reste le premier geste utile avant toute demande au support.
