Probleem met NPS na DC inplace upgrade

[Pharos1985]

All,

Klein mysterie voorleggen.
Ik heb een server 2016 die dienst doet als CA/NPS én DC (enige DC in de domain en forest).
Vorige week die server inplace upgrade gedaan naar server 2022.
Direct erna issues met NPS: die gebruiken we voor wifi authenticatie en voor AOVPN icm RRAS.
WiFi en RRAS werken nietmeer en NPS geeft error code 16 aan.
30uur op getroubleshoot: nietmeer werkend gekregen. Ook nieuwe NPS uitgerold en onze AP's en RRAS naar de nieuwe NPS laten verwijzen: zelfde issue.
Alle nieuwe patches op de server(s) zijn applied (om de issues met NPS in May2022 uit te sluiten).
Nietmeer werkend te krijgen.

So far so good. Vanuit een Veeam backup heb ik een restore gedaan van de server naar een backup van net voor de inplace upgrade. Dat is goed gegaan (altijd spannend met AD), echter: NPS blijft zelfde issue vertonen.
Dat vind ik echt raar: door middel van de Veeam restore zou ik verwachten dat alles weer is zoals ervoor.

Er is op onze wifi & RRAS infrastructuur al zeker 4 maanden geen aanpassing meer gebeurd.

Ticket is nu open bij MS Premier Support (maar het niveau daar is de laatste 2 jaar enorm achteruit gegaan heb ik de indruk).

Iemand enig idee in dit mysterie?

Rare is: 80% van onze clients kon nietmeer verbinden, maar een 20% ongeveer weer wel. Ik heb proberen zoeken wat het verschil is tussen die 2 groepen van clients: ik kan er geen vinden. Zijn er ook met exact dezelde Windows versie als mensen in de andere groep.

Vraag is of dit nu een issue is met onze NPS of eerder met de CA.

Thanks iig!

[Endpoint]

Welke events staan er in je eventlog?

[MAX3400]

30uur op getroubleshoot

Dan zou een korte samenvatting van wat je wel/niet hebt gecontroleerd, opgetuigd, afgetuigd, aangepast etc wel handig zijn.

Welke authentication methods heb je nu nieuw/oud draaien? Welke certificaten hangen daar aan? Werkt het (ook niet) als je NPS even uitbreidt naar je wired LAN en een laptop direct in de switch naar de server prikt? Is de NPS-server nog wel "geregistreerd" in ADDS als NPS-server of zijn daar mogelijk attributes / serials weggevallen? Zijn je subnets nog wel correct geconfigureerd (letterlijk op alle vlakken / consoles die iets met networking doen voor NPS)?

/Edit: aangezien het de enige DC is, mag ik aannemen dat je ook ALLE procedures gevolgd hebt van Veeam en van Microsoft voor een authoritative restore; indien/waar van toepassing?

[ Voor 12% gewijzigd door MAX3400 op 10-08-2022 09:11 ]

[Pharos1985]

Even aanvullen wat ik geprobeerd:
- Ik heb verschillende nieuwe NPS's opgezet (2 in totaal: 1 op server 2019 met een ISO van 1 jaar geleden, 1 op server 2022 met een recente ISO). Zowel NPS opgezet met export configuration als compleet van scratch de NPS configuratie gedaan.
- De certs die de PKI uitgegegeven heeft revoked voor een client en opnieuw certs aangevraagd.
- Een WIndows machine van scratch opgezet als testmachine.
- EAP Smartcard or other certificate heb ik staan in NPS op de networking policy.
- Subnets: waarom is dat hier zo belangrijk? De RADIUS clients en dergelijke staan goed: de RADIUS requests komen van subnets/single IP's die als RADIUS clients geconfigureerd staan in de NPS.
- NPS is geregistreerd in de ADDS, hoewel dat hier eigenlijk minder uitmaakt gezien het vinkje aanstaat dat de NPS policies de dial in settings van de user in AD overrulen.

De certificates voor zowel de NPS als de clients zouden normaal goed moeten zijn: dat zijn templates die ik een half jaar geleden aangemaakt heb en daar is al zeker nietsmeer aan gewijzigd. Ook certs blijven 2 jaar geldig: we hebben maar een 120-tal users: dus die certs zijn nog nooit opnieuw aangevraagd geweest gezien die PKI nogmaar een 6-tal maand draait.

Qua AD restore: ik heb geen authoritative restore uitgevoerd (kan dat nog doen natuurlijk). De AD draait na de restore goed en ik zie geen errors nergens. Waarom zou ik in deze situatie een authoritative restore moeten doen? USN rollback? > er is maar 1 DC.
Ik snap niet goed waarom ik in deze situatie een specifieke AD restore zou moeten uitvoeren.

