Zum Inhalt

SGJ WLAN mit Microsoft 365 – Betriebsstand und Meilenstein

Stand: 16.09.2026. Kunde: Sportgymnasium Jena (SGJ). Profilinventur live: 13:11:40 MESZ. Diese Seite beschreibt den nachgewiesenen Ist-Zustand; historische Planungen sind keine aktive Konfiguration.

Ergebnis und Nachweisgrenze

Der Testclient konnte sich mit Microsoft 365 registrieren und nach einem gezielten RADIUS-Disconnect erfolgreich in VLAN10 anmelden: Aruba meldete authenticated=yes, VLAN10 aus VSA und DHCP Completed. Anschließend bestätigte der Auftraggeber erfolgreiche Tests. Damit sind Registrierung, RADIUS-Freigabe und der Übergang ins Nutzernetz für diesen Testfall belegt.

Noch offen: Eine komplett neue Registrierung mit ausschließlich dem automatisch vom Portal ausgelösten Disconnect wurde nach der CoA-Reparatur nicht erneut end-to-end getestet. Der erfolgreiche gezielte Test verwendete die MAC als User-Name; der Portalcode verwendet dort die Entra-UPN. Deshalb ist der vollautomatische Ablauf für zukünftige Registrierungen noch separat zu bestätigen. Die Erfolgsseite allein ist kein Nachweis der Internetfreigabe.

Interaktives Ist-Architekturdiagramm · Archify-Quelle. Diagramm mit 9/9 Qualitätsprüfungen und vier geprüften Browseransichten; Inhalt Deutsch, feste Viewer-Bedienung Englisch.

Welche Rolle und welches VLAN?

Die Entscheidung trifft die SGJ-Konfiguration des Registrierungsportals anhand der M365-Gruppen. RadiusDesk speichert das ausgewählte Profil für Benutzer/Gerät und liefert die RADIUS-Attribute. Aruba setzt die daraus resultierende Rolle und VLAN-Zuweisung um. Die UDM stellt im jeweiligen VLAN DHCP, Routing und Firewall bereit; sie entscheidet nicht anhand der M365-Gruppe.

RadiusDesk-Profil Profil-ID VLAN Aruba-User-Role Automatische Auswahl im Portal
SGJ - Schueler 63 10 Sportgymnasium Jena Standard, wenn kein Gruppen-Mapping passt
SGJ - Lehrer 64 30 Sportgymnasium Lehrer Mitglied der Lehrergruppe
SGJ - Trainer 65 30 Sportgymnasium Lehrer Keine eigene M365-Zuordnung konfiguriert
SGJ - IPADs 66 10 Sportgymnasium iPad Keine eigene M365-Zuordnung konfiguriert

Trainer existiert und teilt Rolle/VLAN mit Lehrern. iPads haben eine eigene Aruba-Rolle im Schüler-VLAN. Die Existenz der Profile belegt keine automatische Zuweisung oder aktuell angemeldete Geräte dieser Kategorien. Weitere SGJ-benannte Profile wurden in der Live-Abfrage nicht gefunden.

Quelle: RadiusDesk profiles (cloud_id24), radgroupcheck, radgroupreply; Komponenten FupAdd_63 bis FupAdd_66, VLAN-Feld Rd-Fup-Vlan. Alle vier enthalten Fall-Through := Yes, Rd-Fup-Bw-Up := 104857600, Rd-Fup-Bw-Down := 52428800, Rd-Fup-Session-Limit := 0. Eine tatsächliche Bandbreitendurchsetzung wurde nicht gemessen.

Die Funktion resolve_radiusdesk_profile in /opt/wlan-onboarding/app/main.py nimmt den ersten passenden Gruppen-Eintrag, sonst das Standardprofil. Aktuell existiert genau ein Mapping:

  • Gruppe bed2fde4-9398-47ec-af95-8f69d2bbb6de → SGJ - Lehrer.
  • Standard → SGJ - Schueler.
  • allowed_group_ids = []: keine zusätzliche Freigabe über eine dedizierte Gruppenliste.

Folge: „Schüler“ bedeutet hier technisch Fallback für ein zugelassenes Konto ohne Lehrergruppen-Treffer, nicht bestätigte Mitgliedschaft in einer Schülergruppe. Trainer wird nicht anhand von Berufsbezeichnung erkannt, iPads nicht anhand des Gerätetyps. Änderungen an dieser Logik erfordern einen eigenen fachlichen Auftrag.

Mandant und Registrierungsregeln

