Serie „Migration zu Windows Server 2025“ – Migration der NPS-Server

Dieser Eintrag gehört zu meiner Serie „Migration zu Windows Server 2025„. In dieser möchte ich euch die Aktualisierung meiner Server-Infrastruktur von 2019 auf 2025 dokumentieren. Es ist eine lebendige Welt von Systemen, die mir wichtig sind. Mit realen Anforderungen und Bedingungen werde ich alle Arbeitsschritte erläutern.

In diesem Beitrag zeige ich euch, wie ich meine beiden Network Policy Server (NPS) von Windows Server 2019 auf Windows Server 2025 umstelle.

Planung

IST-Situation

Ich nutze für meine WLAN-Anmeldung im Clientnetz eine Radius-Authentifizierung. Dabei müssen die Benutzer über ein Benutzerzertifikat meiner internen Zertifizierungsstelle verfügen. Dieses wird zur Anmeldung an den 3 Accesspoints verwendet. Die APs leiten die Anfrage an einen meiner beiden Network Policy Services Server (NPS) weiter, welche dann die Anmeldung bzw. das Clientzertifikat überprüfen. Ich nutze hier 2 NPS-Server für eine Ausfallsicherheit.

Meine Accesspoints konnten mit der Firmware nur eine IP-Adresse für NPS/Radius verwenden. Daher habe ich beide NPS-Server in einem Network Load Balancing Cluster verbunden. Die APs schicken ihre Anfrage an die Cluster-IP und der NLB-Service verteilt die Anfragen dann auf die beiden NPS-Server. Die Konfiguration meiner WLAN-APs übernimmt mein Omada-Controller. Das sieht als Schema dann so aus:

Das Logging der Anmeldungen bzw. der Anmeldeversuche wird je NPS lokal im Security Eventlog vorgenommen. Mein Elastic Agent leitet die Events dann in mein Elastic SIEM weiter.

SOLL-Situation

Meine NPS-Lösung funktioniert soweit. Nur der NLB stört mich. Diese Funktion vom Windows Server war schon immer etwas problematisch und mit Windows Server 2025 wurde „Network Load Balancing“ auch noch als „deprecated“ geflaggt. Da meine Accesspoints seit einem Firmware-Update nun mehr als einen Radius-Server ansprechen können, kann ich beide NPS ohne einen NLB betreiben. Im Schema sieht das dann so aus:

Insgesamt bin ich mit meiner NPS-Implementierung zufrieden. Daher möchte ich an dem Service keine Veränderungen vornehmen.

Migrationsszenario

Für die Umstellung auf Windows Server 2025 sind diese Migrationsszenarien denkbar

• Wipe & Load: Ich habe eine hochverfügbare Lösung, da bereits 2 Server im Einsatz sind. Ich kann also zu jeder Zeit einen der beiden entfernen und durch einen neuen ersetzen.
• Side-by-Side: Ich könnte aber auch 2 neue Server neben die alten Server stellen, dort den Service neu aufbauen und dann in den Accesspoints die Radius-Konfiguration anpassen. Danach könnte ich die alten Server entfernen.

Side-by-Side benötigt mehr Ressourcen während der Migration, da ich dann 3 bzw.4 statt 2 Server gleichzeitig betreiben müsste. Zudem müsste ich die Server anders benennen. Da ich auch bei Wipe & Load eine Ausfallsicherheit und eine Rollback-Option habe und zusätzlich die Namen übernehmen kann (das spart mir Anpassungsaufwand in der Dokumentation), nehme ich dieses Migrationsszenario.

Vorbereitung

Berechtigungen

Wie immer benötige ich für die Analyse und den Umbau für meine Kennung die passenden Rechte aus meinem Active Directory. Diese vergebe ich mit meiner PAM-Lösung an meine T1-Kennung:

Review

Nun starte ich meine Review-Tour durch die beiden Server WS-NPS1 und WS-NPS2. Ich beginne mit den installierten Rollen und Features. Hier sind nur 2 relevant:

Auf WS-NPS1 sind noch einige Anwendungen installiert. Java war ursprünglich mal für die Anwendung „omada“ erforderlich. Diese Software von TP-Link ist meine Netzwerkverwaltung gewesen. Mittlerweile nutze ich aber einen Hardware-Controller für meine TP-Link-Switches und Accesspoints. Daher brauche ich diese Anwendung nicht auf dem neuen Server installieren. Der veraltete Wireshark benötigte die anderen Anwendungen. Somit ist also abgesehen vom Edge und dem LAPS nichts weiter erforderlich. Auf dem anderen Server ist nur LAPS installiert.

