Access Denied en chaîne sur un FTP porté par IIS

J’ai mis en place un serveur FTP porté par un serveur IIS installé sur un Windows Server 2016. Ce serveur FTP autorise un compte de service sans droits particuliers à écrire sur un répertoire virtuel configuré dans IIS.

Ce compte de service est bien renseigné pour avoir les droits sur le répertoire dans lequel il est censé écrire, et ses droits Read, Write sont bien portés à la fois sur la racine FTP ftproot et sur le répertoire virtuel. Cependant, à la connexion et ce peu importe le client FTP, j’obtenais un simple Access Denied après la transaction d’authentification et l’acceptation du certificat SSL. Après avoir essayé avec mon compte d’administration ayant exactement les mêmes privilèges sur la machine, cela fonctionnait. Le problème est donc lié au compte en lui-même.

Un petit tour dans le fichier de configuration de IIS disponible dans C:\Windows\System32\inetsrv\config\applicationHost.config (comme expliqué dans cet article) me donne rien de plus : les balises sont bien renseignées et le compte en question a bien les droits de connexion.


J’essaye alors d’ajouter le compte en tant qu’administrateur local pour voir si cela fait la différence, et c’est alors qu’un détail me saute aux yeux : dans la fenêtre du groupe des administrateurs locaux, le compte apparaît avec son appellation pré-Windows 2000. Sur cet exemple, le compte testcomptedeserviceftp@mondomaine.com est renseigné avec son nom pré-Windows 2000 MONDOMAINE\testcomptedeservicef :


On peut vérifier dans l’ActiveDirectory les deux noms de connexion :

La console ActiveDirectory Users and Computers permet de vérifier les deux logins d’un utilisateur.

Dans IIS, en remplaçant le nom de connexion usuel par le nom pré-Windows 2000, j’ai pu me connecter.

Il est donc nécessaire d’attribuer les privilèges en utilisant les noms pré-Windows 2000.

En effet, si le nom de mon compte d’administration n’était pas tronqué car identique qu’il soit pré-Windows 2000 ou non, ce n’était pas le cas pour mon compte de service (identifiant trop long). Je tentais donc de me connecter avec un compte inconnu de IIS ; j’ai donc appris aujourd’hui que ce dernier gère les privilèges FTP avec les noms de connexion pré-Windows 2000, ce qui m’a pris une petite heure à réaliser.

550 Cannot create a file when that file already exists sur un FTP porté par IIS

J’ai rencontré une erreur 550 ce jour en tentant d’accéder à un répertoire situé à la racine d’un serveur FTP porté par IIS sur 2008 R2 (IIS 7).

Après vérifications dans le IIS Manager, je n’ai rien trouvé de particulier au niveau des autorisations, le compte que j’utilisais avait bien les droits en lecture et en écriture ; les autorisations NTFS sur le répertoire physique étaient également valides. De plus, ce répertoire n’est qu’une variante de deux autres répertoires identiques, créés en même temps, gérés par les mêmes comptes et accédés par les mêmes applications. Il n’y a donc aucune raison d’avoir une différence de configuration.

J’ai donc été vérifier le fichier de configuration des sites IIS dans C:\Windows\System32\inetsrv\config\applicationHost.config. A la toute fin de ce fichier, la première entrée concerne la racine du FTP, la deuxième concerne spécifiquement le répertoire auquel je n’ai pas accès.

En supprimant cette seconde balise <location> et en redémarrant mon site FTP, tout est revenu dans l’ordre.

Il n’y avait aucune raison d’avoir cette balise pour un seul des 3 répertoires ; par ailleurs ajouter une balise <add accessType= »Allow » users= »MonUser » permissions= »Read, Write » /> n’avait rien changé.

Erreur 530 lors de la connexion sur un FTP géré par IIS