SGJ-Tenant: d6451f5a-1f4c-4e88-a21d-5a7691a195ba. Zulässige Kontodomänen: spogy-jena.de, sportgymnasium-jena.de, sportschule-jena.de, sportgymnasium-jena.info, spogyjena.onmicrosoft.com.

Admin-Gruppen-ID: 1a9245e4-383f-4014-99f0-3d6e56848bb2; diese ist keine zusätzliche VLAN-Zuweisungsregel. Verbindliche SGJ-Konfiguration: Abschnitt [sites.sgj] in /etc/wlan-onboarding/sites.toml. radiusdesk_enabled=true, coa_enabled=true, Realm SGJ.

Verbindungs- und Datenfluss

  1. Ein Gerät verbindet sich mit SSID SGJ. Aktuell ist das eine offene SSID (opensystem) mit MAC-RADIUS/PAP und externem Captive Portal. Es ist keine direkte WPA-Enterprise-Anmeldung mit M365-Passwort am WLAN-Supplicant.
  2. Ein noch nicht freigegebenes Gerät erreicht das Ausgangsnetz VLAN999 und erhält dort DHCP. Aruba verweist auf https://wlan-onboarding.lanstyle.de/?site=sgj.
  3. Das Portal startet die M365-Anmeldung im SGJ-Tenant. Microsoft-Anmelde- und CDN-Ziele müssen bereits im Ausgangsnetz erreichbar sein.
  4. Das Portal prüft die Standortregeln, schreibt die Geräte-MAC in Entra onPremisesExtensionAttributes.extensionAttribute15 und liest die Daten wieder zurück.
  5. Der RadiusDesk-Adapter synchronisiert das ausgewählte Profil in permanent_users, devices und die zugehörigen RADIUS-Tabellen. MAC/PAP verwendet die normalisierte MAC als Identität; Secrets und personenbezogene Tabellenzeilen gehören nicht ins Wiki.
  6. Das Portal stellt einen Hintergrund-Disconnect an die konfigurierten Aruba-Ziele ein. Erst die folgende RADIUS-Anmeldung übernimmt die neue Zuteilung.
  7. Aruba setzt Rolle und VLAN; im Ziel-VLAN muss DHCP abgeschlossen werden. Anschließend Internetzugriff in einem neuen Browser-Tab prüfen.

Ein bereits geöffnetes Portal-Fenster kann veralteten Inhalt behalten. Windows „Aktion erforderlich“ beziehungsweise die Weltkugel unterscheiden nicht zuverlässig zwischen fehlendem DHCP, noch aktiver Captive-Rolle und einer noch nicht aktualisierten Internetprüfung.

Komponenten und Netze

Komponente Verifizierter Standort/Endpoint Funktion
SGJ UDM Pro 10.128.0.1 VLAN-Gateways, DHCP, Firewall; API /proxy/network
Aruba Instant VC 10.128.16.2 SGJ-Cluster, WLAN-Konfiguration
Aruba Conductor 10.128.16.204 Gezielter erfolgreicher Disconnect-Test
Gemeinsames Portal Proxmox pve 10.0.0.220, CT128, 10.222.40.52 M365/Graph, RadiusDesk-Sync, CoA
Gemeinsamer RADIUS VM601, 10.222.40.36, radius.lanstyle.de RadiusDesk/FreeRADIUS, RadSec
Reverse Proxy 10.222.50.10 HTTPS-Portal zum Backend
Wiki CT253, 10.222.40.32, wiki.lanstyle.de Git/MkDocs, bestehender Auto-Deploy
VLAN Verwendung Netz Status
999 Ausgangs-/Registrierungsnetz, UDM-Name Blackhole 10.128.255.0/24, Gateway .1 DHCP .6–.254; aktuelles SGJ-Default-VLAN
100 SGJ-PreAuth 10.9.0.0/24 Vorhanden, aber nicht das aktive SSID-Default-VLAN
10 Schüler und iPads 10.3.0.0/16 DHCP aktiv; erfolgreicher Test in VLAN10
30 Lehrer und Trainer 10.2.0.0/20 DHCP aktiv; Profile live bestätigt, kein neuer Endgerätetest dokumentiert
8 Switchmanagement — Auf WIFI-Uplinks getaggt
16 AP-Management — AP-Ports native16; durch Reparatur nicht geändert

RADIUS, CoA und sichere Betriebszugänge

Aruba Instant AP515, AOS8.13.1.1, Cluster SGJ_Cluster. Primärer WLAN-Authserver bleibt Lanstyle Radius: RadSec zu radius.lanstyle.de über TLS2083. RADIUS-Auth/Accounting-Konfiguration nennt 1812/1813. Die zusätzliche CoA-Konfiguration ersetzt diesen Authserver nicht.

