Corriger les erreurs d'authentification Azure Blob — NetDrive

Un lecteur Azure Blob qui s’était monté sans problème la semaine dernière refuse maintenant de se reconnecter — l’Explorateur affiche une lettre de lecteur avec une erreur d’authentification au lieu de vos artefacts de build, et rien n’a changé dans votre pipeline. C’est presque toujours l’une de ces trois causes : un jeton SAS expiré, une clé de compte régénérée dont NetDrive n’a pas encore connaissance, ou une règle de pare-feu du compte de stockage qui a commencé à bloquer l’IP publique de la machine.

Monter Azure Blob Storage comme lecteur local

Avec NetDrive, Google Drive, OneDrive, S3, SFTP, WebDAV et plus apparaissent comme des lecteurs natifs sur Windows et macOS — sans synchronisation ni téléchargement complet.

• Connexion avec une clé de compte ou un jeton SAS restreint
• Le navigateur de fichiers permet de tester l'accès au conteneur avant le montage
• Les téléversements en arrière-plan gardent les écritures volumineuses hors du chemin critique

WindowsmacOS

Télécharger NetDrive →

Essai gratuit. Licences à vie et abonnements disponibles.

Pourquoi un lecteur Azure Blob fonctionnel échoue soudain à l’authentification

Contrairement à un mot de passe erroné, les échecs d’authentification Azure Blob sont rarement « faux depuis le début ». NetDrive prend en charge deux types d’identifiants pour Azure Blob Storage : la clé de compte primaire ou secondaire du compte de stockage, ou un jeton Shared Access Signature (SAS) restreint au conteneur. Les deux sont sensibles au temps, mais différemment — un jeton SAS porte une date d’expiration ferme que vous définissez à sa génération, tandis qu’une clé de compte reste valide jusqu’à ce que quelqu’un la régénère dans le portail Azure, ce qui invalide immédiatement toute connexion utilisant encore l’ancienne valeur.

La troisième cause est totalement extérieure aux identifiants : le pare-feu réseau du compte de stockage. Si Networking → Firewalls and virtual networks est réglé sur « Selected networks » au lieu de « All networks », Azure rejette la requête avant même de vérifier l’identifiant — et l’erreur qui en résulte peut ressembler exactement à une clé incorrecte.

Vérification 1 : expiration du jeton SAS ou rotation de la clé de compte

Commencez ici — cela résout la majorité des cas « ça marchait hier, plus aujourd’hui ».

1. Dans le Azure Portal, ouvrez votre compte de stockage et vérifiez avec quel type d’identifiant le lecteur a été configuré.
2. Si vous utilisez un jeton SAS : allez dans Security + networking → Shared access signature, et confirmez que la Expiry date du jeton généré n’est pas dépassée. Les jetons SAS sont souvent configurés pour expirer sous 30, 90 ou 365 jours — une valeur qui paraissait généreuse au moment de la configuration.
3. Si vous utilisez une clé de compte : allez dans Security + networking → Access keys et vérifiez si key1 ou key2 a été régénérée récemment. Régénérer une clé l’invalide immédiatement pour tout client utilisant encore l’ancienne valeur, y compris NetDrive.
4. Générez un nouveau jeton SAS (avec au minimum les permissions Read, Write, Delete, List, Add, Create sur le conteneur) ou copiez la clé de compte actuelle.
5. Ouvrez NetDrive → cliquez sur l’icône d’engrenage du lecteur Azure Blob concerné pour ouvrir ses paramètres de connexion, puis collez le nouvel identifiant dans le champ Authentication.
6. Cliquez sur Save, puis reconnectez le lecteur.

Vérification 2 : règles de pare-feu du compte de stockage

Si l’identifiant est à jour et que le lecteur ne s’authentifie toujours pas, les règles réseau du compte de stockage sont l’étape suivante à examiner.

1. Dans le Azure Portal, ouvrez Networking → Firewalls and virtual networks pour le compte de stockage.
2. Si le paramètre est Enabled from selected virtual networks and IP addresses, les requêtes de NetDrive sont rejetées sauf si l’IP publique de la machine est explicitement autorisée.
3. Trouvez l’IP publique actuelle de la machine — c’est facile à vérifier via une recherche dans un navigateur ou un outil en ligne de commande, et il vaut mieux la confirmer directement plutôt que de supposer qu’elle n’a pas changé.

4. Ajoutez cette IP sous Firewall → Address range, ou basculez la règle pour autoriser tous les réseaux si la restriction par IP n’est pas requise pour votre configuration.
5. Enregistrez la modification de la règle réseau dans Azure — cela peut prendre une minute ou deux pour se propager — puis relancez la connexion dans NetDrive.

Une connexion internet résidentielle ou de bureau avec une IP dynamique est un coupable récurrent classique ici : la règle de pare-feu était correcte lors de son ajout, puis le FAI a attribué une nouvelle adresse.

Confirmer la correction

Après avoir mis à jour les identifiants ou les règles de pare-feu, reconnectez le lecteur et vérifiez qu’il sert bien des données plutôt que d’afficher simplement « Connected » dans la liste des lecteurs.

Ouvrez le lecteur monté dans l’Explorateur ou le Finder et listez un dossier contenant des fichiers que vous reconnaissez. Si le contenu du dossier s’affiche et qu’un fichier s’ouvre sans erreur, l’identifiant et le chemin réseau fonctionnent tous les deux.

Conclusion

Les échecs d’authentification Azure Blob dans NetDrive proviennent bien plus souvent d’une expiration de jeton SAS, d’une rotation de clé de compte ou d’une règle de pare-feu du compte de stockage que d’une faute de frappe dans la configuration initiale. Vérifiez d’abord les identifiants, car ils sont plus rapides à écarter, puis passez au réseau. Pour la procédure de connexion initiale, voir Mount Azure Blob Storage on Windows with NetDrive ; si votre compte de stockage utilise Azure File Storage plutôt que Blob, Mount Azure File Storage on Windows couvre la configuration équivalente.

— Alex, NetDrive