Configurare RADIUS + LDAP per WPA2 su Ubuntu

Sto configurando una rete wireless per circa 150 utenti. In breve, sto cercando una guida per impostare il server RADIUS per autenticare WPA2 rispetto a un LDAP. Su Ubuntu.

• Ho ottenuto un LDAP funzionante, ma poiché non è in uso nella produzione, può essere facilmente adattato a qualsiasi cambiamento possa richiedere questo progetto.
• Ho guardato FreeRADIUS, ma qualsiasi server RADIUS lo farà.
• Abbiamo una rete fisica separata solo per WiFi, quindi non troppe preoccupazioni per la sicurezza su quel fronte.
• I nostri AP sono prodotti aziendali di fascia bassa di HP: sembrano supportare qualunque cosa tu possa pensare.
• Tutti i server Ubuntu, piccola!

E le cattive notizie:

• Ora qualcuno meno esperto di me finirà per assumere l'amministrazione, quindi l'installazione deve essere il più "banale" possibile.
• Finora, la nostra configurazione si basa solo sul software dei repository Ubuntu, ad eccezione della nostra applicazione Web di amministrazione LDAP e di alcuni piccoli script speciali. Quindi niente "recupera pacchetto X, untar, ./configure"-things se evitabile.

AGGIORNAMENTO 18-08-2009:

Mentre ho trovato diverse risorse utili, c'è un grave ostacolo:

Ignoring EAP-Type/tls because we do not have OpenSSL support.
Ignoring EAP-Type/ttls because we do not have OpenSSL support.
Ignoring EAP-Type/peap because we do not have OpenSSL support.

Fondamentalmente la versione Ubuntu di FreeRADIUS non supporta SSL ( bug 183840 ), il che rende inutili tutti i tipi EAP sicuri. Bummer.

Ma una documentazione utile per chiunque sia interessato:

• http://vuksan.com/linux/dot1x/802-1x-LDAP.html
• http://tldp.org/HOWTO/html_single/8021X-HOWTO/#confradius

AGGIORNAMENTO 19-08-2009:

Ho finito per compilare il mio pacchetto FreeRADIUS ieri sera - c'è una ricetta davvero buona su http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (Vedi i commenti al post per istruzioni aggiornate).

Ho ricevuto un certificato da http://CACert.org (probabilmente dovresti ottenere un certificato "reale" se possibile)

Quindi ho seguito le istruzioni su http://vuksan.com/linux/dot1x/802-1x-LDAP.html . Questo link a http://tldp.org/HOWTO/html_single/8021X-HOWTO/ , che è una lettura molto utile se vuoi sapere come funziona la sicurezza WiFi.

AGGIORNAMENTO 2009-08-27:

Dopo aver seguito la guida sopra, sono riuscito a convincere FreeRADIUS a parlare con LDAP:

Ho creato un utente di prova in LDAP, con la password mr2Yx36M- questo dà una voce LDAP all'incirca di:

uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja

Durante l'utilizzo radtest, posso collegarmi bene:

> radtest testuser "mr2Yx36N" sbhr.dk 0 radius-private-password
Sending Access-Request of id 215 to 130.225.235.6 port 1812
    User-Name = "msiebuhr"
    User-Password = "mr2Yx36N"
    NAS-IP-Address = 127.0.1.1
    NAS-Port = 0
rad_recv: Access-Accept packet from host 130.225.235.6 port 1812, id=215, length=20
> 

Ma quando provo attraverso l'AP, non vola - mentre conferma che capisce le password NT e LM:

...
rlm_ldap: sambaNTPassword -> NT-Password == 0x4441343431383745434139374237433134413232463239463532424542443930
rlm_ldap: sambaLMPassword -> LM-Password == 0x4346334436463841393239363745304645373243353745463530463736413035
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP.  Are you sure that the user is configured correctly?
[ldap] user testuser authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing NT-Password from hex encoding
[pap] Normalizing LM-Password from hex encoding
...

È chiaro che le password NT e LM differiscono da quanto sopra, eppure il messaggio [ldap] user testuser authorized to use remote access- e l'utente viene in seguito rifiutato ...

Proverò a rispondere alla domanda LDAP qui.

Ecco la risposta breve: assicurati che il ldapmodulo sia rimosso dalla authenticatesezione e assicurati che il mschapmodulo sia presente sia authorizenella authenticatesezione che nella sezione. E ignora semplicemente la password "No" good good ".

E ora ecco la (lunghissima) risposta.

