marcoandClaude Opus 4.8
f40be6e4bd
Ursache des 404 bei Zugriff über IP/Proxy: .NET-HttpListener bedient den Prefix http://localhost:8077/ nur bei Host: localhost. socat (L4) reicht den originalen Host-Header durch -> 404. Jetzt sitzt ein winziger nginx im Container davor, der den Host-Header auf localhost umschreibt (Upstream [::1]:8077, IPv4 als Fallback). App-Code bleibt unverändert. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Intune Manager - Docker-Test (self-hosted)
Test-Aufbau, um den Intune Manager als Container zu verproben. Der bestehende
App-/Client-Teil (Start.ps1, src/, www/) wird nicht verändert — er wird nur
unverändert ins Image kopiert. Container-Spezifika laufen über Env-Variablen und ein
Entrypoint-Script.
Kein Caddy/TLS enthalten — der vorhandene Reverse-Proxy zieht den veröffentlichten Port (
8080) an. HTTPS macht der Proxy.
Wie es funktioniert
- Die App bindet unverändert auf
http://localhost:8077/(nur containerintern) und bedient — bedingt durch .NET-HttpListener— nur Requests mitHost: localhost. - Ein interner nginx (Port 8080) leitet auf die App weiter und schreibt dabei den
Host-Header auflocalhostum. Ohne dieses Rewrite käme bei Zugriff über IP/Proxy ein404. Der App-Code bleibt unangetastet. - Settings/Policy-Exporte liegen im Volume
/data(XDG_CONFIG_HOME=/data, wird vonGet-AppDataDirauf Linux automatisch genutzt).
Bauen & starten
docker compose -f docker/docker-compose.yml up --build -d
Logs ansehen:
docker compose -f docker/docker-compose.yml logs -f
Erwartet: „Intune Manager - Web Edition" und „URL: http://localhost:8077/".
Den Reverse-Proxy auf http://<docker-host>:8080 zeigen lassen (reiner HTTP-Proxy,
keine WebSockets/Callbacks nötig).
Erststart: Verbindung konfigurieren
Beim ersten Start ist noch kein Tenant hinterlegt. Zwei Wege:
- UI: Seite öffnen → Einstellungen → Tenant-ID, Client-ID (Read/Write),
optional Client-ID (Read-Only) und Scopes eintragen und speichern. Landet in
/data/IntuneAppManager-Web/settings.json. - oder eine vorhandene
settings.jsonins Volume legen:docker cp settings.json intune-manager-test:/data/IntuneAppManager-Web/settings.json docker compose -f docker/docker-compose.yml restart
Login (Device-Code)
Der interaktive „Verbinden"-Button nutzt WAM/Loopback und funktioniert im Container
nicht — das ist erwartet. Für den Test den bereits vorhandenen Device-Code-Flow
per curl anstoßen (Host = euer Reverse-Proxy oder http://<docker-host>:8080):
curl -s -X POST http://<host>/api/connect/start
Antwort enthält code und urlComplete. Dann:
urlCompleteim Browser öffnen und als Admin anmelden.- Status pollen, bis verbunden:
(Feld
curl -s http://<host>/api/statusconnectedwirdtrue.) - Die UI im Browser neu laden → jetzt verbunden. Geräte/Gruppen/Policies laden zum Verifizieren.
Stoppen / Aufräumen
docker compose -f docker/docker-compose.yml down # Daten bleiben im Volume
docker compose -f docker/docker-compose.yml down -v # inkl. Daten löschen
Wichtige Hinweise (für den echten Einsatz)
- Kein eigener UI-Login und geteilte Sitzung: Wer die URL erreicht, kann den Login auslösen; die verbundene Graph-Sitzung gilt prozessweit. Die Instanz zwingend hinter Zugangsschutz stellen (Reverse-Proxy-Auth / Netzsegment / VPN). Eine Instanz = eine Team-Sitzung, kein sauberes Multi-Admin.
- Reports liegen unter
/tmp(nicht persistent) — für den Test ausreichend. - Das ist ein Test-Setup. Echtes Mehrbenutzer (Login pro Admin) wäre ein separater Ausbau (Auth-Code-Flow + Sitzungs-Isolation).