TP2 — Services & identité : l'AD, Nextcloud et la supervision

Conception d'architecture Ingénieurs · ESIROI Active Directory · Nextcloud · Alloy → Loki → Grafana · ~6 h

---

1. Contexte — la matrice rencontre la réalité

Au TP1, vous avez écrit la matrice avant les services — des témoins nc en tenaient la place. Aujourd’hui, les vrais services arrivent, et le contrat s’inverse : chaque service doit rentrer dans la matrice, ou la faire amender en justifiant l’amendement. C’est la gestion de changement d’une vraie infrastructure : rien ne s’ouvre « parce que ça ne marche pas sinon ».

Et le service central du jour est celui qui met toutes les matrices à l’épreuve : l’annuaire. Un Active Directory ne parle pas qu’en LDAP — DNS, Kerberos, SMB… — c’est le service qui fait exploser les matrices trop simples. Vous allez le monter vous-mêmes, et découvrir ligne à ligne ce qu’il exige.

La dérogation assumée — un AD Windows dans un module open source

Le TP0 impose l’open source, et votre annuaire sera un Windows Server. C’est une dérogation délibérée : dans les organisations que vous rencontrerez, l’annuaire d’entreprise est un AD — le monde réel est hybride, et savoir intégrer un composant propriétaire dans une architecture maîtrisée est une compétence en soi. La dérogation se documente dans votre tableau d’arbitrage : c’est exactement ce qu’on ferait en clientèle.

Rappel — qui héberge quoi (groupe de 4)

Les services du jour sont répartis sur vos postes, chacun dans le VLAN de sa zone :

• Membre B — TAAF-WEB-001 (z-front) : Caddy + Nextcloud
• Membre C — TAAF-AD-001 (z-services, Windows, monté à la main) + TAAF-DB-001 : AD + PostgreSQL
• Membre D — TAAF-MON-001 (z-soc) : Loki + Grafana

Comme ils sont dans des VLAN différents, tout flux entre services traverse l’OPNsense du Membre A (router-on-a-stick) : Nextcloud→AD (LDAP), Nextcloud→PostgreSQL, les agents→Loki… chacun doit figurer dans votre matrice, sinon le pare-feu le bloque. Un service qui « marche en local mais pas depuis l’autre poste » = une ligne manquante dans la matrice, pas un bug.

Ce que le dépôt server vous fournit pour ce TP

Dans server/ingenieurs/services/, un dossier par service, chacun avec son README.md : ad/ (scripts PowerShell de promotion, clonés depuis le dépôt active-directory), postgresql/ (provisioning de TAAF-DB-001, jeu de données du dépôt sql), nextcloud/ (docker-compose.yml Caddy + Nextcloud, .env.example à copier en .env, jamais commité), supervision/ (Loki, Grafana, configuration Alloy). Ce sont des indications et des briques, pas des installations clé en main : les IP, les noms et les mots de passe sont les vôtres.

---

Des indices, pas des réponses

Chaque palier dit ce que vous devez obtenir et comment le prouver. Le « comment faire » n’est pas écrit : cherchez, dans la documentation des outils et dans le dépôt server. Si vous bloquez, des blocs Indice repliés vous orientent sans donner la solution. Dans le rapport, listez les indices que vous avez ouverts : sans malus, c’est une information honnête sur votre autonomie.

2. Palier E6 : l’annuaire, un AD monté par vous

Créez la VM à la main dans VirtualBox, comme OPNsense : c’est une appliance qui s’installe, pas une box à télécharger.

Paramètre	Valeur
VM	TAAF-AD-001, 4 Go de RAM, 2 vCPU, ~40 Go de disque
Réseau	une seule carte, pontée sur le port access du switch (VLAN de z-services, poste du Membre C), IP statique de votre plan (ex. 10.G.10.10)
OS	Windows Server (ISO d’évaluation 180 jours), édition Desktop Experience

Ce que vous devez obtenir, dans l’ordre que vous jugerez bon :

• une machine nommée TAAF-AD-001, en IP statique, avant toute promotion ;
• un domaine propre à votre groupe, par exemple base-g<G>.taaf, distinct de celui du groupe voisin (au TP3, deux domaines identiques ne cohabitent pas) ;
• le DNS de ce domaine porté par l’AD lui-même ;
• trois comptes aux rôles distincts : un utilisateur standard, un compte de service pour Nextcloud (jamais un compte d’administration), un administrateur nommé. Ce qui ne sert pas est désactivé ;
• depuis les autres zones, la résolution de votre domaine passe par OPNsense, qui sait vers qui l’envoyer ; le DNS général du reste du SI ne change pas.

La matrice d’abord

Avant de toucher Windows, écrivez ce que l’AD va exiger comme flux : qui doit lui parler, sur quoi ? DNS 53, LDAP 389, Kerberos 88, SMB 445… Chaque port ouvert se justifie, les autres restent fermés. Un AD joignable en any depuis tout le SI est la première marche de la plupart des compromissions réelles.

Indice : par où chercher