In der Aufgabenplanung habe ich einen ScriptTask gefunden. Dieser kopiert die Konfiguration vom WS-NPS1 auf WS-NPS2. Damit sind beide immer identisch eingerichtet. Diese Aufgabe exportiere ich in ein Migrationsverzeichnis:

Der Task nutzt ein Script, das in einer Ordnerstruktur c:\admin liegt:

Hier sind auch die zusätzlichen NPS-Logs enthalten:

Ich kopiere das gesamte Verzeichnis c:\admin von beiden Servern in mein AdminShare auf dem Fileserver.

Nun sichere ich noch einmal die Konfiguration der beiden NPS-Server. Mit meinem ScriptTask ist das eigentlich nicht notwendig. Aber so könntet ihr eure Migration ausführen:

Die geheimen Schlüssel werden in der Sicherungsdatei im Klartext stehen. Daher dürfen die Exportdateien nicht offen abgelegt werden!

Die NLB-Konfiguration muss ich nicht sichern. Aber hier gibt es noch Informationen, die ich später bei der Bereinigung benötige:

Mehr gibt es auf den beiden Servern nicht zu finden.

Aufbau der neuen VMs

Daher melke ich mich nun auf meinen beiden Hyper-V-Servern an und erstelle 2 neue VMs mit meinem GoldenImage für Windows Server 2025. Die VMs haben keine besonderen Anforderungen in meiner Umgebung. Die Anlage der VMs nehme ich heute mal mit der PowerShell vor:

$VMName = "WS-NPS1"
$VMPath = "V:\Hyper-V\PROD"

Copy-Item `
        -Path "V:\Base\win2025-2501.vhdx" `
        -Destination "$VMPath\$VMName\Virtual Hard Disks\HDD0-System.vhdx"

$NewVM = New-VM `
        -Name               "$VMName" `
        -MemoryStartupBytes 2GB `
        -SwitchName         "VLANs" `
        -Path               "$VMPath" `
        -Generation         2 `
        -VHDPath            "$VMPath\$VMName\Virtual Hard Disks\HDD0-System.vhdx"

