[Windowsw 2019 NPS] Servernaam veranderen?

[Urk]

Wij gebruiken de NPS rol van een Windows Server 2019 voor wifi authenticatie voor WPA2 Enterprise.
Het certificaat wat gebruikt wordt voor een WiFi connectie moet gelijk zijn aan de servernaam van de server (zie dit artikel en deze discussie).
Helaas is ons domein ooit opgezet als een .local domein en heb ik daarnaast in DNS wel een ad.domeinnaam.nl DNS zone opgezet maar hoe kan ik de naam van een NPS server aanpassen? Deze is nu dus bijv servernaam.domein.local maar wil ik aanpassen naar servernaam.ad.domeinnaam.nl.
Met dat in zicht kan ik ook een signed certificaat toevoegen op deze naam via een bekende Cert Authority.
Hoe verander ik verder de uitgegeven/verzonden FQ servername zodat deze ook niet meer het .local domein gebruikt maar servernaam.ad.domeinnaam.nl, zodat ook een certificaat hiervoor voor bijv RDP gebruikt kan worden? Of doe je dat per service?

[Wim-Bart]

Oplossing 1: Nieuwe active directory optuigen server uit oude domein halen in nieuwe domein hangen.

Oplossing 2: Nieuwe server bouwen in je nieuwe AD, wat sneller is.

Oplossing 3: Cname maken in DNS van nieuwe domein naar oude server, op oude server een San certificaat gebruiken.

Oplossing 2 is eigenlijk de enige juiste. Dan kan je testen of het werkt en dan de hele boel overzetten. En voor een naadloze overgang kan je een trust gebruiken tussen de twee ADs en langzaam alles migreren van oude domein naar nieuwe.

[ Voor 29% gewijzigd door Wim-Bart op 18-12-2019 18:52 ]

[johnkeates]

Oplossing 4: een RADIUS server opzetten die niet op je windows bak werkt en daar gewoon een domein en certificaat naar smaak op zetten. Die server kan je dan met AD of LDAP laten babbelen voor user management.

[Urk]

Hmmm... Veel opties zijn niet echt mogelijk, er hangen al een paar nieuwe servers in het .local domein.
Kan ik dus niet gewoon de FQ naam van de NPS server wijzigen? Of pakt de NPS server gewoon de interne servernaam?
Via DNS CNAME kan ik voor bijv RDP prima een andere hostname gebruiken die ik heb aangemaakt.

[johnkeates]

https://packetfence.org/d...e_Installation_Guide.html Kost niks, ook niet moeilijk op te zetten. En als een VM te veel is kan het ook in een container.

[ Voor 43% gewijzigd door johnkeates op 18-12-2019 19:15 ]

[Urk]

Bedankt, maar ik wil 't toch graag bij de Windows services houden. Hoe zit dat dan toch precies met die servernaam? NPS heeft dus geen optie de servernaam aan te passen anders dan de standaard AD servernaam?

[Urk]

Kickje

[Will_M]

Urk schreef op vrijdag 27 december 2019 @ 22:28:
Kickje

NPS: Staat dat niet voor 'Network Protection Service'?

Wat zou er gebeuren als je die DNS NAAM gaat aanpassen in een Active Directory welke cruciaal voor je netwerk is én waarbij een Active Directory ook volledig DNS georiënteerd is?

[DukeBox]

johnkeates schreef op woensdag 18 december 2019 @ 18:51:
Oplossing 4: een RADIUS server opzetten die niet op je windows bak werkt en daar gewoon een domein en certificaat naar smaak op zetten. Die server kan je dan met AD of LDAP laten babbelen voor user management.

Het kan eventueel ook middels een radius proxy. Authenticatie nog steeds via je AD maar toch een custom certificaat.

Je kan ook op de NPS het certificaat vervangen (vernieuwen) met meerdere 'alternative names' aan toe voegen.

[johnkeates]

Je kan het wel 'bij windows willen houden' maar dat lost je probleem niet op, en al helemaal niet als je het op de eerste plaats in Windows niet aan het werk kan krijgen.

[Urk]

