Ultimamente sto effettuando la migrazione dei sistemi operativi Microsoft server di alcuni clienti.
Di solito questa operazione nasconde sempre delle insidie. Bisogna verificare che nel frattempo non ci siano state novità che ad esempio possano inficiare o impedire i servizi operanti nell'azienda. Nel passato Microsoft non si è risparmiata a rende difficile la vita ai noi sistemisti, introducendo regressioni o comportamenti inaspettati come quello in oggetto.
Lo scenario era apparentemente semplice: un server virtuale 2012r2 membro di dominio da rimpiazzare con uno 2019 e due funzionalità presenti: Print Server + Server dei criteri di rete (NPS) configurato come radius server per un paio di applicativi linux che lo utilizzano per l'autenticazione. A prima vista un lavoro facile, installazione della vm ex novo, export ed import della configurazione ed è fatta. Uno scenario del genere essendo stateless, non richiede un impegno elevato.
Installo vm Win2019 e aggiorno l'aggiornabile fino a Novembre 2020. Per il print server le cose vanno come previsto, i test danno presto esito positivo. Passo a NPS immaginando di poter completare l'operazione in pochi minuti avvalendomi della funzionalità di export / import della configurazione e apparentemente le cose vanno così. Fino a che non decido di testare questa funzionalità prima di effettuare la sostituzione tra i due server.
Configuro un ambiente di test per utilizzare il server 2019 come radius ... e niente non c'è verso che funzioni.
Andiamo a più basso livello, client linux sul quale in pochi minuti sono pronti tutti gli strumenti di verifica e in particolare il fidato radtest. Faccio subito un test protocollo udp / porta 1812 ottenendo solo time-out di risposta: evidente si tratta di firewall. Ricontrollo le regole su win2019 e sono state create automaticamente e all'apparenza correttamente:
Però se disabilito completamente il firewall ecco che tutto riprende a girare a meraviglia. L'ultima cosa che si possa prendere in considerazione è tenere attivo un server o un client in produzione senza un minimo di protezione firewall. Ho solo trovato il problema, bisogna trovare un rimedio!
Prima soluzione temporanea: disabilito le regole di default e ne creo altre inserendo manualmente protocollo e porta. Adesso il sistema può andare in produzione anche se mi prendo del tempo per poter verificare più a fondo la causa del problema.
Con più calma ho modo di verificare che il problema è già noto: Windows Server 2019 - Default NPS Firewall rules (Port 1812 UDP) Not working (microsoft.com)
Micorosoft ha rilasciato regole di default per il suo firewall relativamente ad NPS che semplicemente non funzionano! La causa principale è che il SID del servizio associato al servizio IAS non consente al servizio Firewall di indirizzare lo stesso servizio IAS.
Una soluzione più ragionata quindi è eseguire il seguente comando da powershell amministrativa:
Get-NetFirewallRule -DisplayGroup "Server dei criteri di rete" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any
Non sembra che Microsoft abbia alcuna intenzione di risolvere il problema. Non ho potuto far altro che firmare la richiesta di presa in considerazione del problema:
https://windowsserver.uservoice.com/forums/295059-networking
annotandomi l'anomalia. Altra magra figura del colosso di Redmond.
Valerio Maglietta
PS: qualora vogliate ripristinare il (mal)funzionamento iniziale, dovrete eseguire il seguente comando da PS: Get-NetFirewallRule -DisplayGroup "Server dei criteri di rete" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service IAS
Comments
NPS & Windows 2019 Server ... altro bug di Microsoft!
Ultimamente sto effettuando la migrazione dei sistemi operativi Microsoft server di alcuni clienti.
Di solito questa operazione nasconde sempre delle insidie. Bisogna verificare che nel frattempo non ci siano state novità che ad esempio possano inficiare o impedire i servizi operanti nell'azienda. Nel passato Microsoft non si è risparmiata a rende difficile la vita ai noi sistemisti, introducendo regressioni o comportamenti inaspettati come quello in oggetto.
Lo scenario era apparentemente semplice: un server virtuale 2012r2 membro di dominio da rimpiazzare con uno 2019 e due funzionalità presenti: Print Server + Server dei criteri di rete (NPS) configurato come radius server per un paio di applicativi linux che lo utilizzano per l'autenticazione. A prima vista un lavoro facile, installazione della vm ex novo, export ed import della configurazione ed è fatta. Uno scenario del genere essendo stateless, non richiede un impegno elevato.
Installo vm Win2019 e aggiorno l'aggiornabile fino a Novembre 2020. Per il print server le cose vanno come previsto, i test danno presto esito positivo. Passo a NPS immaginando di poter completare l'operazione in pochi minuti avvalendomi della funzionalità di export / import della configurazione e apparentemente le cose vanno così. Fino a che non decido di testare questa funzionalità prima di effettuare la sostituzione tra i due server.
Configuro un ambiente di test per utilizzare il server 2019 come radius ... e niente non c'è verso che funzioni.
Andiamo a più basso livello, client linux sul quale in pochi minuti sono pronti tutti gli strumenti di verifica e in particolare il fidato radtest. Faccio subito un test protocollo udp / porta 1812 ottenendo solo time-out di risposta: evidente si tratta di firewall. Ricontrollo le regole su win2019 e sono state create automaticamente e all'apparenza correttamente:
Però se disabilito completamente il firewall ecco che tutto riprende a girare a meraviglia. L'ultima cosa che si possa prendere in considerazione è tenere attivo un server o un client in produzione senza un minimo di protezione firewall. Ho solo trovato il problema, bisogna trovare un rimedio!
Prima soluzione temporanea: disabilito le regole di default e ne creo altre inserendo manualmente protocollo e porta. Adesso il sistema può andare in produzione anche se mi prendo del tempo per poter verificare più a fondo la causa del problema.
Con più calma ho modo di verificare che il problema è già noto:
Windows Server 2019 - Default NPS Firewall rules (Port 1812 UDP) Not working (microsoft.com)
Micorosoft ha rilasciato regole di default per il suo firewall relativamente ad NPS che semplicemente non funzionano! La causa principale è che il SID del servizio associato al servizio IAS non consente al servizio Firewall di indirizzare lo stesso servizio IAS.
Una soluzione più ragionata quindi è eseguire il seguente comando da powershell amministrativa:
Get-NetFirewallRule -DisplayGroup "Server dei criteri di rete" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any
Non sembra che Microsoft abbia alcuna intenzione di risolvere il problema. Non ho potuto far altro che firmare la richiesta di presa in considerazione del problema:
https://windowsserver.uservoice.com/forums/295059-networking
annotandomi l'anomalia. Altra magra figura del colosso di Redmond.
Valerio Maglietta
PS: qualora vogliate ripristinare il (mal)funzionamento iniziale, dovrete eseguire il seguente comando da PS:
Get-NetFirewallRule -DisplayGroup "Server dei criteri di rete" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service IAS