$NewVM | Set-VM `
        -ProcessorCount 4 `
        -MemoryMinimumBytes 1GB `
        -MemoryMaximumBytes 3GB `
        -DynamicMemory `
        -AutomaticStartAction "Start" `
        -AutomaticStartDelay  30 `
        -AutomaticStopAction  "ShutDown"

$NewVM |
    Get-VMNetworkAdapter |
        Set-VMNetworkAdapterVlan  -Access -VlanId 99

$NewVM |
    Get-VMIntegrationService | 
        Enable-VMIntegrationService

Auf beiden VMs schließe ich die Betriebssystembereitstellung ab und melde mich lokal an. Die Netzwerkkonfiguration zeigt auf das VLAN 99, das es bei mir nicht gibt. Daher kann ich den Servern die gleichen Namen und IP-Adressen vergeben, wie den noch laufenden Windows Server 2019:

Und dann installiere ich noch die Rolle Network Policy Server und das Feature Windows Server Backup. Das spart mir nachher beim Schwenk einige Minuten:

Bisher (zumindest bis Windows Server 2019) musste man immer selber die Ausnahmen in der Windows Firewall für die beiden NPS-Ports UDP 1812 und 1813 setzen. Das war immer ein beliebter Stolperstein bei der Bereitstellung. Mit Windows Server 2025 scheint dieser Fehler beim Setup behoben zu sein. Die Regeln wurden bei der Rolleninstallation angelegt:

Migration

Umstellung auf 2 Radius-Server im Omada-Controller

Aktuell nutzen meine Accesspoints noch den Zugriff über den NLB und seiner IP-Adresse. Mit dem Austausch der beiden Server wird das nicht mehr funktionieren. Daher stelle ich nun auf die beiden dedizierten IP-Adressen der NPS-Server um. Die Einstellung des Radius-Profiles findet man über diesen Pfad:

Hier nutze ich den Schalter „add new authentication server“ und füge einen zweiten Radius-Server ein. Die IP des ersten ändere ich von der 192.168.100.24 (NLB-ClusterIP) auf die des Servers WS-NPS1. Beide Server nutzen das gleiche Secret. Daher kopiere ich dieses vom ersten Eintrag in den zweiten:

Das Radius-Profil hängt direkt an meinen WLAN-Konfigurationen dran. Daher wird diese neue Einstellung direkt auf meine Accesspoints übertragen:

Nun teste ich die Anmeldung an einem meiner Clients und kontrolliere das Ergebnis in meinem Elastic SIEM. Hier kommen direkt neue Events rein und Zugriff auf das Netzwerk habe ich auch:

Damit sind nun alle Voraussetzungen für den Serveraustausch geschaffen.

Maintenance aktivieren

In meinem PRTG setze ich die beiden alten NPS-Server auf pausiert. So erspare ich mir unnötige Fehlalarme an meinem Handy:

Austausch des Servers WS-NPS1

Ich beginne mit dem ersten Server und fahre diesen kontrolliert herunter. Dann nehme ich die VLAN-Konfiguration des neuen Servers raus. Ab jetzt ist er im Netzwerk erreichbar:

Mit meiner T3-Kennung nehme ich den Server in mein Active Directory auf. Da er den gleichen Namen wie der alte Server hat, übernimmt er das Computerkonto:

Jetzt kann ich mich mit meiner T1-Kennung über RDP verbinden und die Konfiguration des NPS-Servers importieren:

In den Eigenschaften des NPS (lokal) muss ich nun noch die Ports umstellen. Hier stand noch die IP des NLB drin:

Die Konfiguration ist nun wieder vorhanden:

Das lokale Accounting nutzt den Pfad c:\admin\Radius\Logfiles. Daher kopiere ich noch schnell die Sicherung von meinem Migrationsverzeichnis nach C:\

Final starte ich nun den Service:

Testphase

Problem: Zertifikat fehlt

Ich starte meinen WLAN-Adapter neu und hoffe, dass mich mein Accesspoint über den neuen WS-NPS1 authentifiziert. Dieses Mal kann ich mich aber nicht verbinden! Also suche ich nach der Ursache. Im Eventlog des neuen Servers werde ich fündig:

Die Authentifizierung meines Clients wurde abgelehnt. Er hat keine EAP-Aushandlung gestartet (das erkennt man an dem Strich beim EAP-Typ). Und das kann nur eine Ursache haben: Ich nutze 802.1x mit gegenseitiger Authentifizierung: Zuerst prüft mein Client das Serverzertifikat des NPS-Servers und dann sendet er seine Anmeldung. Und dem neuen Server habe ich noch kein Zertifikat mit dem Verwendungszweck „ServerAuthentication“ installiert. Das sieht man auch gut in der Verwaltungskonsole:

Also starte ich mit certlm.msc die Zertifikatkonsole des Computers und frage ein neues Zertifikat bei meiner CA an:

Hier nutze ich die Vorlage für Webserverzertifikate:

Das neue Serverzertifikat binde ich nun an die Authentifizierungsmethode:

Problem: fehlende AD-Integration

Mit dem Zertifikat auf dem NPS-Server versuche ich es erneut. Nun erhalte ich einen anderen Fehler in dem Eventlog:

Der Ursachencode 16 im Event 6273 zeigt an, dass der NPS-Server den Computer im Active Directory nicht finden kann. Hier fehlt also die Registrierung des NPS im Active Directory. Diese kann mit einem Rechtsklick in der Konsole gestartet werden. Dafür ist ein Benutzerkonto mit Domain Admin Rechten und lokalen Adminrechten erforderlich. Daher statte ich meine T3-Kennung mit diesen Rechten über mein PAM-Tool aus, melde mich damit an und starte den Assistenten:

Problem: Zugriff verweigert

Ein neuer Anmeldeversuch an meinem WLAN-Accesspoint scheitert wieder mit der gleichen Meldung. Spätestens jetzt muss ich die Reißleine ziehen, um nicht noch mehr Clients am WLAN-Zugriff zu hindern. Ich konfiguriere den 2. alten NPS-Server im Omada-Controller als Radius-Server:

Zusätzlich konfiguriere ich noch die NLB-Cluster-IP im alten NPS raus und trage dafür seine lokale IP-Adresse ein:

TroubleShooting mit WireShark

Da die Ereignisanzeige immer noch den Fehler 16 im Event 6273 anzeigt und ich hier aber nicht weiter komme, möchte ich einen WireShark-Mitschnitt einer Radius-Anmeldung aufzeichnen. Dafür will ich aber keinen WireShark auf meinem NPS-Server installieren. WireShark habe ich auf meinen DHCP-Servern installiert. Mit diesen und einer Portspiegelung auf Hyper-V-Ebene kann ich den Traffic für die Aufzeichnung kopieren. Dafür stelle ich die Netzwerkkarte des NPS-Servers als Quelle ein:

Die Netzwerkkarte des DHCP-Servers WS-NET1 auf dem gleichen Hyper-V-Host stelle ich als Ziel ein:

In größeren Umgebungen würde ich nun im Omada-Controller ein weiteres WLAN anlegen und ein Radius-Profil konfigurieren, dass nur den neuen NPS-Server verwendet. Dann könnte ich einen Testclient mit diesem WLAN verbinden und troubleshooten, während alle normalen Verbindungen über den alten NPS laufen. Das kann ich mir aber sparen, da aktuell keine Clients in meinem Netzwerk auf WLAN angewiesen sind (Wartungsfenster). Also stelle ich das Radius-Profil wieder auf die IP des neuen NPS-Servers ein:

Auf meinem DHCP-Server WS-NET1 starte ich WireShark und filtere nach UDP 1812 für NPS-Traffic. Hier sehe ich den Verbindungsversuch meines Clients:

Diese werden nach einigen Paketen vom NPS-Server mit einem Access Denied abgelehnt. Der Client meldet sich aber korrekt:

Irgendwas übersehe ich hier…

TroubleShooting: GPO

Vielleicht liegt es an meiner neuen Security Richtlinie, die nur für die neuen Windows Server 2025 wirkt? Diese enthält einige TLS/SSL-Konfigurationen. Eventuell stört sich der Server daran? Das hätte aber ebenfalls einige Events generieren müssen…

Einfacher ist es hier, die GPO für den neuen Server einfach testweise auszuschließen. Das geht in den erweiterten Delegierungen. Hier kann ich den Server hinterlegen und die Richtlinienanwendung deaktivieren:

Nach der AD-Replikation starte ich ein gpupdate auf dem NPS-Server und starte ihn dann anschließend neu. Nun versuche ich eine erneute Verbindung mit meinem WLAN – und es ist erfolgreich!

Es scheint die GPO zu sein. Ich sichere mich aber durch einen weiteren Test ab und entferne den Filter aus der GPO-Delegierung wieder. Nach einem gpupdate starte ich den Server wieder neu und teste die WLAN-Anmeldung: Und sie funktioniert immer noch – mit der Security GPO!

Offenbar hat wohl nur ein Neustart gefehlt. Und jetzt kommt mir die Lösung:

• Der Fehler hat sich nach der AD-Autorisierung nicht verändert!
• Also war die Autorisierung nicht vollständig. In dieser Dokumentation hole ich mir das Bild noch einmal ran. Der letzte Satz zeigt an, dass es im Active Directory eine Gruppe gibt, in welcher der Computer Mitglied sein muss:
  
• Der Computer ist im AD Mitglied in der Gruppe geworden:
  
• Und was braucht eine neue Gruppenmitgliedschaft? Richtig: einen Neustart…

Durch meinen Test mit der GPO habe ich den Neustart mit ausgeführt. Daher eben auch die Gegenprobe durch die Reaktivierung der Richtlinie. 😉

Austausch des Servers WS-NPS2

Nachdem nun alles funktioniert und der Omada-Controller bereits alle Anmeldungen an den neuen NPS-Server sendet, kann ich den anderen Server austauschen. Das Vorgehen dabei ist gleich – abgesehen von den Fehlern vom ersten Lauf:

• Ich fahre den alten Server herunter.
• Dann entferne ich das falsche VLAN vom Netzwerkadapter des neuen Servers.
• Diesen nehme ich nun mit dem gleichen Namen und der gleichen IP in mein Active Directory auf und starte ihn neu.
• Danach melde ich mich als T3-Admin mit lokalen Adminrechten und als Domain Admin an und finalisiere die Konfiguration:
  • Ich importiere die NPS-Konfiguration des alten Servers, die ich im Migrationsordner gespeichert hatte:
    
  • Dann frage ich bei meiner PKI ein Webserverzertifikat für den Server an:
    
  • Das Zertifikat hinterlege ich in den beiden Netzwerkrichtlinien:
    
  • Dazu kopiere ich den Ordner C:\Admin wieder rein:
    
  • Der Server wird nun noch im Active Directory autorisiert:
    
  • Und zum Abschluss wird er neugestartet.

Testphase

Für einen Testlauf stelle ich meinen Radius-Server im Omada-Controller auf die IP-Adresse des 2. NPS-Servers ein. Dann nehme ich einen Client und verbinde mich mit dem WLAN:

Ich kontrolliere die Verbindung im Eventlog. Hier finde ich das passende Event 6272 🙂

Finale Omada-Konfiguration

Nachdem nun beide NPS-Server einzeln funktional arbeiten, stelle ich im Omada-Controller das Radius-Profil auf beide Server um. Primär soll immer der WS-NPS1 verwendet werden. Erst, wenn dieser ausfällt, wird WS-NPS2 verwendet. Das Passwort für die Authentisierung zwischen den Accesspoints als Radius-Clients und den Radius-Servern (NPS) kopiere ich aus dem oberen Feld:

Und ein letztes Mal verbinde ich meinen Testclient mit dem WLAN neu: es funktioniert! 🙂

Nacharbeiten

Monitoring konfigurieren

Auf beiden Servern installiere ich meine Scriptsammlung für meinen PRTG-Remotezugriff über PowerShell JEA:

Im PRTG kommen nun wieder Daten an. Da die Datensicherung noch fehlt, meldet mein Base-Sensor weiter einen Fehler. Den lasse ich bestätigt:

Konfiguration der Datensicherung

Die Datensicherung läuft wieder über meinen Sicherungstask. Diesen importiere ich auf beiden Servern:

Den ServiceAccount (ein gMSA) muss ich separat einrichten. Da ich sein Passwort nicht kenne, stelle ich auf „nur ausführen, wenn der Benutzer angemeldet ist“ um:

Für die Integration des gMSA-Accounts in die Aufgaben statte ich meinen T3-Admin mit den passenden Rechten aus: Er muss Domain Admin sein, sich auf den DCs anmelden können und er benötigt Adminrechte auf den NPS-Servern:

So ausgestattet melde ich mich auf dem Domain Controller an und starte die Verwaltungskonsole für AD-User und Computer. Hier ändere ich den Wert im Feld msDS-SupportedEncryptionTypes von 28 auf 24. Den Hintergrund dazu habe ich hier erklärt: gMSA TroubleShooting unter Windows Server 2025

Und zuletzt starte ich auf dem DC mein Script „gMSA-Admin„. Hier verbinde ich mich remote mit den beiden Servern und konfiguriere die Sicherungsaufgabe für die gMSA-Nutzung:

Die Datensicherung wird automatisch in der Nacht durchgeführt. Diese warte ich einfach ab.

Updatekonfiguration

Im WSUS kontrolliere ich die Gruppenzugehörigkeiten beider Server. Diese passt immer noch, da ich die Namen der Server beibehalten habe:

Aber der WS-NPS2 wird mit einem Fehler angezeigt. Ich kontrolliere die Ereignisse im WSUS. Hier gab es wohl Probleme mit einem Update vom Defender. Das könnte mit dem Neustart nach der NPS-Einrichtung zu tun haben:

Ich suche erneut auf dem Server nach Updates:

Ein wuauclt /reportnow später ist der Fehler behoben:

Sonstige Bereinigungen

Im Hyper-V entferne ich die beiden alten VMs und ihre VHDX-Dateien.

Dann bleibt noch die alte IP-Adresse des NLB-Clusters über. Diese ist in meiner Netbox (mein IP Adressverwaltungstool) hinterlegt und muss bereinigt werden. Sie ist dem NIC-1-Adapter des WS-NPS1 zugeordnet:

Ebenso gibt es den Platzhalter „NIC-2“ nicht mehr. Den lösche ich ebenfalls raus. Über bleibt eine saubere WS-NPS1-VM:

Zusätzlich lösche ich die IP noch im DNS. Der Reverse-Lookup-Record wird dabei gleich mit entfernt:

Kontrolle im SIEM

Beide Server sollten sich zwischenzeitlich im Elastic SIEM registriert haben. Der dafür erforderliche Agent wird mit einer Gruppenrichtlinie und einer geplanten Aufgabe für einen Scriptaufruf ausgebracht. Im Fleet – dem zentralen Agent Management – finde ich die beiden Server jeweils mit einem alten und einem neuen Eintrag:

Die alten Einträge werden markiert und gelöscht:

Abschluss

Damit sind nun alle Arbeitsschritte erledigt und meine beiden NPS-Server laufen mit Windows Server 2025. Der Weg war etwas holprig und daher musste ich einige Zeit in das TroubleShooting stecken. Aber für meinen Block ist das auch fein, denn so könnt ihr auch von mir den Umgang mit Problemsituationen lernen. 😉

Die Übersichtsseite zum meinem Migrationsprojekt findet ihr hier: Migration zu Windows Server 2025

Stay tuned!