Ik zeg niet dat ik het aanpas in AD. Ik vraag me alleen af wat er mogelijk is. En waarom zou je dat niet kunnen wijzigen naar eigen believen? Bij installatie kan ik het ook zelf kiezen...
Eigenlijk zou ik de hele FQDN willen aanpassen die de NPS server naar clients presenteert

[Urk]

DukeBox schreef op vrijdag 27 december 2019 @ 22:39:
[...]

Het kan eventueel ook middels een radius proxy. Authenticatie nog steeds via je AD maar toch een custom certificaat.

Je kan ook op de NPS het certificaat vervangen (vernieuwen) met meerdere 'alternative names' aan toe voegen.

Ja klopt maar niet alle WiFi clients kunnen daar mee omgaan voor zover ik weet. Net zoals een wildcard ook niet werkt, dat heb ik zelf ondervonden.

[johnkeates]

Wat probeer je eigenlijk te realiseren? Werkende WPA2 Enterprise of een windows-experiment?

[Will_M]

Urk schreef op vrijdag 27 december 2019 @ 22:42:
[...]

Ja klopt maar niet alle WiFi clients kunnen daar mee omgaan voor zover ik weet. Net zoals een wildcard ook niet werkt, dat heb ik zelf ondervonden.

Ik hoop voor je dat dit een OTA omgeving is waar je géén productie (netwerk) mee gaat raken? Wie heeft die 2019 MS Windows Server daar 't netwerk op geholpen én de NPS rol daar aan toebedeeld?

[Urk]

wimmel_1 schreef op vrijdag 27 december 2019 @ 22:45:
[...]


Ik hoop voor je dat dit een OTA omgeving is waar je géén productie (netwerk) mee gaat raken? Wie heeft die 2019 MS Windows Server daar 't netwerk op geholpen én de NPS rol daar aan toebedeeld?

Dat heb ik zelf gedaan, hoezo? AD is al jaren geleden opgezet door een andere partij met toen nog een .local AD domein helaas.
Alles werkt opzich prima (de WPA2 Enterprise omgeving), alleen vind ik het storend dat ik geen certificaat kan presenteren die uitgegeven is door een erkende cert authority.

[Urk]

johnkeates schreef op vrijdag 27 december 2019 @ 22:44:
Wat probeer je eigenlijk te realiseren? Werkende WPA2 Enterprise of een windows-experiment?

Klopt, werkende WPA2 Enterprise omgeving; en dat lukt ook, zie ook andere reactie hieronder

[DukeBox]

Urk schreef op vrijdag 27 december 2019 @ 22:42:
Ja klopt maar niet alle WiFi clients kunnen daar mee omgaan voor zover ik weet. Net zoals een wildcard ook niet werkt, dat heb ik zelf ondervonden.

Zou gewoon moeten werken. Ik maak ook gebruik van een wildcard je moet alleen zorgen dat de key sterk genoeg is (en het werkt niet op een sub-sub domain, wat met bijv co.uk wel een issue kan zijn).

[midget]

Urk schreef op vrijdag 27 december 2019 @ 22:55:
[...]

Dat heb ik zelf gedaan, hoezo? AD is al jaren geleden opgezet door een andere partij met toen nog een .local AD domein helaas.
Alles werkt opzich prima (de WPA2 Enterprise omgeving), alleen vind ik het storend dat ik geen certificaat kan presenteren die uitgegeven is door een erkende cert authority.

Kwestie van je eigen interne CA te realiseren?
eenvoudige rol op een Windows server.
En neem aan dat de nps server alleen voor interne clients is.

[johnkeates]

Urk schreef op vrijdag 27 december 2019 @ 22:56:
[...]

Klopt, werkende WPA2 Enterprise omgeving; en dat lukt ook, zie ook andere reactie hieronder

Het enige wat ik aan reacties zie zijn opstellingen die niet ondersteund worden, combinaties van rollen die niet ondersteund worden en opstellingen die je in het algemeen niet productie waardig zou noemen.

[Urk]

DukeBox schreef op vrijdag 27 december 2019 @ 22:56:
[...]