Bedankt alvast iedereen!

[Brahiewahiewa]

Pharos1985 schreef op woensdag 10 augustus 2022 @ 16:02:
... er is maar 1 DC...

Terug naar de tekentafel dan maar?

[Pharos1985]

Dat is idd een andere discussie, maar ja daar gaat het hier eigenlijk niet over. We hebben die omgeving geërfd en zijn stuk voor stuk aan het integreren/migreren

[Joenino]

Waarom is er niet gekozen om gewoon 2 nieuwe DC's op basis van 2022 erbij te zetten en oude zijn rollen te ontnemen? In dit geval wordt er door de multi role die die machine heeft zo veel gewijzigd dat het zoeken is naar een spelt in een hooiberg. Restoren wilt niet altijd zeggen dat alles weer functioneert als er voor, vaak zat ervaren dat overige servers het niet meer snapte waar AD 0 meldingen gaf. Vandaar de comment over heb je wel authoritative restore gedaan.

Maar goed dat is een andere discussie.

Kan je vanuit je WiFi ook authenticatie\radius tests doen? Misschien geeft dat een helpvolle melding.

NPS is niks meer als een dom doorgeef luik naar de juiste autorisatieservers in dit geval je DC mits er voldaan wordt aan een x aantal voorwaarde vanaf de client \login.

Geeft je CA ook certificaten af voor WiFi? Heb je bv al geprobeerd met een selfsigned certificaat te werken richting je WiFi dus een self signed hangen aan je eap?

Mocht dat werken heb je in ieder geval een werkende (tijdelijke) oplossing en geeft je tijd om er goed in te duiken zonder dat de klant continu in je nek staat te hijgen.

Edit* Las je bericht nog eens goed door en je zegt Windows clients... Wel overal netwerk vergeten gedaan dus uit de bekende netwerken gegooit? Vaak blijft de client een oud certificaat of connectie gegevens profiel gebruiken en werkt het wel weer door het bekende netwerk even te vergeten en schoon verbinding te maken.

[ Voor 12% gewijzigd door Joenino op 18-08-2022 15:42 ]

[Pharos1985]

Beste,

Eventjes een statusupdate.
Ticket opengedaan bij MS en na 1 week iemand van MS te pakken gekregen die vrij goed wist waarover hij sprak. Hij vertelde me dat een CA upgraden naar van 2016 naar 2022 met inplace upgrade geen goed idee was. Hij raadde me aan om een tussenstap te maken op 2019.
De AD/CA/NPS machine die ik dus terugrolde uit Veeam backup, geupgrade naar 2019 en jawel: NPS/CA werkte weer als vanouds. Zowel voor onze AOVPN als onze WiFi.
Dan onmiddellijk doorgezet en terug inplace upgrade naar 2022: zelfde: NPS werkt weer voor beide services.

Dusja: strange, maar goed. Nochtans is inplace upgrade van 2016 naar 2022 gesupporteerd volgens wat ik overal lees.

Met de AD nu: die draait al een 3-tal weken zonder enige issue, dus zonder een authorative restore: denken jullie dat ik hier in de toekomst nog issues mee ga krijgen? Want een authorative restore alsnog nu gaan uitvoeren, lijkt me niet zo'n goed idee...

[Question Mark]

Da's bijzonder... Heb je toevallig ook een verwijzing naar een KB-artikel hierover? De officiele docu vanuit Microsoft geeft nl. aan dat dit prima supported zou moeten zijn:

https://docs.microsoft.co...erver-should-i-upgrade-to

[Dennism]

Question Mark schreef op woensdag 24 augustus 2022 @ 09:08:
Da's bijzonder... Heb je toevallig ook een verwijzing naar een KB-artikel hierover? De officiele docu vanuit Microsoft geeft nl. aan dat dit prima supported zou moeten zijn:

https://docs.microsoft.co...erver-should-i-upgrade-to

Kan zijn dat er voor de CA rol misschien andere zaken gelden, ik weet bijvoorbeeld uit het verleden dat MS Upgrades van een machine met een CA role eigenlijk standaard afraadde, en een migratie aanraadde waarbij je een nieuwe server optuigde.

[ElCondor]

CA schijnt inderdaad lastig te zijn. Ik heb ook altijd begrepen (sinds Windows 2016 uitkwam) dat een CA niet up te graden is.
CA rol exporteren en importeren op een nieuwe server wordt aangeraden. Dit heb ik tot nu toe altijd gedaan en nooit meer problemen ondervonden hiermee. Het is alleen wel spannend.