• Sous Windows Server, un annuaire est un rôle qui s’installe, puis une promotion en contrôleur de domaine ; une « nouvelle forêt » est le point de départ quand rien n’existe. Le DNS s’installe avec la promotion.
• Côté OPNsense, le résolveur (Unbound) sait déléguer un domaine précis à un autre serveur DNS sans changer le reste : cherchez « forwarding » par domaine dans ses réglages.
• Le dépôt server fournit dans services/ad/ des scripts PowerShell de création d’objets, pas la promotion : lisez-les pour comprendre ce qu’ils attendent avant de les lancer.

Preuve E6 : depuis z-front, la résolution DNS du domaine répond via la patte OPNsense ; un ldapsearch (ou Test-ComputerSecureChannel depuis une machine jointe) réussit sur 389 ; et un port AD non déclaré dans la matrice tombe en filtered.

---

3. Palier E7 : les services, PostgreSQL et Nextcloud sur l’AD

Étendez votre Vagrantfile : le provisioning de TAAF-DB-001 installe PostgreSQL, celui de TAAF-WEB-001 installe Caddy et Nextcloud (conteneurs bienvenus : un docker compose versionné est du code parfaitement acceptable).

Ce que vous devez obtenir :

• PostgreSQL avec une base dédiée à Nextcloud, un rôle dédié, et une écoute restreinte : il ne répond qu’à qui en a besoin ;
• Nextcloud dans z-front, sa base dans z-services : le flux 5432 de votre matrice devient réel, à travers OPNsense ;
• Nextcloud authentifie sur l’AD : un utilisateur du domaine se connecte sans compte local, et Nextcloud lit l’annuaire avec le compte de service, jamais l’administrateur ;
• le provisioning est idempotent : deux passages, même résultat.

LDAP en clair, à dessein

Le 389 transporte l’annuaire en clair. C’est un écart réel et assumé, qui reste à l’intérieur d’une zone contrôlée aujourd’hui, et que le tunnel du TP3 devra protéger dès que ce flux traversera un lien. Notez-le dans votre rapport comme dette connue : un audit doit pouvoir la retrouver, datée et argumentée. (LDAPS avec une CA interne : bonus.)

Indice : par où chercher

• PostgreSQL n’écoute que sur la boucle locale par défaut, et refuse les clients qu’il ne connaît pas : deux fichiers de configuration sont en jeu, l’un pour l’adresse d’écoute, l’autre pour qui a le droit de se connecter d’où.
• Nextcloud a une application dédiée à l’authentification sur un annuaire LDAP ; elle demande un compte pour lire l’annuaire et une base de recherche.
• Le dépôt server fournit dans services/nextcloud/ et services/postgresql/ des briques à compléter : les adresses, les noms et les secrets sont les vôtres, et rien de ce que vous y écrivez ne se commite.

Preuve E7 : un login Nextcloud avec un compte du domaine réussit ; le compte de service LDAP n’a que les droits de lecture nécessaires ; le balayage depuis z-front ne montre que les flux de la matrice.

---

4. Palier E8 : la supervision, construire la chaîne, pas l’opérer

Vous ne faites pas de détection dans ce module. Mais une architecture qui n’a pas prévu son observabilité ne pourra jamais l’accueillir. Vous construisez la chaîne :

• sur TAAF-MON-001 (z-soc) : Loki (ingestion) et Grafana ;
• chaque machine Linux pousse ses journaux système vers Loki (les journaux Windows de l’AD : bonus, exporter les événements de sécurité vaut des points, pas des excuses) ;
• OPNsense pousse aussi ses journaux de pare-feu, vos refus block log ;
• dans Grafana, consulté depuis mgmt et jamais depuis les zones : un tableau de bord minimal, les refus du pare-feu par zone source.

L’invariant du TP1 s’applique à la lettre : tout pousse vers le SOC, rien n’en sort. Si votre configuration a besoin d’un flux SOC → zone, c’est elle qui a tort.

Indice : par où chercher

• Alloy est l’agent : il lit des fichiers ou le journal système et écrit vers Loki en HTTP. C’est lui qui initie, pas Loki.
• OPNsense sait envoyer ses journaux en syslog vers une cible distante ; Loki, lui, ne parle pas syslog. Quelque chose doit écouter le syslog dans z-soc et le remettre à Loki : Alloy sait le faire.
• Le dépôt server fournit dans services/supervision/ de quoi lancer Loki et Grafana ; la configuration de collecte est à écrire.

Preuve E8 : une requête LogQL montre un refus que vous venez de provoquer (un balayage depuis z-front, par exemple) ; et depuis z-front, l’ingestion Loki est open mais Grafana est filtered : Grafana ne se consulte pas depuis le SI.

---

5. Le rapport : chapitre TP2

Le Vagrantfile étendu et le config.xml à jour vivent dans votre dépôt Git : c’est votre outil, pas le livrable. Ce qui est corrigé, c’est le chapitre TP2 de votre rapport de réalisation. Les preuves à coller, chacune légendée, hostname et date lisibles :