Separater Aruba-Authserver Lanstyle Onboarding CoA: Quell-IP 10.222.40.52, rfc3576 aktiviert, Secret nur aus Vault. Portal-Ziele: 10.128.16.2 und 10.128.16.204, UDP3799. Beidseitige Firewall erlaubt Portalquelle zum SGJ-AP-Netz 10.128.16.0/24. SGJ-Policy-ID 6a2871dde98fdac9e83f644b, Lanstyle-Policy-ID 6a287ee35d6775879ec316a8.

CredentialRefs: sgj-unifi-network-api, sgj-aruba-wlan-admin, sgj-aruba-onboarding-coa. Shared-DB-Zugang gehört zum kanonischen gemeinsamen System lanstyle-radiusdesk, nicht zu einer Kopie des Dienstes pro Kunde. Secrets ausschließlich per lanstyle-vault run injizieren. UDM nutzt X-API-Key; das gebundene Feld heißt historisch SGJ_UNIFI_PASSWORD, enthält aber den API-Key. Controller-SSH nutzt die gebundene Passwortanmeldung; die Aruba-CX-Switches werden separat per vorhandenem SSH-Key administriert.

Behobene Fehler und Rückwege am 16.09.2026

1. Keine IP durch Native-VLAN-Mismatch

Core 10.128.8.10 lag2 ↔ DV2-WIFI 10.128.8.12 lag1 und Core lag4 ↔ DV3-WIFI 10.128.8.132 lag1: Core native999, Gegenstellen zuvor native1. Die Gateway-MAC wurde auf den WIFI-Switches dadurch in VLAN1 gelernt.

Nur beide WIFI-lag1 wurden nacheinander auf vlan trunk native 999 gestellt, jeweils Management/APs und MAC-Lernen geprüft, anschließend write memory und Startup-Konfiguration geprüft. Allowed-VLANs blieben all. AP-Ports bleiben native16. Vier geprüfte APs blieben erreichbar (je 3/3 Antworten, kein Paketverlust); LLDP/1G-Links stabil. DV4/DV5 hatten bereits übereinstimmend native999.

Rückweg nur bei Regression und nach Prüfung neuer Änderungen: betroffenen lag1 auf native1 zurückstellen und speichern. Dies stellt den fehlerhaften Prestate wieder her.

2. Weiße M365-Anmeldeseite durch Regelreihenfolge

Die aktive pauschale BLOCK-Policy 6a286d25e98fdac9e83ebe67 bei index10002 verdeckte die bestehende Microsoft-Domainfreigabe bei index30003. Nur diese frühere BLOCK-Policy wurde deaktiviert. Domain-ALLOW obj_6a286ef9e98fdac9e83f1738_1 und Default-BLOCK _2 bei index30004 blieben aktiv. Es wurde keine allgemeine Internetfreigabe eingerichtet.

Vorhandene Domainliste: microsoftonline.com, microsoftonline-p.com, login.microsoft.com, graph.microsoft.com, msftauth.net, msftauthimages.net, msauth.net, msauthimages.net, auth.microsoft.com, msftidentity.com, msidentity.com, windows.net, activedirectory.windowsazure.com, cloud.microsoft, static.microsoft, usercontent.microsoft, enterpriseregistration.windows.net, live.com, gfx.ms, lanstyle.de, wlan-onboarding.lanstyle.de.

Vier ältere feste IP-Netze deckten die Auth-CDNs nicht vollständig ab. Portal-Redirect und externe Microsoft-Antwort waren separat erfolgreich; nach der Regeländerung gelang die Benutzerregistrierung. Rückweg: nur die genannte Policy wieder enabled=true setzen, unveränderte Domain-/Defaultregeln erneut prüfen.

3. Registrierung ohne anschließende Freigabe

Audit zeigte erfolgreiche Registrierung und RadiusDesk-Sync, aber fünf CoA-Timeouts je Ziel. Der dedizierte Aruba-CoA-Authserver fehlte. Dienst, DB-Tunnel, Route und Firewall waren vorhanden. Wiederhergestellt wurde ausschließlich Lanstyle Onboarding CoA mit Portal-IP, gebundenem Secret und rfc3576; commit apply, danach frischer Read.

