Publie un premier service web Windows avec IIS

01Ce que ce TP ajoute — et ce qu’il ne répète pas

Ce TP ne réenseigne pas HTTP, HTTPS, TLS, DNS ni la méthode générale de diagnostic. Il réutilise :

windows/installer-inventorier-retirer-roles-fonctionnalites
windows/configurer-adressage-nommage-dns-local
windows/diagnostiquer-services-reseau-parefeu

reseaux/resoudre-noms-dns
reseaux/observer-http-https-tls
reseaux/diagnostiquer-service-bout-en-bout

bts-sisr/conduire-diagnostic-remediation
bts-sisr/construire-dossier-preuves

Le nouveau geste est volontairement ciblé : publier et exploiter un premier service web sur Windows Server avec IIS.

Le scénario PHP cité dans certaines progressions locales n’est pas ajouté ici. Le blueprint BTS le conserve comme exigence locale exacte ou variante technologique encore à arbitrer ; ce TP ne l’invente donc pas.

02Besoin de SORIA Distribution

SORIA Distribution demande un intranet interne de démonstration.

Architecture minimale :

CLIENT-USERS
  |
  | DNS + HTTP TCP 8080
  v
SRV-WEB01 — Windows Server 2022 — IIS

Contraintes :

nom attendu        = intranet.corp.soria.test
service            = HTTP sur TCP 8080
accès attendu      = depuis la zone Utilisateurs du laboratoire
contenu            = page HTML statique de démonstration
site IIS           = dédié
application pool   = dédié
pare-feu           = règle entrante bornée au besoin
preuves             = DNS + port + HTTP + état IIS + journal
production réelle  = interdite

Si tu réutilises le plan de l’évaluation précédente, adapte les exemples à tes propres sous-réseaux validés. Les adresses ci-dessous restent purement pédagogiques.

03Établis l’état avant changement

Sur SRV-WEB01 :

Get-WindowsFeature -Name Web-Server
Get-NetIPConfiguration
Get-NetFirewallProfile |
  Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
Get-Service W3SVC,WAS -ErrorAction SilentlyContinue

Consigne :

rôle IIS présent ou absent
adresse IPv4 du serveur
profil de pare-feu actif
état de W3SVC et WAS si présents
snapshot / point de retour disponible

Ne commence pas par modifier le pare-feu ou DNS. Il faut d’abord connaître l’état initial.

04Simule puis installe IIS

Commence par la simulation :

Install-WindowsFeature -Name Web-Server \
  -IncludeManagementTools -WhatIf

Après validation du changement sur une VM de laboratoire snapshotée :

$result = Install-WindowsFeature -Name Web-Server \
  -IncludeManagementTools

$result | Format-List Success, RestartNeeded, ExitCode, FeatureResult
Get-WindowsFeature -Name Web-Server
Get-Service W3SVC,WAS

Le résultat attendu n’est pas seulement Installed = True. Les services nécessaires doivent être observables et le changement doit être traçable.

05Prépare un contenu et un pool dédiés

$siteName = 'SORIA-Intranet'
$poolName = 'SORIA-IntranetPool'
$root     = 'C:\SORIA-Labs\IIS\Intranet'
$serverIp = '10.44.0.114'   # exemple : adapte à ton plan validé

New-Item -ItemType Directory -Path $root -Force

@'
<!doctype html>
<html lang="fr">
<head><meta charset="utf-8"><title>SORIA Distribution</title></head>
<body>
  <h1>Intranet SORIA Distribution</h1>
  <p>Service IIS de laboratoire opérationnel.</p>
</body>
</html>
'@ | Set-Content -Path "$root\index.html" -Encoding UTF8

Charge le module d’administration et crée un pool séparé :

Import-Module WebAdministration
New-WebAppPool -Name $poolName
Get-WebAppPoolState -Name $poolName

Accorde uniquement la lecture nécessaire au contenu :

& icacls.exe $root /grant \
  "IIS AppPool\${poolName}:(OI)(CI)RX"

Get-Acl $root | Format-List

Un service web n’a pas besoin d’un droit d’écriture sur son contenu statique pour fonctionner.

06Crée un site avec un binding explicite

