Firefox 160 : vérifier les blocages de connexion NTLM/Kerberos sur l’intranet

Mis à jour le 13 novembre 2026. Firefox se fige plusieurs secondes lors de la connexion à un site interne ? Mozilla annonce dans Firefox 160.0, publié le 10 novembre, une correction concernant les intranets utilisant NTLM ou Kerberos/Negotiate. Ce guide aide les utilisateurs et les équipes informatiques à cerner le parcours de connexion puis à vérifier une mise à jour autorisée. Il ne promet ni de résoudre tous les échecs ni de réparer le serveur. Il repose sur la documentation du fournisseur ; nous n’avons pas reproduit le défaut. [1]

Portée de la correction

Le symptôme documenté est un gel de plusieurs secondes pendant l’authentification, pas toute erreur de mot de passe ou d’autorisation. NTLM et Kerberos sont distincts ; Negotiate peut intervenir dans le choix. Un délai sur un service externe ne prouve pas la même cause. Firefox Release, Enterprise et ESR ne sont pas interchangeables. Les notes d’administration mentionnent ESR 153.7.0 à la même date, sans confirmer pour autant cette correction dans ESR. Les politiques de l’entreprise restent applicables. [1] [4]

Préparer sans perdre de données

Prévoyez un système pris en charge, un compte autorisé, l’adresse intranet concernée et l’assistance informatique sur les postes administrés. Notez système, version, origine de l’installation, état du VPN, durée approximative et heure du problème. N’utilisez que des identifiants autorisés. Sauvegardez les données selon la procédure interne ; une copie manuelle du profil exige la fermeture complète de Firefox. Un profil peut contenir mots de passe et sessions : conservez-le dans un stockage protégé à accès limité, jamais en pièce jointe d’un ticket. [3]

Cinq étapes sûres

  1. Relevez version et canal dans Aide > À propos de Firefox. Avec une installation Mozilla, cette fenêtre peut déjà lancer la recherche et le téléchargement d’une mise à jour. Si une plage de maintenance est imposée, consultez d’abord l’équipe informatique ou la gestion des logiciels. Consultez about:policies sans modifier les politiques. [2]
  2. Faites confirmer par l’équipe informatique que l’application utilise NTLM ou Kerberos/Negotiate. Distinguez une interface figée d’une page attendant le serveur. Maintenez le VPN nécessaire. Évitez les tentatives répétées avec un mot de passe erroné susceptibles de verrouiller le compte.
  3. Respectez le canal : mise à jour intégrée pour une installation Mozilla autonome, Store pour une installation issue du Store, gestionnaire de paquets pour Linux, déploiement approuvé pour un poste d’entreprise. Redémarrez puis contrôlez la version. Ne superposez pas un autre type d’installation et ne contournez pas les politiques. [2]
  4. Effectuez une connexion normale avec le même compte autorisé, la même application et les mêmes conditions réseau/VPN. Comparez délai et réactivité avec l’état initial. Enregistrez le travail avant une déconnexion nécessaire. Ne consignez ni ne partagez mots de passe, cookies ou en-têtes complets d’authentification.
  5. Vérifiez la connexion, les pages nécessaires de l’application et la réactivité du navigateur. Si le gel persiste, transmettez version, heure, application et observations expurgées à l’équipe informatique. Ne désactivez ni validation des certificats ni mécanismes d’authentification et n’ajoutez pas de larges listes de confiance.

Vérifier le résultat et prévoir la reprise

Le succès correspond à une application utilisable sans le gel observé, pas seulement à un navigateur annoncé à jour. Sinon, examinez séparément réseau, proxy, service d’identité, extensions et application. Une correction fournisseur n’exclut pas ces causes. Suspendez le déploiement selon la procédure interne en cas de nouvelle régression. Une sauvegarde de profil ne garantit pas un retour sûr à une ancienne version : n’y ouvrez pas aveuglément un profil modifié par une version récente. Convenez d’une reprise avec l’équipe informatique et une sauvegarde compatible.

Limites, solutions temporaires et sources

Un autre navigateur déjà approuvé peut rétablir temporairement l’accès sans démontrer la cause. Ne changez pas de navigateur administré ou de canal sans vérifier la compatibilité. Cette correction ciblée n’est pas une réparation garantie du SSO. Ces vérifications ne nécessitent ni outil payant ni nouveau matériel. Aucun lien affilié ni essai indépendant. Revérifiez les sources avant un déploiement ultérieur. [1] [4]