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.

Introduction au Windows Admin Center

Après avoir déployé mon premier Windows Server 2019 sur une plateforme de tests, j’ai été invité à essayer le Windows Admin Center au premier démarrage. Cet outil se veut être le futur de l’administration des plateformes Windows, serveurs et clientes et souhaiterait bien rendre le besoin d’interfaces graphiques sur les serveurs obsolète.

Basé sur une interface web, le Windows Admin Center – que j’appellerai WAC par la suite – est une grosse évolution du Server Manager qui n’avait pas bougé d’un iota ou presque depuis la sortie de Windows Server 2012. Tout comme lui, il fonctionne principalement grâce à WMI et offre un panel d’options pour gérer des serveurs distants (nativement à partir de 2016, avec une installation supplémentaire sur 2012 R2), mais aussi des postes de travail sous Windows 10, des clusters ou des infrastructures plus complètes, en local ou également dans Azure.

Idéalement, on installe le petit MSI d’une soixantaine de méga-octets du WAC sur une machine d’administration et ensuite on attaque cette interface web depuis n’importe quel navigateur, en local ou à distance.

Connexion à l’interface avec prompt de login.

Bien que l’outil soit utilisable en production selon Microsoft, il y a quand même quelques choix de design qui me perturbent : la connexion se fait via un vulgaire prompt et l’outil n’est pas compatible avec Internet Explorer, mais Edge, qui n’est pas disponible sur Windows Server. Cette restriction – techniquement compréhensible – pourrait se révéler handicapante dans certains environnements où l’administration ne se fait qu’à partir d’un serveur et sur lequel aucun autre navigateur est installé.

Au moins Microsoft ne manque pas d’humour quant à l’abandon d’Internet Explorer !

Pour la suite des événements, j’ai donc dû déployer un Firefox sur mon serveur pour naviguer. L’interface est plutôt agréable, typique des produits Microsoft actuels.

La page d’accueil d’un système présente les informations de base, à peu près comme on pouvait les trouver sur le Server Manager avant.

Très peu de dépaysement mais également très peu de nouvelles fonctionnalités. Ce qui est appréciable, c’est que l’on regroupe sous un même outil le Server Manager mais aussi les différentes consoles (regedit, mmc), sans oublier la possibilité d’exécuter du Powershell à distance !

Bon, ça n’a pas fonctionné du premier coup, mais après avoir martelé la touche entrée et saisi mes identifiants, c’est bien passé :

On peut même en théorie se passer des partages administratifs. Cependant, il faudra utiliser un autre navigateur que Firefox car il m’était impossible de parcourir l’arborescence jusqu’au bout. Microsoft ne supporte officiellement que Edge et Chrome – ce qui encore une fois, me paraît être un choix douteux étant donné la réputation de Chrome par rapport au soin apporté concernant la confidentialité des données de navigation.

Le panneau des rôles et fonctionnalités est évidemment inclus dans le WAC

Les fonctionnalités sont plus ou moins les mêmes lorsqu’on administre une station de travail avec Windows 10 ; étant donné qu’il existe déjà des outils de gestion de parc bien installés sur le marché, le WAC devrait rester cantonné à la gestion des serveurs et des infrastructures, d’autant plus qu’il y a de nombreuses intégrations possibles avec Azure (notamment une fonctionnalité de sauvegarde de serveur, que j’aimerais tester dès que possible).

Au final, après quelques heures passées sur l’outil, j’ai plus le sentiment d’avoir à faire à une évolution plus qu’une révolution, même si c’est une petite révolution qui pourra être menée par rapport aux habitudes sur les plateformes Windows. Une évolution, car le WAC ne reste qu’un Server Manager en plus moderne, un peu moins complexe, moins rigide et intégrant différentes consoles MMC ; une révolution car cet outil permet de pousser un peu plus les versions headless (sans interfaces graphiques) de Windows, plus légères et plus facilement administrables à distance. Si les interfaces graphiques avaient un sens pour une facilité d’administration avant et de gestion des fichiers (lorsqu’elles n’étaient pas requises pour un applicatif particulier, évidemment), c’est désormais le cas inverse : elles n’ont plus grand intérêt lorsqu’on peut tout réaliser à distance. Si cela est depuis longtemps possible avec Powershell, les outils de management déployés ici et là sur les stations, les consoles MMC ou encore le Server Manager, le WAC a l’intérêt d’offrir une centralisation sur un seul outil accessible depuis n’importe quelle station du réseau. J’ai hâte de pouvoir utiliser un peu plus cet outil dans un cadre plus consistant que sur une maquette de test. 😀