Ein attributloser Test war erfolglos und ist ausdrücklich kein positiver Nachweis. Der nachfolgende gezielte Disconnect-Request (Code40) verwendete MAC als User-Name und Calling-Station-Id. Antwort vom Conductor: Disconnect-ACK (Code41), Response-Authenticator geprüft. Danach authentifizierter Client in VLAN10 mit abgeschlossenem DHCP. Personenbezogene MAC/IP/UPN werden hier nicht veröffentlicht.

Rückweg: ausschließlich neu angelegten Authserver entfernen (no wlan auth-server "Lanstyle Onboarding CoA", commit apply) und Abwesenheit prüfen; vorher spätere Änderungen ausschließen. Primärer Authserver bleibt unverändert. Der erfolgreiche einzelne Disconnect bedarf keiner Rücktrennung.

Wiederkehrende Diagnose

  1. Kunden-/Systembindung laden; Ziel-MAC nur für gezielte Abfragen verwenden, nicht in dauerhaftes Wiki übernehmen.
  2. Aruba show clients debug: VLAN, Rolle, Authentifizierung und DHCP-Status prüfen. APIPA/Discovering → zuerst DHCP/L2, nicht erneut M365 registrieren.
  3. Bei VLAN999 ohne DHCP: UDM-Netzstatus, WIFI-lag1/Core-Gegenport, LLDP und Gateway-MAC-Lernen prüfen. AP-Management VLAN16 getrennt betrachten.
  4. Bei weißer Anmeldung: Portal-Redirect, DNS, Microsoft/CDN-Ziele und Firewallreihenfolge prüfen. Keine Cookies/OAuth-State protokollieren.
  5. Bei „Gerät registriert“, aber Captive-Rolle: /opt/wlan-onboarding/audit.log gezielt auf registration_success, RadiusDesk-Sync, coa_queued und coa_result prüfen. Dienste wlan-onboarding und wlan-onboarding-radiusdesk-tunnel.service; Health lokal8088/healthz.
  6. Aruba show ap debug rfc3576-radius-statistics, CoA-Quell-IP und Zielclient prüfen. Bei NAK/Timeout Identifier MAC versus UPN abgleichen. Nicht blind weitere Clients trennen.
  7. Nach Neuanmeldung Rolle/VLAN/DHCP am Controller und tatsächlichen Internetzugriff prüfen. RADIUS-Gesamtzähler allein sind kein Nachweis für den einzelnen Client.

Keine vollständigen Controllerkonfigurationen, RADIUS-Server-Dumps, Tokens oder Secrets in Ausgaben, Tickets oder Wiki kopieren. Änderungen benötigen frischen Objekt-Prestate, eng begrenzten Apply, Read-after-write und Rückweg.

Offene Prüfungen und bewusste Grenzen

  • Neue Registrierung einschließlich automatischem Hintergrund-CoA vollständig testen; UPN/MAC-Differenz bei den Session-Attributen gezielt prüfen.
  • Lehrer-VLAN30 sowie Trainer-/iPad-Profilwirkung wurden in diesem Meilenstein nicht neu am Endgerät getestet.
  • Trainer-/iPad-Gruppenmapping ist nicht eingerichtet; dafür fachliche Gruppen und gewünschte Priorität festlegen, bevor etwas geändert wird.
  • Beobachtete regelmäßige RadSec-Servertrennungen mit Wiederverbindung wurden nicht als Ursache dieses Fehlers bewiesen und nicht als behoben erklärt.
  • MAC-basierte Registrierung ist keine Geräte-Zertifikatsbindung; die offene SSID stellt keine WPA-Enterprise-Funkverschlüsselung bereit. Dies beschreibt den Ist-Stand, kein separat abgenommenes Sicherheitszielbild.

Quellen, Nachweise und Pflege

Fachlich autoritativ sind die Live-Konfigurationen von SGJ-Aruba/UDM, [sites.sgj] auf CT128 und die auf SGJ begrenzte RadiusDesk-Profilabfrage. Dauerhafte Quellen und redigierte Nachweise liegen im SGJ Customer-Ops-Repository.

Wiki-Veröffentlichung: bestehendes Repository vinc32/infrastruktur-wiki, MkDocs Strict Build, normaler Git-Push, vorhandener wiki-auto-deploy.service auf CT253 mit Webroot-Backup. Rückweg der Dokumentation: betroffene Commits nach Prüfung neuer Änderungen normal revertieren und über denselben Deploy-Weg publizieren; kein Force-Push. Das Wiki enthält keine Zugangsdaten oder personenbezogenen Testbilder. Bei künftigen Änderungen Live-Stand, Customer-Ops, Wiki und Operational Knowledge gemeinsam nachziehen.