Guida online ESET

Ricerca Italiano
Seleziona l'argomento

Configurazione PAM

Configurare un'area di autenticazione personalizzata

1.Creare un'area di autenticazione personalizzata per gli utenti che effettuano l’autenticazione attraverso un modulo PAM.

2.In caso di configurazione del client RADIUS, selezionare l'area di autenticazione personalizzata nella sezione Utenti.


note

Area di autenticazione personalizzata rispetto al dominio AD corrente

Se si seleziona un’area di autenticazione personalizzata e il modulo PAM invia “dominio\nome utente” al server ESA RADIUS, nell’area di autenticazione personalizzata viene creato un utente con il nome utente “dominio\nome utente”.

Se si seleziona il Dominio AD corrente o il Dominio AD corrente e i domini attendibili al posto di un’area di autenticazione personalizzata e il modulo PAM invia “dominio\nome utente” al server ESA RADIUS, verrà creato un utente con il nome utente “nome utente” nell’area di autenticazione “dominio”.

Modulo di autenticazione PAM

1.Scaricare PAM RADIUS tar.gz da https://freeradius.org/sub_projects/

2.Estrarre il pacchetto scaricato eseguendo il seguente comando in una finestra del terminale:

tar xzvf pam_radius-release_2_0_0.tar.gz

3.Creare la libreria .so eseguendo i seguenti comandi in una finestra del terminale:
 
cd pam_radius-release_2_0_0
./configure
make
 
Su Linux, per esempio OpenSuse, in base all'output del comando configure (Configura), potrebbe essere necessario installare delle dipendenze.
 
sudo zypper install gcc make pam-devel

4.Copiare la libreria costruita nel percorso predefinito dei moduli PAM
 
Linux:
cp pam_radius_auth.so /lib/security
oppure
cp pam_radius_auth.so /lib64/security
 
Mac:
cp pam_radius_auth.so /usr/lib/pam

In OS X El Capitan e versioni successive, questo percorso è protetto da System Integrity Protection (Protezione integrità di sistema). Per utilizzarlo, è necessario disabilitarlo per il comando copia.

5.Creare un file di configurazione del server denominato server nel percorso /etc/raddb/ Al suo interno, inserire i dettagli del server RADIUS nel seguente formato:
<radius server>:<port> <shared secret> <timeout in seconds>
 
Per esempio:
1.1.1.1 test 60

dove:

1.1.1.1 rappresenta l'indirizzo IP del server RADIUS ESA

test è il segreto condiviso di un client RADIUS configurato in ESA Web Console

60 è il tempo di attesa in secondi per l'approvazione della notifica push

6.Applicare le autorizzazioni di protezione appropriate al file di configurazione

chown root /etc/raddb

chown root /etc/raddb/server

chmod 600 /etc/raddb

chmod 600 /etc/raddb/server

 

Vedere INSTALLA per consultare le raccomandazioni per il file di configurazione e UTILIZZO per i parametri che è possibile trasferire alla libreria. Ad esempio, è possibile utilizzare il parametro “debug” per individuare potenziali problemi.

Integrazione del modulo PAM

I moduli PAM possono essere integrati in vari tipi di autenticazione, ad esempio, login (Autenticazione), sshd, su, sudo e così via. L’elenco di tipi di autenticazione disponibili è posizionato nel percorso /etc/pam.d/.

sshd: accesso remoto tramite SSH


note

Assicurarsi di impostare ChallengeResponseAuthentication su yes (sì) in /etc/ssh/sshd_config.

sudo

su

common-auth - OpenSUSE (tutte le autenticazioni)

login: OpenSUSE (accesso alla console)

authorization (autorizzazione): schermata di accesso macOS

Per abilitare l'autenticazione a due fattori per uno dei servizi indicati in precedenza, aggiungere la seguente riga nel file di configurazione corrispondente in /etc/pam.d:

auth required pam_radius_auth.so use_first_pass

Nel comando precedente, pam_radius_auth.so rappresenta il percorso di un modulo PAM configurato in precedenza o sarà "pam_radius_auth.so". use_first_pass garantisce che il modulo PAM non richieda invano una password aggiuntiva (OTP), a meno che ESA RADIUS non richieda il secondo fattore. Se, ad esempio, un utente con protezione 2FA ha abilitato l'autenticazione push, il modulo PAM attende solo l'approvazione della notifica push senza richiedere l’inserimento di una OTP.

Per garantire che la 2FA non venga richiesta quando il primo fattore restituisce un errore, modificare auth required pam_unix.so in auth requisite pam_unix.so.

Alcune interfacce di accesso, tra cui la schermata di accesso di macOS, non possono visualizzare un campo separato per la 2FA. In questi casi, l'accesso può essere effettuato solo dagli utenti che utilizzano l'autenticazione push (push applicazione mobile), gli utenti non 2FA o gli utenti provenienti da un indirizzo IP nella whitelist. Per garantire che venga utilizzato solo il push applicazione mobile senza che venga richiesta l'attivazione della OTP, anche se l'utente ha abilitato opzioni 2FA aggiuntive, aggiungere client_id=challenge_never alla riga di configurazione:

auth required pam_radius_auth.so use_first_pass client_id=challenge_never

Valori disponibili per client_id (id_client):

challenge_if_possible: l’opzione predefinita richiede sempre la password monouso se l’utente ha abilitato un qualsiasi tipo di password monouso, anche se l’invio del “push dell’applicazione mobile” è stato eseguito correttamente.

challenge_always: richiedere sempre l'OTP, anche se l'invio del "push applicazione mobile" è riuscito e l'utente non ha abilitato alcun tipo di OTP. Consente sempre di inserire MRK in caso di errore (questa opzione è consigliata per gli scenari critici, per esempio, l’autenticazione SSH a un server remoto a cui non è possibile accedere in modo semplice)

challenge_if_needed: non richiedere mai l'OTP in caso di invio del "push applicazione mobile" riuscito, evitando in tal modo ulteriori richieste/campi OTP e consentendo un’autenticazione più rapida.

challenge_never: non richiedere mai l'OTP.

Su alcune distribuzioni Linux è possibile modificare facilmente il login manager. Per esempio, gdm supporta la richiesta di informazioni aggiuntive.