Per poter gestire un accesso autenticato a delle pagine web riservate, il server web Apache fornisce diverse modalità che consentono di farlo.

Difatti, il meccanismo dell’autenticazione HTTP è direttamente previsto dal protocollo, in genere l’autenticazione viene gestita nella forma più semplice di un file .htpasswd in cui viene salvato un elenco di utenti con relativa password.

In questo articolo vedremo come la si possa realizzare con il web server Apache, appoggiandosi ad un server Active Directory, cosi da poter utilizzare gli utenti già presenti in un dominio Windows. In realtà in questo caso useremo il supporto generico di Apache per l’autenticazione su LDAP, utilizzando questo protocollo per collegarsi ad Active Directory.

Le istruzioni che seguono sono relative ad un sistema basato su Debian, i concetti sono gli stessi per tutte le distribuzioni, così come i comandi e le direttive di configurazione, ma saranno diversi i file di configurazione coinvolti. Teniamo sempre in considerazione che il meccanismo di autenticazione HTTP avviene a livello del protocollo e prevede il passaggio delle credenziali in chiaro, quindi dovrà essere sempre utilizzato previa impostazione dell’uso dello stesso all’interno di un collegamento in https (una impostazione di questo tipo è stata trattata in questo altro articolo).

Su Debian i moduli di Apache necessari all’autenticazione su LDAP non sono abilitati di default ma sono installati insieme al server, pertanto per poterli utilizzare andranno abilitati eseguendo i comandi:

a2enmod ldap 
a2enmod authnz_ldap

Rispetto all’autenticazione HTTP con un server LDAP ordinario (per una trattazione dettagliata si rimanda al capitolo 3.2.1 del testo Integrazione sistemistica con LDAP), l’autenticazione fatta su Active Directory presenta alcune difficoltà aggiuntive.

Utilizzando AD infatti non saranno possibili interrogazioni anonime, e pertanto occorrerà disporre di un utente per poter effettuare l’accesso preliminare necessario ad ottenere  il distinguished name corrispondente al nome utente inserito nel browser, con il quale si potrà eseguire l’autenticazione su LDAP. Inoltre, per ovvi motivi di sicurezza, per accedere con autenticazione su AD è necessario utilizzare una connessione cifrata con TLS/SSL, ma il certificato di un server AD non ha quasi mai una firma valida, in quanto viene generato internamente, e quindi di default il client rifiuterà la connessione.

La prima azione da fare per la configurazione è quella di verificare la raggiungibilità ed il corretto funzionamento della connessione ad Active Directory con LDAP con l’utente che useremo per le interrogazioni preliminari, iniziando dall’utilizzo del corretto distinguished name dello stesso. Dando per scontato che il dominio servito dal server AD sia example.com e che l’utente per il collegamento sia apacheauth (non è necessario che abbia nessun privilegio, per cui è opportuno usare un utente dedicato senza nessun permesso specifico) potremo usare per la verifica della connessione il comando ldapsearch (installabile su Debian con il pacchetto ldap-utils), con qualcosa del tipo:

root@server~: LDAPTLS_REQCERT=never ldapsearch -x -H ldaps://IND.IP.AD.SERV -D "cn=apacheauth,cn=Users,dc=example,dc=com" -b "dc=example,dc=com" -w apachepwd '(sAMAccountName=apacheauth)' | grep result:
result: 0 Success

dove il prefisso LDAPTLS_REQCERT=never è necessario per disabilitare la verifica del certificato SSL del server AD, che, come abbiamo spiegato prima, non risulterà valido, mentre CN=apacheauth,CN=Users,DC=example,DC=com è la forma standard del distinguished name che invece corrisponde all’utente apacheauth.

Dopo che avremo verificato che l’accesso LDAP al server AD stia funzionando, potremo passare alla configurazione di Apache, in genere andrà divisa in due fasi, la prima per la configurazione generale delle interrogazioni LDAP, che si può fare con il seguente frammento (da inserire ad esempio in /etc/apache2/conf-available/ad-ldap.conf ed abilitare con a2enconf ad-ldap):

# do not verify server certificate, for AD is invalid
LDAPVerifyServerCert Off

# if you have installed in /etc/ssl/certs/ad-server-cert.pem the AD server certificate 
# (you can get it with: openssl s_client -connect IND.IP.AD.SERV:636| openssl x509 > ad-server-cert.pem)
# you can comment the previous directive and uncomment the next one
# LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/certs/ad-server-cert.pem

dove si indica ad Apache di non verificare il certificato del server AD con LDAPVerifyServerCert, o, in alternativa, una volta ottenuto il certificato dello stesso come indicato nel commento, lo si imposta forzatamente come fidato con LDAPTrustedGlobalCert.

Le direttive da includere in un virtual host, all’interno delle direttive Directory o Location che selezionano le pagine su cui si vuole impostare un accesso autenticato con gli utenti del server AD, a questo punto, sono le seguenti:

    AuthType Basic
    AuthBasicProvider ldap        
    AuthName "AD domain user" 
    AuthLDAPURL "ldaps://IND.IP.AD.SERV/cn=Users,dc=example,dc=com?sAMAccountName?sub?(objectClass=*)" 
    AuthLDAPBindDN "cn=apacheauth,cn=Users,dc=example,dc=com" 
    AuthLDAPBindPassword apachepwd
    AuthzLDAPAuthoritative on
    Require valid-user

dove  AuthLDAPBindDN sta a indicare il distinguished name dell’utente di servizio che abbiamo verificato (e AuthLDAPBindPassword la sua password) mentre AuthLDAPURL indica la URL da utilizzare con il protocollo LDAP per eseguire la ricerca dell’username fornito dal browser, che deve essere fatta sui valori dell’attributo sAMAccountName.

In questo caso le istruzioni, con la direttiva Require valid-user, vincolano l’accesso ad una autenticazione con un qualunque utente valido, si può indicare una restrizione più precisa ad uno specifico utente sostituendo questa riga con Require ldap-user "someuser", indicandolo per nome (con cui verrà cercato su AuthLDAPURL) o più specificatamente indicandolo per distinguished name con Require ldap-dn "cn=someuser,cn=Users,dc=example,dc=com".

E’ possibile però anche essere più restrittivi ed utilizzare un gruppo di utenti, ottenibile nuovamente da Active Directory, in tal caso occorrerà dire ad Apache in che maniera verificare l’appartenenza di un utente ad un gruppo, e le precedenti direttive dovranno essere modificate in:

    AuthType Basic
    AuthBasicProvider ldap        
    AuthName "AD domain user" 
    AuthLDAPURL "ldaps://IND.IP.AD.SERV/cn=Users,dc=example,dc=com?sAMAccountName?sub?(objectClass=*)" 
    AuthLDAPBindDN "cn=apacheauth,cn=Users,dc=example,dc=com" 
    AuthLDAPBindPassword apachepwd
    AuthzLDAPAuthoritative on
    # parameters for group authentication
    AuthLDAPGroupAttribute member
    AuthLDAPGroupAttributeIsDN On
    # you need to identify group by its distinguished name
    Require ldap-group cn=website,cn=Users,dc=example,dc=com

dove si suppone che gli utenti autorizzati all’accesso siano quelli del gruppo website di Active Directory, da indicare di nuovo con il suo distinguished name.

Se avete ulteriori domande o questioni che richiedano uno specifico approfondimento, non esitate a contattarci sul nostro sito (Contatti – Not Just A Cloud).

                                                                                             La redazione