Zou gewoon moeten werken. Ik maak ook gebruik van een wildcard je moet alleen zorgen dat de key sterk genoeg is (en het werkt niet op een sub-sub domain, wat met bijv co.uk wel een issue kan zijn).

Hmmm OK tnx, dan heb je ongetwijfeld gelijk maar mijn wildcard certificaat is voor ons publieke domein, en die zou eventueel natuurlijk ook voor een ad.domeinnaam.nl opnieuw uitgegeven kunnen worden. Het probleem is echter dat het AD domein een.local domein is en ik daarom dus de servernaam wilde veranderen, bijv in iets als nps.ad.domeinnaam.nl.

[Will_M]

midget schreef op vrijdag 27 december 2019 @ 22:57:
[...]


Kwestie van je eigen interne CA te realiseren?
eenvoudige rol op een Windows server.
En neem aan dat de nps server alleen voor interne clients is.

Ook dát is niet even 'simpel'....Je maakt al snel de fout door maar even snel dóór te gaan klikken terwijl je eigenlijk (minimaal) een 2-Tier CA wil op zetten (en nog liever een 3-tier vanwege de CRL handeling).

[midget]

wimmel_1 schreef op vrijdag 27 december 2019 @ 23:00:
[...]


Ook dát is niet even 'simpel'....Je maakt al snel de fout door maar even snel dóór te gaan klikken terwijl je eigenlijk (minimaal) een 2-Tier CA wil op zetten (en nog liever een 3-tier vanwege de CRL handeling).

Eens en de Root offline in de kluis of crypto ruimte.
Snap ik, maar er wordt gezocht naar oplossingen en met voldoende Windows kennis is dit te realiseren.

[Urk]

johnkeates schreef op vrijdag 27 december 2019 @ 22:58:
[...]

Het enige wat ik aan reacties zie zijn opstellingen die niet ondersteund worden, combinaties van rollen die niet ondersteund worden en opstellingen die je in het algemeen niet productie waardig zou noemen.

Want...? Verklaar je nader graag. Waarom is een NPS server ik een Windows 2019 AD domein niet productie waardig? Omdat het een .local domein betreft en dat een bottleneck is?

[Urk]

midget schreef op vrijdag 27 december 2019 @ 22:57:
[...]


Kwestie van je eigen interne CA te realiseren?
eenvoudige rol op een Windows server.
En neem aan dat de nps server alleen voor interne clients is.

Klopt wat betreft je eerste deel, interne CA heb ik al draaien, die is ook nieuw opgezet naast een oude AD CA op een 2008 R2 bak.
En nee, niet alleen voor interne clients, dat zou makkelijk zijn omdat ik dan via GPO automatisch de interne CA zou kunnen vertrouwen. Het kunnen echter ook non-domain joined laptops zijn die gebruik maken van de WPA2 Enterprise wifi. En daarnaast natuurlijk non-domain joined smartphones die de interne CA standaard natuurlijk niet vertrouwd

[Urk]

Dank trouwens voor de vele en snelle reacties deze keer

[Question Mark]

wimmel_1 schreef op vrijdag 27 december 2019 @ 22:34:
[...]
Wat zou er gebeuren als je die DNS NAAM gaat aanpassen in een Active Directory welke cruciaal voor je netwerk is én waarbij een Active Directory ook volledig DNS georiënteerd is?

Dat is nu precies zijn vraag...

Ik kan het niet terugvinden, maar mijn vermoeden zou zijn dat het allemaal wel wat mee zou moeten vallen. Veel spannender dan het aanpassen van de naam in AD (wat een supported optie is), het vervangen van het certificaat en aanpassen van evt. policy's en de access points zou voldoende moeten zijn.

Wat zou er dan nog meer moeten gebeuren in jouw ogen of mis kunnen gaan?

@TS: Microsoft heeft een artikel waarin uitgeleg wordt welke controles uitgevoerd moeten worden na het hernoemen van een Server 2016 based NPS server:

Verify Configuration After NPS Changes

Uit die checklist blijkt al dat er maar een paar aanpassingen doorgevoerd hoeven te worden....