Vous pouvez télécharger le setup du Windows Admin Center directement sur le site de Microsoft.

Installation des drivers (Integration Services) sur une VM Windows Server 2003 hébergée sur Hyper-V 2016

Bien qu’il puisse s’agir d’une faute professionnelle que de déployer à l’aube de 2019 des machines Windows Server 2003, dans le cadre du projet sur lequel je planche actuellement j’ai dû procéder à un tel crime de lèse-majesté.

Le hic, c’est qu’Hyper-V 2016, à la différence de 2012, ne supporte plus Windows Server 2003 (entre autres), ce qui signifie que le bon fonctionnement d’un tel OS n’est pas garanti et que les drivers (regroupés sous un pack nommé Integration Services, qui pourrait être comparé aux VMtools sous VMware) ne sont pas fournis ; si Hyper-V 2012 proposait ces drivers nativement, Hyper-V 2016 procède à leur installation par internet. Afin de les déployer sur une machine 2003 – avec toutes les précautions que cela comprend ainsi que le bon sens qui doit vous dicter de ne pas déployer cela en production si possible – il faut donc ruser un peu.

Une première solution : installer Hyper-V 2012 sur une machine et récupérer ces drivers ; ils sont situés dans C:\Windows\System32\vmguest.iso. Ensuite, monter cette image ISO sur la VM 2003 et procéder à l’installation sur le serveur 2003 des packages.

La deuxième solution est la plus simple : sur les forums de Microsoft, de nombreux sujets traitent du problème que rencontrent certains utilisateurs, et il est possible de trouver l’image ISO d’Integration Services. Je vous fais grâce de la recherche, puisque j’ai uploadé l’ISO sur le serveur de manière à ce qu’il soit disponible en téléchargement direct. Comme pour la première solution, il suffit de monter cette image sur la VM 2003 et de procéder à l’installation.

A noter qu’il faudra que le Service Pack 2 soit déployé sur la VM afin que les Integration Services s’installent. Plusieurs pilotes (dont le très important pilote de carte réseau !) vont s’installer et un redémarrage sera nécessaire.

Installation des drivers réseau pour une VM Windows Server 2016 sur hôte Proxmox VE 5

Voici ce qui m’est arrivé à la fin de l’installation d’un contrôleur de domaine de test sous 2016 en mode Core sur mon hyperviseur fonctionnant sous Proxmox VE 5. En cause, l’absence de drivers pour la carte réseau qui est de type virtIO.

sconfig m’indique bien que je n’ai pas de carte réseau active.

Il est donc nécessaire d’installer ces drivers. Le site de documentation de la distribution Fedora explique rapidement ce que sont ces drivers virtIO et pourquoi il est nécessaire de les installer à part. Dans le cas présent, l’installation va être très facile. Il suffit de télécharger l’ISO (dernière version stable ou le canal « développement »), la monter sur la VM et ensuite d’installer le pilote correspondant.

Il y a pléthore de pilotes sur cet ISO, celui qui nous intéresse est dans NetKVM\2k16\amd64. En partant du principe que l’ISO est monté sur le lecteur D:, cela nous donne ceci dans l’invite de commandes :

d:
cd NetKVM\2k16\amd64

Bien évidemment, on remplacera 2k16 par la version de Windows concernée. Il y a de multiples fichiers dans le répertoire, mais le pilote s’installe à partir du fichier inf. Il reste à appeler pnputil pour installer le driver :

pnputil -i -a netkvm.inf

Quelques secondes plus tard :

Comme indiqué dans la documentation de Fedora, le pilote n’est pas signé par Microsoft – qu’importe.

L’instruction se termine, il suffit alors d’appeler de nouveau sconfig et de se rendre dans les propriétés de la carte réseau pour voir qu’elle est désormais visible et configurable !