Come funziona il modulo ldap?

Quando attivi il ldapmodulo nella authorizesezione, questo è ciò che fa quando un pacchetto RADIUS viene ricevuto da FreeRADIUS:

1. prova a collegarsi al server LDAP (come utente guest o usando l'identità fornita se ne è configurata una ldap.conf)
2. cerca la voce DN dell'utente utilizzando il filtro sotto il DN di base (configurato in ldap.conf).
3. recupera tutti gli attributi LDAP che può ottenere tra quelli configurati ldap.attrmape li converte in Attributi RADIUS.
4. aggiunge tali attributi all'elenco degli elementi di controllo del pacchetto RADIUS.

Quando attivi il ldapmodulo nella authenticatesezione, questo è ciò che fa FreeRADIUS:

1. tenta di collegarsi al server LDAP come utente .
2. se può legarsi, allora è un'autenticazione corretta e un Radius-Acceptpacchetto verrà rispedito al client, oppure è un errore che porta a un Radius-Rejectpacchetto.

Quindi, come posso configurare FreeRADIUS per far funzionare PEAP / MS-CHAP-v2 con LDAP?

Il punto importante qui è che l'associazione in quanto l'utente funzionerà solo se il server FreeRADIUS può recuperare la password in chiaro dell'utente dal pacchetto RADIUS che ha ricevuto. Questo è solo il caso in cui vengono utilizzati i metodi di autenticazione PAP o TTLS / PAP (e possibilmente anche EAP / GTC). Solo il metodo TTLS / PAP è veramente sicuro e non è disponibile per impostazione predefinita in Windows. Se vuoi che i tuoi utenti si connettano con TTLS / PAP, devi far installare un software supplicant TTLS, che raramente è un'opzione. Il più delle volte, quando si distribuisce WiFi con WPA Enterprise in modo sicuro, PEAP / MS-CHAP-v2 è l'unica opzione ragionevole.

Quindi la linea di fondo è: a meno che non si stia utilizzando PAP o TTLS / PAP, è possibile rimuovere in sicurezza il ldapmodulo dalla authenticatesezione e, in realtà, è necessario: eseguire il binding poiché l'utente non funzionerà.

Se il test funziona quando lo usi radtest, probabilmente significa che il ldapmodulo è attivato nella authenticatesezione: proverà a collegarsi come utente e poiché radtest utilizza l'autenticazione PAP, avrà esito positivo. Ma fallirà se provi a connetterti attraverso il punto di accesso, poiché stai usando PEAP / MS-CHAP-v2.

Quello che dovresti fare è rimuovere il ldapmodulo dalla authenticatesezione e assicurarti di attivare il mschapmodulo sia authorizenella authenticatesezione che nella sezione. Quello che accadrà è che il mschapmodulo si occuperà dell'autenticazione usando l' NT-Passwordattributo che viene recuperato dal server LDAP durante la authorizefase.

Ecco come sites-enabled/defaultdovrebbe apparire il tuo file (senza tutti i commenti):

    ...
    authorize {
        preprocess
        suffix
        eap {
            ok = return
        }
        expiration
        logintime
    }
    authenticate {
        eap
    }
    ...

Ed ecco come sites-enabled/inner-tunneldovrebbe apparire il tuo file:

    ...
    authorize {
        mschap
        suffix
        update control {
               Proxy-To-Realm := LOCAL
        }
        eap {
            ok = return
        }
        ldap
        expiration
        logintime
    }
    authenticate {
        Auth-Type MS-CHAP {
            mschap
        }
        eap
    }
    ...

Che dire dell'avviso "Nessuna" password "valida"?

Bene, puoi tranquillamente ignorarlo. È proprio lì perché il ldapmodulo non è riuscito a trovare un UserPasswordattributo quando ha recuperato i dettagli dell'utente dal server LDAP durante la authorizefase. Nel tuo caso, hai l' NT-Passwordattributo e va benissimo per l' PEAP/MS-CHAP-v2autenticazione.

Immagino che l'avvertimento esista perché quando il ldapmodulo è stato progettato, PEAP/MS-CHAP-v2non esisteva ancora, quindi l'unica cosa che sembrava avere senso al momento era recuperare l'attributo UserPassword dal server LDAP, al fine di utilizzare PAP, CHAP, EAP / MD5 o tali metodi di autenticazione.

Cercherò di rispondere alla domanda OpenSSL qui: la risposta breve è usare FreeRADIUS 2.1.8 o successivo, che include OpenSSL . È disponibile nei backport Ubuntu Lucid e Debian Lenny (e probabilmente finirà anche nei backport Ubuntu Karmic).

Ecco la lunga risposta:

Sfortunatamente, la licenza OpenSSL era (in qualche modo) incompatibile con la licenza FreeRADIUS. Pertanto, la gente di Ubuntu ha scelto di fornire un binario FreeRADIUS non collegato a OpenSSL. Se si voleva EAP / TLS, PEAP o TTLS, si doveva trovare i sorgenti e compilarli con l' --with-opensslopzione (come la ricetta si è utilizzato, spiega).

Ma recentemente, il problema delle licenze è stato risolto . Le versioni di FreeRADIUS 2.1.8 o successive possono essere compilate e distribuite con OpenSSL. La cattiva notizia è che la distribuzione Ubuntu stabile più recente (Karmic Koala) include solo FreeRADIUS 2.1.0, senza OpenSSL (lo stesso vale per Debian, poiché Lenny contiene solo FreeRADIUS 2.0.4). Ho controllato i backport di Karmic, ma sembra che FreeRADIUS 2.1.8 o versioni successive non siano stati ancora caricati lì (ma potrebbe essere aggiunto presto, dai un'occhiata qui). Quindi per ora, è necessario passare a Ubuntu Lucid (che include FreeRADIUS 2.1.8) o attenersi alla compilazione. Per gli utenti Debian, le cose sono un po 'più luminose: i backport di Lenny includono FreeRADIUS 2.1.8. Quindi, se vuoi qualcosa di molto stabile, facile da installare e mantenere, ti suggerisco di distribuire un server con Debian Lenny e installare il pacchetto FreeRADIUS di backport (ti dà anche la possibilità di scrivere moduli Python gratuitamente, senza dover ricompilare con tutti i moduli sperimentali).

Ho ricevuto un certificato da http://CACert.org (probabilmente dovresti ottenere un certificato "reale" se possibile)

C'è un "gotcha" con certificati "reali" (al contrario dei certificati autofirmati).

Ne ho usato uno firmato da Thawte. Funziona bene e gli utenti vedono un bellissimo certificato "valido" chiamato qualcosa di simile www.my-web-site.com. Quando l'utente accetta il certificato, il suo computer in realtà comprende che tutti i certificati emessi dalla stessa autorità di certificazione dovrebbero essere considerati attendibili (l'ho verificato con Windows Vista e MacOSX Snow Leopard)! Quindi nel mio caso, se un hacker ha un certificato, per esempio, www.some-other-web-site.comfirmato anche da Thawte, allora può eseguire facilmente un attacco Man-in-the-middle, senza che nessun avviso venga visualizzato sul computer dell'utente!

La soluzione a questo sta nella configurazione di rete del computer dell'utente, al fine di specificare specificamente che solo "www.my-web-site.com" dovrebbe essere considerato attendibile. Ci vuole solo un minuto, ma la maggior parte degli utenti non saprà dove configurarlo a meno che non si dia loro una procedura chiara e si assicuri che ogni utente lo segua. Uso ancora certificati "validi", ma francamente è deludente vedere che sia Windows che MacOSX condividano questo "bug": affidarsi all'Autorità di certificazione invece del certificato specifico. Ahia...

Secondo la segnalazione di bug, una semplice ricostruzione di FreeRADIUS dovrebbe risolvere il problema del supporto OpenSSH. Deve essere fatto solo una volta.

Non sono sicuro della facilità di amministrazione dell'installazione. Spesso, più è coinvolta e dettagliata la configurazione, più è facile amministrarla, poiché la configurazione copriva tutte le basi. Vuoi dire che la configurazione deve essere rilasciata facilmente anche su altri server? Quante LAN wireless stai configurando?

Una volta configurato, l'amministrazione dovrebbe essere limitata alle aggiunte, eliminazioni e modifiche dell'utente LDAP. Questi dovrebbero essere abbastanza facili da eseguire uno script con ldapmodify (et al) o trovare un front-end grafico LDAP decente e documentare i processi con schermate.

Ho riscontrato lo stesso problema. Ho dovuto scaricare i sorgenti RADIUS e compilarli da solo.

Puoi usare FreeRADIUS2 (con OpenSSL) + EAP-TLS + WPA2-Enterprice. Ecco come fare con le dita . Windows XP SP3 ha il supporto nativo e Windows 7, Android 2.3, iPhone, Symbian. Ma non conosco la compatibilità con SLDAP in un tale schema.