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.