New-Website \
  -Name $siteName \
  -PhysicalPath $root \
  -IPAddress $serverIp \
  -Port 8080 \
  -HostHeader 'intranet.corp.soria.test' \
  -ApplicationPool $poolName

Vérifie :

Get-Website -Name $siteName |
  Select-Object Name, Id, State, PhysicalPath

Get-WebBinding -Name $siteName |
  Select-Object protocol, bindingInformation

Get-WebAppPoolState -Name $poolName

Un binding associe ici le service à une adresse, un port et un nom HTTP. Il ne crée pas lui-même l’enregistrement DNS.

07Valide d’abord localement sans masquer DNS

Teste le serveur avec son adresse tout en envoyant le nom attendu dans l’en-tête Host :

Invoke-WebRequest \
  -Uri "http://$serverIp`:8080/" \
  -Headers @{ Host = 'intranet.corp.soria.test' } \
  -UseBasicParsing

Puis observe les éléments locaux :

Get-Service W3SVC,WAS
Get-Website -Name $siteName
Get-NetTCPConnection -LocalPort 8080 -State Listen \
  -ErrorAction SilentlyContinue

Avec IIS, l’écoute HTTP passe par HTTP.sys. Ne déduis donc pas l’état applicatif uniquement du PID propriétaire du socket : vérifie aussi le site, le pool, le service et une vraie requête HTTP.

08Relie le service au DNS du laboratoire

Sur le serveur DNS du laboratoire, commence par vérifier l’absence ou la valeur de l’enregistrement :

Resolve-DnsName intranet.corp.soria.test \
  -ErrorAction SilentlyContinue

Si le scénario utilise le rôle DNS Windows et qu’aucun enregistrement correct n’existe, crée-le sur le serveur DNS autorisé :

Add-DnsServerResourceRecordA \
  -ZoneName 'corp.soria.test' \
  -Name 'intranet' \
  -IPv4Address $serverIp

Depuis le client :

Resolve-DnsName intranet.corp.soria.test

Conserve la valeur renvoyée. Une résolution réussie vers une mauvaise adresse reste une panne.

09Ouvre seulement le flux nécessaire

Adapte le sous-réseau à ton plan VLSM validé :

$usersSubnet = '10.44.0.0/26'   # exemple à adapter

New-NetFirewallRule \
  -DisplayName 'SORIA-Lab-IIS-8080' \
  -Direction Inbound \
  -Action Allow \
  -Protocol TCP \
  -LocalPort 8080 \
  -RemoteAddress $usersSubnet \
  -Profile Domain,Private

Vérifie la règle :

Get-NetFirewallRule -DisplayName 'SORIA-Lab-IIS-8080' |
  Get-NetFirewallPortFilter

N’utilise pas « désactiver le pare-feu » comme méthode de diagnostic ou de mise en service.

10Fais la recette depuis le client attendu

Sur CLIENT-USERS :

Resolve-DnsName intranet.corp.soria.test

Test-NetConnection intranet.corp.soria.test \
  -Port 8080 -InformationLevel Detailed

$response = Invoke-WebRequest \
  -Uri 'http://intranet.corp.soria.test:8080/' \
  -UseBasicParsing

$response.StatusCode
$response.Content

Preuves minimales :

DNS -> adresse attendue
TCP 8080 -> joignable depuis le client autorisé
HTTP -> code de succès
contenu -> page attendue

Test négatif

Vérifie qu’un port non publié ne répond pas :

Test-NetConnection intranet.corp.soria.test -Port 8081

Si le laboratoire contient un poste situé hors du sous-réseau autorisé, teste aussi TCP 8080 depuis ce poste. La règle de pare-feu doit empêcher ce second accès.

Un test négatif sur 8081 prouve seulement l’absence de service sur ce port ; il ne remplace pas le test d’isolation depuis une zone non autorisée lorsque celle-ci existe.

11Lis les journaux comme preuve de service

Récupère l’identifiant IIS du site :

$siteId = (Get-Website -Name $siteName).Id
$logDir = "C:\inetpub\logs\LogFiles\W3SVC$siteId"

Get-ChildItem $logDir -Filter *.log \
  -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1

Puis lis les dernières lignes du fichier réellement produit :

