RouterOS OpenVPN e NPS: imposta user-auth-method, non auth

RouterOS può raggiungere NPS con un accesso OpenVPN e venire comunque rifiutato, e la causa abituale sono due impostazioni i cui nomi suonano entrambi come autenticazione. Una sceglie un digest crittografico per il tunnel; l'altra decide come le credenziali dell'utente vengono presentate a RADIUS. Cambiare il digest non trasformerà mai una richiesta PAP in MS-CHAPv2, per quante volte il servizio venga riavviato. L'elenco di controllo qui sotto separa le due cose, poi segue un singolo accesso fallito attraverso la policy NPS che lo ha giudicato.

Passo 1: leggi entrambe le impostazioni prima di cambiarne una

Stampa la configurazione effettiva del server OpenVPN sul router che termina il tunnel, non da un backup o da un post di forum copiato. I due campi che ti interessano di solito stanno nello stesso menu e si leggono come se fossero alternative. Non lo sono: uno riguarda il canale dati, l'altro lo scambio delle credenziali.

/interface ovpn-server server print
/interface ovpn-server server export

Il campo auth elenca digest come sha1 e sha256 e controlla l'HMAC che autentica i pacchetti del tunnel. Il campo user-auth-method sceglie pap o mschap2 e decide come il router presenta le credenziali dell'utente a RADIUS. Un cambio di digest non può alterare il secondo comportamento, ed è per questo che lo stesso rifiuto sopravvive a ogni ritocco del primo.

Fermati qui se la tua versione non espone affatto user-auth-method. Le build più vecchie di RouterOS potrebbero non offrirlo sul server OpenVPN, e la correzione appartiene a una versione che puoi supportare, non a un comando copiato da una più recente.

Passo 2: trova la policy che ha realmente rifiutato l'accesso

Lato NPS, una richiesta di connessione viene valutata rispetto alle policy di rete, e il metodo di autenticazione indicato nella policy corrispondente deve essere uno che il client ha realmente offerto. Correla un singolo accesso fallito per ora e utente invece di leggere un conteggio riepilogativo. Il registro di sicurezza annota le richieste concesse e negate con un codice motivo, che ti dice molto più della riga di errore generica del router.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Leggi tre cose nell'evento: il nome della policy corrispondente, il metodo di autenticazione e il codice motivo. Una policy che richiede MS-CHAPv2 rifiuta una richiesta PAP anche quando la password è corretta, e una policy che richiede un account di dominio rifiuta uno locale. Anche la voce del client RADIUS deve corrispondere all'indirizzo sorgente del router, altrimenti la richiesta viene scartata prima che qualsiasi policy sia consultata. Niente di tutto ciò compare nel registro di OpenVPN.

Fermati qui se la richiesta non raggiunge mai NPS. È un problema di segreto condiviso, indirizzo del client o UDP 1812, e cambiare i metodi di autenticazione non lo risolverà.

Passo 3: cambia un metodo, su entrambi i lati

Se il progetto approvato è MS-CHAPv2, impostalo sul router e conferma che la policy corrispondente lo accetti. Cambia un lato, ripeti il test, poi cambia l'altro; cambiare entrambi insieme ti lascia incapace di dire quale contava.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Non abilitare ogni metodo più debole su NPS per far sparire l'errore. Il backend deve possedere materiale che il metodo scelto possa verificare: MS-CHAPv2 richiede accesso alla password o al dominio, e una policy non può inventare quel materiale. Ampliare la policy amplia anche ciò che un attaccante può tentare contro lo stesso account. Registra insieme il metodo, il nome della policy e il riferimento della modifica, così la persona successiva eredita una decisione e non una supposizione.

Lascia la validazione del certificato del tunnel esattamente com'era. Un metodo di credenziali non sostituisce l'identità del server, e abbassare i controlli TLS per far passare un test scambia un problema con uno peggiore.

Passo 4: prova tre accessi e un permesso

Prova un utente consentito, una password errata e un utente escluso, ciascuno in una sessione nuova. Il primo dimostra il percorso, il secondo dimostra che il controllo delle credenziali è reale e il terzo dimostra che la policy esclude ancora chi deve. Una sessione in cache può nascondere tutti e tre, quindi disconnettiti tra i tentativi.

/log print where topics~"ovpn"
/radius monitor 0

Il successo dell'autenticazione non è la fine dell'elenco. Controlla l'indirizzo che il client ha ricevuto e le risorse che quell'indirizzo può raggiungere, perché un utente può autenticarsi correttamente e finire comunque nel pool sbagliato. Se l'indirizzo assegnato è errato, il problema sta nel profilo o negli attributi della risposta RADIUS, non nel metodo. Conferma entrambe le cose prima di chiudere il ticket.

L'elenco è completo quando l'impostazione del router e la policy NPS nominano lo stesso metodo, un utente consentito si connette con una sessione nuova, una password errata viene rifiutata, un utente escluso resta escluso e l'indirizzo assegnato corrisponde al pool previsto. Qualsiasi cosa in meno lascia il prossimo accesso al caso.