J’ai installé récemment sous IIS un site FTP de backup qui est une réplication exacte du premier pour un client externe. Avant de procéder à la livraison de celui-ci, je voulais faire un test de connexion avec un utilisateur lambda pour m’assurer que tout était bien configuré proprement. Dans cet exemple, le serveur FTP se base sur ActiveDirectory pour obtenir la liste des comptes habilités ou non à lire ou écrire.

Et voilà que sur FileZilla, je me heurte à une erreur 530.

Un petit tour dans l’ActiveDirectory pour voir si il ne s’agit pas d’une variable mal configurée :

Aucun répertoire de profil n’est configuré, mais pas plus sur tous les autres comptes qui fonctionnent sur le premier environnement. Je décide donc de tester ce compte sur ce dit premier environnement et pas mieux, je me heurte à la même erreur.

Avec accord du client, je duplique donc un compte qui fonctionne et fais le test : pas mieux.

Je vérifie donc ma configuration IIS, et tous les paramètres sont strictement identiques. S’agissant visiblement d’un problème de répertoire, je vais sur la page des paramètres d’isolement des utilisateurs et le désactive (ce qui fait que chaque utilisateur n’est plus cantonné à son propre répertoire) :

Sur cette capture d’écran, le réglage bloque l’utilisateur dans un répertoire donné afin qu’il ne puisse pas browser l’intégralité du serveur FTP.

Une fois l’option Do not isolate users cochée, tout fonctionne avec les deux comptes, le dupliqué et mon compte de test. Le problème provient donc bien d’un répertoire non accessible qui est indiqué quelque part dans les comptes utilisateurs. Je fais un test avec l’original du compte dupliqué, et ça fonctionne !

Je décide donc de regarder au niveau des attributs des comptes. Sur les comptes qui fonctionnent, je vois ceci :

Deux attributs msIIS-FTPDir et msIIS-FTPRoot qui contiennent les informations permettant au serveur FTP d’isoler l’utilisateur. Sans ces attributs, pas de connexion possible. En analysant les attributs du compte dupliqué et de mon compte de test, je ne vois pas ces attributs, rendant alors la connexion impossible :

L’erreur n’a donc côté client jamais existé puisque les comptes utilisés avaient bien ces attributs de renseignés, ce qui n’était pas le cas pour mon compte de test.

Accéder à un serveur FTP situé derrière un routeur

Un ami qui partait en vacances et qui souhaitait sauvegarder les vidéos de son drone afin de pouvoir libérer la mémoire interne avait besoin d’un espace en ligne pour déposer les fichiers car sa tablette Android n’avait pas une capacité suffisante. J’ai donc ouvert sur le web mon serveur FTP personnel situé sur mon Cloud personnel. Je vais donc détailler les quelques pas nécessaires à la bonne configuration du serveur FTP afin qu’on puisse y accéder depuis le web même si il est situé derrière un routeur.

J’ai réalisé cette opération en me servant d’un routeur virtuel pfSense car mon serveur FTP est hébergé sur un serveur vSphere ESXi, ainsi que de FileZilla Server pour Windows, sur un 2012 R2. Pour des raisons de simplicité, j’ai utilisé le port 21 afin d’éviter des incompatibilités avec les clients FTP disponibles sur Android.

Etant donné qu’il est placé derrière un routeur, le serveur ne doit pas agir en mode actif, mais en mode passif. Le mode passif nécessite d’être configuré dans FileZilla, car afin de fonctionner correctement, il faut lui spécifier l’IP externe de la machine physique, c’est à dire, par exemple, 87.32.38.143, et non l’IP du serveur FTP sur le réseau local, qui pourrait être 192.168.1.2. Ensuite, un range de ports pour que le mode passif fonctionne, et le tour est joué.

A titre d’exemple, j’ai utilisé le range de ports 30000-30100 car il n’était utilisé par aucune autre application sur l’hyperviseur.

Il faut maintenant ouvrir et router correctement les ports, ce qui n’a rien de difficile. Sur pfSense, il m’a suffit de rediriger vers le serveur FTP les requêtes TCP sur le port 21 sur le range 30000 à 30100. Le test montre bien que tout communique sans problème :