$latestLog = Get-ChildItem $logDir -Filter *.log |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1

Get-Content $latestLog.FullName -Tail 20

Corrèle avec les événements récents :

Get-WinEvent -FilterHashtable @{
  LogName   = 'System'
  StartTime = (Get-Date).AddHours(-1)
} | Where-Object ProviderName -Match 'WAS|W3SVC' |
  Select-Object TimeCreated, Id, LevelDisplayName,
                ProviderName, Message

Une ligne de journal prouve une requête observée ; elle ne prouve pas à elle seule que tous les utilisateurs attendus peuvent utiliser le service ni que la configuration survivra à toutes les pannes.

12Panne volontaire mono-cause

Après validation de l’état fonctionnel, l’évaluateur injecte une seule cause parmi :

A — enregistrement DNS pointant vers une mauvaise adresse
B — site IIS arrêté
C — HostHeader du binding incorrect
D — règle de pare-feu IIS désactivée ou limitée au mauvais sous-réseau
E — permission de lecture retirée au pool sur le répertoire du site

Symptôme remis :

« Le client autorisé ne peut plus utiliser intranet.corp.soria.test:8080. »

Méthode obligatoire :

1. collecter les faits ;
2. distinguer DNS, port, site, binding, permission et pare-feu ;
3. formuler plusieurs hypothèses ;
4. choisir un test discriminant ;
5. corriger uniquement la cause démontrée ;
6. refaire la recette positive et le test négatif ;
7. déclarer la limite de la preuve.

Outils utiles :

Resolve-DnsName intranet.corp.soria.test
Test-NetConnection intranet.corp.soria.test -Port 8080
Get-Website -Name 'SORIA-Intranet'
Get-WebBinding -Name 'SORIA-Intranet'
Get-WebAppPoolState -Name 'SORIA-IntranetPool'
Get-Service W3SVC,WAS
Get-NetFirewallRule -DisplayName 'SORIA-Lab-IIS-8080'
Get-Acl 'C:\SORIA-Labs\IIS\Intranet'
Get-WinEvent -LogName System -MaxEvents 50

13Prépare le retour arrière

Dans la VM de laboratoire :

Remove-NetFirewallRule \
  -DisplayName 'SORIA-Lab-IIS-8080' \
  -ErrorAction SilentlyContinue

Remove-Website -Name 'SORIA-Intranet' \
  -ErrorAction SilentlyContinue

Remove-WebAppPool -Name 'SORIA-IntranetPool' \
  -ErrorAction SilentlyContinue

Remove-Item 'C:\SORIA-Labs\IIS\Intranet' \
  -Recurse -Force -ErrorAction SilentlyContinue

Si ce TP a créé l’enregistrement DNS, retire exactement cet enregistrement sur le serveur DNS du laboratoire. Ne supprime jamais une zone complète pour annuler une entrée A.

Le retrait du rôle IIS n’est nécessaire que si la VM était dédiée au TP et que le plan de retour l’exige :

Uninstall-WindowsFeature -Name Web-Server -IncludeManagementTools -WhatIf

14Conserve les preuves BTS

L’entrée de dossier doit répondre au contrat :

EXIGENCE
Mettre à disposition un premier service web Windows aux utilisateurs autorisés.

CONTEXTE
SORIA Distribution — IIS interne de laboratoire, données et adresses synthétiques.

ACTION
Installation du rôle, site/pool dédiés, binding, DNS, permission et règle de flux bornée.

RÉSULTAT + VÉRIFICATION
Résolution correcte, TCP 8080 joignable depuis la zone autorisée, réponse HTTP attendue, journal IIS corrélé et test négatif conservé.

LIMITE
Le TP ne démontre ni haute disponibilité, ni exposition Internet, ni TLS de production, ni application PHP, ni résistance à une cyberattaque complète.

Livrables :

1. schéma client -> DNS -> IIS ;
2. fiche de changement ;
3. configuration utile du site et du binding ;
4. règle de pare-feu et portée ;
5. preuve DNS ;
6. preuve TCP ;
7. preuve HTTP ;
8. extrait de journal pertinent ;
9. test négatif ;
10. diagnostic de la panne imposée ;
11. rollback ;
12. limite de la conclusion.