NetExtender accede ma nessun accesso: SonicWall locale + LDAP

L'accesso riesce, il tunnel si alza e nulla dietro il firewall risponde. Questo schema su un SonicWall SSL VPN di solito significa che l'account ha superato l'autenticazione e si è fermato a una delle due autorizzazioni successive: l'ammissione al servizio SSL VPN o il permesso di raggiungere una risorsa. Gli account locali e LDAP misti peggiorano la situazione, perché i due archivi raggiungono queste autorizzazioni per percorsi diversi. Il sintomo è identico dal client, ed è per questo che i livelli vanno separati deliberatamente.

Il sintomo e le tre autorizzazioni dietro

Tre decisioni indipendenti separano un nome utente da un server raggiungibile. Il metodo di autenticazione decide se la credenziale viene accettata e da quale archivio. L'appartenenza al servizio SSL VPN decide se quell'identità può usare l'SSL VPN. L'elenco di accesso VPN decide quali destinazioni private la sessione può raggiungere. Superarne una non dice nulla delle due successive.

Un utente che si autentica ma non è nel gruppo del servizio SSL VPN vede una connessione che si stabilisce e poi non trasporta nulla, e il registro del firewall mostra un accesso accettato anziché un errore. È il caso che conviene riconoscere in fretta, perché la soluzione è un'appartenenza a un gruppo e non un ripristino della password.

Un utente ammesso ma senza risorse vede una sessione che si connette e non instrada da nessuna parte di utile. Entrambi sembrano un tunnel rotto dall'help desk, ed entrambi sono configurazione e non connettività.

Il campo dominio non è la directory

NetExtender chiede un dominio, e quel campo non è una base di ricerca per Active Directory. Nella disposizione predefinita il campo deve corrispondere al dominio utente SSL VPN configurato sul firewall, e il valore predefinito documentato è LocalDomain. Il confronto distingue maiuscole e minuscole, quindi un valore digitato con una diversa capitalizzazione fallisce anche quando l'account è corretto.

Con il partizionamento dell'autenticazione configurato, i nomi delle partizioni selezionano il contesto di autenticazione esterno, e il valore predefinito configurato mantiene il proprio ruolo. In entrambe le disposizioni l'etichetta di dominio lato client non viene inoltrata a LDAP o RADIUS come parte del nome utente, quindi non può orientare una ricerca nella directory.

Tieni separate le tre stringhe nelle note: il suffisso DNS dell'azienda, la base di ricerca LDAP e l'etichetta di dominio NetExtender. Si somigliano e nessuna sostituisce l'altra. Copia il valore dell'operatore per questa installazione e non un valore da un post di forum su un'altra versione del firmware.

Ammissione e accesso alle risorse sono autorizzazioni separate

Gli account locali devono appartenere al gruppo del servizio SSL VPN prima che il servizio li accetti. Gli account di directory raggiungono lo stesso gruppo tramite il flusso di lavoro di mappatura dei gruppi supportato, il che significa che la relazione di gruppo LDAP va configurata e poi verificata come appartenenza effettiva anziché presunta dal lato della directory.

L'accesso alle risorse viene dopo, in Accesso VPN sull'utente o sul gruppo. Concedi le sottoreti e i servizi specifici che il ruolo richiede, e resisti alla scorciatoia di concedere l'intera LAN perché serve un'applicazione. Le rotte della sessione, le regole di accesso e i permessi del servizio di destinazione devono tutti concordare con questo ambito.

Una rotta sul client rende selezionabile una destinazione e non la autorizza. L'appartenenza al gruppo SSL VPN non rende nemmeno l'account un amministratore del firewall, e non va trattata come una concessione generale di privilegi.

Due identità, quattro controlli ciascuna

Prova con un account locale e un account di directory, entrambi con autorizzazione ristretta ed entrambi documentati come account di test. Per ciascuno, registra l'origine di autenticazione che ha accettato l'accesso, i gruppi effettivi, l'accesso alle risorse assegnato e un'operazione applicativa consentita. Quattro controlli, due archivi e un risultato scritto per ogni combinazione.

Poi prova i casi negativi: una risorsa che l'account non deve raggiungere e un account che va rifiutato del tutto. Un progetto che dimostra solo il percorso positivo tende a lasciare aperto un secondo ingresso, soprattutto quando lo stesso nome utente breve esiste in entrambi gli archivi. Disabilita l'account di directory e conferma che quello locale non continua a funzionare in silenzio.

Esamina i nomi duplicati come parte del rilascio e non dopo un incidente. La stessa persona in due archivi è insieme una comodità per il supporto e un problema di audit, e il firewall autenticherà volentieri quello che hai configurato.

Mantieni stretto il percorso di ripristino

Conserva la politica MFA per ogni classe di account invece di esentarne gli account locali. Se gli account locali offrono un percorso di ripristino approvato per un'interruzione della directory, limita quel percorso ad amministratori nominati e gestiscilo deliberatamente, perché un account di emergenza locale per ogni dipendente è un secondo sistema di autenticazione con una supervisione più debole.

Scrivi il dominio del client, l'origine di autenticazione e l'accesso effettivo nello stesso record. L'amministratore successivo può così riprodurre un progetto di account misti funzionante invece di provare stringhe di dominio finché un accesso riesce.