1. L’AD en service : capture du gestionnaire de serveur ou de Get-ADDomain : nom du domaine, TAAF-AD-001 contrôleur ; et la liste de vos trois comptes avec leur rôle (aucun mot de passe visible).
2. Le DNS porté par l’AD : une résolution du domaine depuis z-front, qui passe par la patte OPNsense (forward conditionnel).
3. Nextcloud authentifié sur l’AD : capture d’une session Nextcloud ouverte avec un compte du domaine, et la configuration du backend LDAP montrant le compte de service (mot de passe masqué).
4. La matrice amendée : tableau dans le rapport : chaque flux ajouté depuis le TP1 daté et justifié, dette LDAP en clair incluse.
5. Le balayage depuis z-front : après services : seuls les flux de la matrice répondent ; 3100 ouvert et 3000 filtré vers TAAF-MON-001.
6. Un refus en LogQL : capture Grafana (consulté depuis mgmt) : la requête et une ligne de résultat horodatée, provoquée par vous.
7. L’idempotence : les dernières lignes de deux vagrant provision successifs : pas d’erreur, pas de changement au second.
8. La procédure AD : en une demi-page : les étapes de promotion telles que vous les avez faites, ce qui n’a pas marché du premier coup.

6. Les dix questions

De la plus facile à la plus difficile. Chaque réponse cite une valeur relevée dans vos captures. Barème : le rapport.

● Facile : relever, nommer, constater

1. Q1 : Relevez dans vos captures le nom de votre domaine AD, l’IP de TAAF-AD-001 et vos trois comptes avec le rôle de chacun.
2. Q2 : Quelle requête LogQL avez-vous exécutée pour voir un refus du pare-feu ? Recopiez-la avec une ligne de résultat et son horodatage.
3. Q3 : Dans votre balayage depuis z-front vers TAAF-MON-001, quel est l’état de 3100 et de 3000 ? Recopiez la sortie.

●● Moyen : expliquer, justifier, relier

4. Q4 : Listez les flux que vous avez ajoutés à la matrice depuis le TP1 (source, destination, port, date) et la justification de chacun. Y en a-t-il un que vous avez d’abord ouvert « pour que ça marche » avant de le justifier ?
5. Q5 : Pourquoi Nextcloud se lie-t-il à l’AD avec un compte de service et non avec l’administrateur ? Que peut faire un attaquant qui a lu la configuration LDAP de Nextcloud, dans chacun des deux cas ?
6. Q6 : Décrivez le forward conditionnel d’Unbound que vous avez configuré : quelle zone DNS part vers l’AD, et pourquoi le reste du SI ne doit pas utiliser l’AD comme résolveur général.
7. Q7 : « Tout pousse vers le SOC, rien n’en sort. » Montrez avec vos règles comment Alloy et OPNsense poussent vers Loki sans qu’aucune règle SOC → zone existe. Qu’aurait exigé un collecteur qui tire les journaux, et que casse-t-il ?

●●● Difficile : arbitrer, prouver, généraliser

8. Q8 : Le LDAP en clair sur 389 est une dette assumée. Décrivez ce qu’un attaquant capable d’écouter le trunk voit passer lors d’un login Nextcloud, ce que LDAPS avec votre CA interne y change, et ce que ce changement coûte à l’exploitation (émission, renouvellement, confiance dans la CA).
9. Q9 : Prouvez l’idempotence avec votre capture des deux vagrant provision. Puis expliquez une étape de votre provisioning qui n’était pas idempotente au départ, ou qui aurait pu ne pas l’être, et comment vous l’avez rendue telle.
10. Q10 : Un AD joignable en any depuis tout le SI est « la première marche de la plupart des compromissions réelles ». Avec votre matrice, tracez le chemin d’un attaquant depuis TAAF-WEB-001 vers un compte administrateur du domaine : quelles lignes l’arrêtent, laquelle manquerait dans une matrice naïve, et quel événement votre Loki verrait passer.

7. Critères de réussite

Critère	Ce qu’on vérifie
L’AD est monté et raisonné	Domaine propre au groupe, DNS porté, 3 comptes typés, ports ouverts = ports justifiés.
Nextcloud vit dans l’architecture	Servi par Caddy en z-front, base en z-services, authentification par l’AD via le compte de service.
La matrice a survécu aux services	Les amendements sont datés et justifiés ; rien d’ouvert « pour que ça marche ».
La chaîne de supervision tient l’invariant	Les refus sont requêtables en LogQL ; rien ne sort de z-soc ; Grafana injoignable depuis les zones.
Le code est idempotent	vagrant provision deux fois de suite : ni erreur ni changement au second passage.

La suite — TP3

Votre base est complète : services, identité, supervision. Mais elle est seule. Au TP3, l’archipel voisin apparaît : un tunnel IPsec négocié entre vos deux groupes — et l’épreuve finale du module, le destroy.

---

Récapitulatif — ce qu’il vous faut pour démarrer

• Le TP1 au palier E5 (matrice posée, balayage bash « après » conforme, check-vm.sh passé sur chaque VM).
• L’ISO d’évaluation Windows Server téléchargée (180 jours — largement assez pour le module).
• ~12 Go de RAM utilisés VMs allumées : confortable sur vos 32 Go, mais budgétez quand même dans le Vagrantfile.
• Le dépôt Git du groupe, à jour.