Table of Contents
Configurazione Radius v3 per INFN-dot1x
Ai LNF e' stata implementata la rete wireless INFN-dot1x secondo le specifiche del progetto TRIP per l'accesso ai servizi informatici dedicato ai dipendenti dell'INFN.
La soluzione tecnica prevede l'annuncio di una rete WL con SSID INFN-dot1x su VLAN dedicata a cui e' attribuita una network IP pubblica "di classe C", avente gli stessi diritti di accesso alle risorse informatiche fornite dai Laboratori, rispetto ai nodi connessi alla LAN in modalita' wired.
Radius Server
Questo documento fornisce una guida per l'installazione e la configurazione di un radius server locale per l'autorizzazione alla connessione sulla rete wireless INFN-dot1x. Seguendo le indicazioni si potra' costruire un server radius in grado di demandare (via proxy) tutte le autenticazioni di tipo EAP-TTLS e PEAP ai realm INFN diversi da lnf.infn.it, ma anche in grado di autenticare autonomamente tutte le richieste di tipo EAP-TLS (purche' l'utente si presenti con un certificato personale rilasciato dalla CA TERENA), ma anche di tipo EAP-TTLS e PEAP-MSCHAPv2 tramite l'inserimento delle credenziali kereberos dei LNF.
- Installare l'ultima versione di Freeadius (quella attualmente testata e sperimentata e' la v. 3.2.4; il server radius dei LNF per il servizio INFN-dot1x si chiama radius3.lnf.infn.it).
- Posizionarsi nella directory ove sono situati i file di configurazione (ad esempio: /usr/custom/freeradius/etc/raddb/)
radiusd.conf
- Modificare radiusd.conf (esempio di file completo) secondo le esigenze di sede; in particolare:
potrebbe essere utile impostare opportunamente la sezione log per inviare i log ad un logserver remoto, invece che su file locale:
log {
...
destination = syslog
...
syslog_facility = local6
...
}
eap
- Modificare ../mod-available/eap secondo le esigenze di sede; in particolare:
eap {
...
default_eap_type = ttls
...
tls {
...
##private_key_password = whatever
## Inserire i nomi dei files rispettivamente della chiave privata e del certificato x509 (rilasciato dalla CA INFN)
private_key_file = ${certdir}/myradius-key.pem
certificate_file = ${certdir}/myradius-cert.pem
...
## inserire il file contenente tutti i certificati pubblici delle seguenti CA: INFN e TERENA
## Attenzione!: per potersi autenticare con i certificati TERENA e' necessario aggiungere anche i certificati
## di COMODO (root CA) e UTN-USERFirst-Client-Authentication-and-Email (Intermediate CA) [Vedi file INFN-TERENA-CA.pem allegato]
ca_file = ${cadir}/myradius-chain.pem
...
fragment_size = 1200
check_cert_cn = %{User-Name}
...
}
...
ttls {
...
##default_eap_type = md5
...
copy_request_to_tunnel = yes
...
use_tunneled_reply = yes
...
virtual_server = "inner-tunnel"
...
}
...
peap {
...
default_eap_type = mschapv2
...
copy_request_to_tunnel = yes
...
use_tunneled_reply = yes
...
virtual_server = "inner-tunnel"
...
}
...
}
Allegato: INFN-TERENA-CA.pem
proxy.conf
- Modificare proxy.conf secondo le esigenze di sede; in particolare modificare la definizione dei realm a cui demandare le richieste di autenticazione. Per la configurazione e' importante concordare le <secret password> con i gestori dei radius server dei realm remoti:
home_server localhost {
...
secret = mysecret1
...
}
home_server radius.infn.it {
type = auth+acct
ipaddr = 193.206.190.118
port = 1812
secret = mysecret2
require_message_authenticator = yes
response_window = 20
zombie_period = 40
revive_interval = 60
status_check = status-server
check_interval = 30
num_answers_to_alive = 3
max_outstanding = 65536
coa {
irt = 2
mrt = 16
mrc = 5
mrd = 30
}
}
home_server radius2.infn.it {
type = auth+acct
ipaddr = 193.206.144.38
port = 1812
secret = mysecret2
require_message_authenticator = yes
response_window = 20
zombie_period = 40
revive_interval = 60
status_check = status-server
check_interval = 30
num_answers_to_alive = 3
max_outstanding = 65536
coa {
irt = 2
mrt = 16
mrc = 5
mrd = 30
}
}
home_server_pool radius-infn-pool {
type = load-balance
home_server = radius.infn.it
home_server = radius2.infn.it
}
...
realm LOCAL {
# If we do not specify a server pool, the realm is LOCAL, and
# requests are not proxied to it.
}
...
realm NULL {
authhost = LOCAL
accthost = LOCAL
nostrip
}
...
realm lnf.infn.it {
authhost = LOCAL
accthost = LOCAL
strip
}
...
realm "~^(.+\\.|)infn\\.it$" {
pool = radius-infn-pool
nostrip
}
...
realm DEFAULT {
authhost = LOCAL
accthost = LOCAL
nostrip
}
clients.conf
- Modificare clients.conf secondo le esigenze di sede; in particolare aggiungere in lista la definizione di tutti i client. Per la configurazione e' importante concordare le <secret password> con i gestori degli client (o degli access point) remoti:
client localhost {
...
secret = mysecret
...
}
...
#
# Definizione relativa al server stesso (radius.lnf.infn.it)
#
client radius.lnf.infn.it {
secret = mysecret
shortname = radius
nastype = other
}
#
# Definizione relativa al radius server di autenticazione dei LNF su rete wireless eduroam (edugw.lnf.infn.it)
#
client edugw.lnf.infn.it {
secret = mysecret
shortname = edugw
nastype = other
}
#
# Definizione (eventuale) del server di monitoring (Nagios)
#
client 193.206.84.50 {
secret = mysecret
shortname = nagios
nastype = other
}
#
# Proxy INFN (TRIP per SSID INFN-dot1x)
#
client radius.infn.it {
ipaddr = 193.206.190.118
secret = mysecret2
shortname = TRIP-INFN-dot1x-1
nastype = other
}
client radius2.infn.it {
ipaddr = 193.206.144.38
secret = mysecret2
shortname = TRIP-INFN-dot1x-2
nastype = other
}
#
# Definizione del server proxy del GARR (DEFAULT GARR)
#
#client 192.84.145.15 {
# secret = mysecret2
# shortname = eduroam
# nastype = other
#}
#
# VPNBOX dei LNF
#
client 193.206.84.7 {
secret = mysecret
shortname = vpnbox
nastype = cisco
}
#
# Captive Portal
#
client 193.205.228.106 {
secret = mysecret
shortname = tino
nastype = other
}
#
# Definizione del Wireless LAN Controller WLC4400 AP Ports IP
#
client 172.16.14.18 {
secret = mysecret
shortname = wlc4400
nastype = cisco
}
client 172.16.14.19 {
secret = mysecret
shortname = wlc4400ap
nastype = cisco
}
#
# Elenco degli aironet dei LNF ordinati per IP Address (o N. di edificio)
#
client 172.16.1.2 {
secret = mysecret
shortname = ed1ap1
nastype = cisco
}
...
etc.
...
In alternativa alla definizione dell'elenco dei client ad uno ad uno, dovrebbe essere possibile anche inserire tutta una network (soluzione non testata):
client 172.16.0.0/16 {
secret = mysecret
shortname = accesspoint
nastype = cisco
}
modules/logger-accept e modules/logger-reject
- Al fine di specializzare i log, in modo che venga scritto anche il subject del certificato dell'utente che tenta l'autenticazione via EAP-TLS, e' necessario creare 2 nuovi moduli di radius: logger-accept e logger-reject
- Creare logger-accept in modo che contenga la stringa di log per le richieste di autenticazione EAP-TLS accettate; vedi esempio:
exec logger-accept {
wait = yes
#radiuspid = "%{exec:/bin/cat ${pidfile}}"
outlog = "Access Accepted in Post-Auth session for user [%{User-Name}] [Issuer: %{TLS-Client-Cert-Issuer} - Subject: %{TLS-Client-Cert-Subject}]"
program = "/usr/bin/logger -p local6.info -t radiusd[$pid$] ${outlog}"
input_pairs = request
output_pairs = reply
#packet_type = Access-Accept
shell_escape = yes
}
- Creare logger-reject in modo che contenga la stringa di log per le richieste di autenticazione EAP-TLS rifiutate; vedi esempio:
exec logger-reject {
wait = yes
#radiuspid = "%{exec:/bin/cat ${pidfile}}"
outlog = "Access Rejected in Post-Auth session for user [%{User-Name}] due to local policy [Issuer: %{TLS-Client-Cert-Issuer} - Subject: %{TLS-Client-Cert-Subject}]"
program = "/usr/bin/logger -p local6.info -t radiusd[$pid$] ${outlog}"
input_pairs = request
output_pairs = reply
#packet_type = Access-Accept
shell_escape = yes
}
- Nota: non sono riuscito a far scrivere il pid del processo radiusd nel log, ma non e' molto importante.
sites-enabled/default
- Modificare default secondo le esigenze di sede; in particolare e' importante abilitare i desiderati metodi di autenticazione e di autorizzazione:
...
authorize {
...
preprocess
...
chap
...
mschap
...
suffix
...
eap {
ok = return
}
...
files
...
expiration
logintime
...
pap
...
}
...
Authenticate {
...
Auth-Type PAP {
pap
}
...
Auth-Type CHAP {
chap
}
...
Auth-Type MS-CHAP {
mschap
}
...
Auth-Type Kerberos {
krb5
}
...
ntlm_auth
...
eap
...
}
- e inserire i controlli sul certificato dell'utente nella sessione post-authentication:
...
post-auth {
...
# update reply {
# Reply-Message += "%{TLS-Cert-Serial}"
# Reply-Message += "%{TLS-Cert-Expiration}"
# Reply-Message += "%{TLS-Cert-Subject}"
# Reply-Message += "%{TLS-Cert-Issuer}"
# Reply-Message += "%{TLS-Cert-Common-Name}"
#
# Reply-Message += "%{TLS-Client-Cert-Serial}"
# Reply-Message += "%{TLS-Client-Cert-Expiration}"
# Reply-Message += "%{TLS-Client-Cert-Subject}"
# Reply-Message += "%{TLS-Client-Cert-Issuer}"
# Reply-Message += "%{TLS-Client-Cert-Common-Name}"
# }
...
### if ( TLS-Client-Cert-Subject !~ /^$/ ) {
### if ( TLS-Client-Cert-Issuer != "/C=NL/O=TERENA/CN=TERENA Personal CA" ) {
### logger-reject
### reject
### }
### if ( TLS-Client-Cert-Subject !~ /^\/C=IT\/O=Istituto Nazionale di Fisica Nucleare\/CN=.+$/ ) {
### logger-reject
### reject
### }
### else {
### logger-accept
### }
### }
###
if ( TLS-Client-Cert-Subject !~ /^$/ ) {
if ( TLS-Client-Cert-Issuer != "/C=NL/O=TERENA/CN=TERENA Personal CA" && TLS-Client-Cert-Issuer != "/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA Personal CA 3" ) {
logger-reject
reject
}
if ( TLS-Client-Cert-Subject !~ /^\/C=IT.*\/O=Istituto Nazionale di Fisica Nucleare\/CN=.+$/ ) {
logger-reject
reject
}
else {
logger-accept
}
}
...
}
sites-enabled/inner-tunnel
Il server inner-tunnel viene chiamato in causa nel caso di richiesta di autenticazione passata all'interno di un tunnel (PEAP o EAP-TTLS)
- Modificare inner-tunnel secondo le esigenze di sede; in particolare e' importante abilitare i desiderati metodi di autenticazione e di autorizzazione:
server inner-tunnel {
...
authorize {
...
chap
...
mschap
...
suffix
...
...
eap {
ok = return
}
...
files
...
expiration
logintime
...
pap
...
# if ( "%{outer.request:User-Name}" != "%{User-Name}" ) {
# fail
# }
}
...
Authenticate {
...
Auth-Type PAP {
pap
}
...
Auth-Type CHAP {
chap
}
...
Auth-Type MS-CHAP {
mschap
}
...
Auth-Type Kerberos {
krb5
}
...
ntlm_auth
...
eap
...
}
...
}
- Nota: le ultime righe (commentate) nella sezione authorize e' necessario scommentarle qualora si voglia impedire l'autenticazione con outer-identity diversa da inner-identity
modules/krb5
- Se si vuole demandare l'autenticazione a kerberos, creare il principal per il servizio radius ed esportare il keytab relativo sul server radius, ad esempio nel file krb/.radius.keytab
- Assegnare al file le giuste protezioni di accesso:
chmod g-r,o-r krb/.radius.keytab
- Quindi creare il file modules/krb5; vedi esempio:
krb5 {
keytab = ${raddbdir}/krb/.radius.keytab
service_principal = radius/radius.lnf.infn.it
}
users
- Modificare il file users secondo le esigenze di sede; puo' essere utile aggiungere un utente locale di test per la verifica della funzionalita' del radius server; puo' essere utilizzato anche dal server di monitoring Nagios:
test Auth-Type := Local, Cleartext-Password := "mypassword"
DEFAULT Auth-Type = Kerberos, Realm == "lnf.infn.it"
DEFAULT Proxy-To-Realm := "~^(.+\\.|)infn\\.it$", Realm == "~^(.+\\.|)infn\\.it$"
DEFAULT Auth-Type := Reject, Realm == "DEFAULT"
$INCLUDE users.guests
DEFAULT Auth-Type = Kerberos, Realm == "NULL"
Fall-Through = Yes
- Nota: lasciare una riga vuota sotto ogni entry del file users
- Nell'esempio:
- il primo record definisce l'utente test con password mypassword (utile per i test e per il monitoring)
- il secondo record demanda al modulo kerberos l'autenticazione degli utenti con username del tipo: <username>@lnf.infn.it
- il terzo record demanda al proxy radius INFN (TRIP, definito nel file proxy.conf) la autenticazione degli utenti aventi username del tipo: <username>@infn.it oppure <username>@<sede>.infn.it
- il quarto record, forse e' inutile, ma rifiuta l'autenticazione di chi inserisce la username con realm DEFAULT (per motivi di sicurezza)
- il quinto record include un file con utenti locali (di tipo username e Cleartext-Password) aggiornato periodicamente dal database di Gestione Ospiti e Visitatori per l'accesso tramite Captive Portal tino (vedi sotto)
- il sesto record demanda al modulo kerberos l'autenticazione degli utenti con username del tipo: <username> (con realm sottinteso @lnf.infn.it)
Configurazione opzionale per abilitare l'autenticazione PEAP-EAP/TLS
Se non si vuole abilitare l'autenticazione PEAP-EAP/TLS saltare al paragrafo successivo (Start del server radius).
Il protocollo di autenticazione PEAP-EAP/TLS e' utilizzato esclusivamente dai supplicant con sistema operativo MS-Windows. Windows permette di configrare nativamente tale protocollo, che consente di effettuare l'autenticazione tramite presentazione del certificato, come per EAP/TLS, ma dentro un tunnel PEAP che seguirebbe quindi la strada dei proxy, in funzione del realm della username. Ovvero l'autenticazione, invece di essere effettuata dal server radius locale (della WLAN a cui ci si sta connettendo), verrebbe effettuata dal server della sede di appartenenza.
Volendo abilitare l'autenticazione PEAP-EAP/TLS, occorre fare in modo che radius generi una seconda istanza di eap (inner-eap); seguire i seguenti passi:
modules/inner-eap
- Modificare il file modules/inner-eap
eap inner-eap {
...
default_eap_type = tls
...
mschapv2 {
}
...
tls {
...
certdir = ${confdir}/certs
cadir = ${confdir}/certs
...
##private_key_password = whatever
## Inserire i nomi dei files rispettivamente della chiave privata e del certificato x509 (rilasciato dalla CA INFN)
private_key_file = ${certdir}/myradius-cainfn-key.pem
certificate_file = ${certdir}/myradius-cainfn-cert.pem
...
## inserire il file contenente tutti i certificati pubblici delle seguenti CA: INFN e TERENA
## Attenzione!: per potersi autenticare con i certificati TERENA e' necessario aggiungere anche i certificati
## di COMODO (root CA) e UTN-USERFirst-Client-Authentication-and-Email (Intermediate CA) [Vedi file INFN-TERENA-CA.pem allegato]
CA_file = ${cadir}/INFN-TERENA-CA.pem
...
## Attenzione il fragment size deve essere inferiore a quello definito nel file eap.conf (valori consigliati
## sono: 1200 in eap.conf e 1024 in modules/inner-eap
fragment_size = 1024
...
## attenzione: commentare la seguente riga:
##check_cert_cn = %{User-Name}
...
}
...
}
eap.conf
- Modificare il file eap.conf
eap {
...
tls {
...
## attenzione: commentare la seguente riga:
##check_cert_cn = %{User-Name}
...
}
...
}
sites-enabled/inner-tunnel
- Modificare il file sites-enabled/inner-tunnel in modo che punti al modulo inner-eap anziche' ad eap, e inoltre inserire anche qui i controlli sul certificato dell'utente nella sessione post-authentication:
server inner-tunnel {
...
authorize {
...
inner-eap {
ok = return
}
...
}
...
Authenticate {
...
inner-eap
...
}
...
post-auth {
...
/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA Personal CA 3
if ( TLS-Client-Cert-Subject !~ /^$/ ) {
if ( TLS-Client-Cert-Issuer != "/C=NL/O=TERENA/CN=TERENA Personal CA" && TLS-Client-Cert-Issuer != "/C=NL/ST=Noord-Holland/L=Amsterdam/O=TERENA/CN=TERENA Personal CA 3" ) {
logger-reject
reject
}
if ( TLS-Client-Cert-Subject !~ /^\/C=IT.*\/O=Istituto Nazionale di Fisica Nucleare\/CN=.+$/ ) {
logger-reject
reject
}
else {
logger-accept
}
}
...
}
- Nota: Affinche' l'autenticazione PEAP-EAP/TLS venga demandata via proxy al server radius della propria sede, occorre configurare il supplicant in modo che venga impostata una username diversa dal common name del certificato (tipicamente selezionando "Use a different user name for the connection"). Al momento dell'autenticazione verra' proposto un pop-up in cui sara' possibile modificare tale username; a questo punto appendere alla username proposta dal pop-up il realm della propria sede (ad esempio: Massimo Pistoni@lnf.infn.it).
Start del server radius
- Prima dello start occorre modificare la proprieta' e le protezioni dei file di configurazione
chown -R radiusd:radiusd * chmod -R u+rw,g+r,o+r * chmod -R g-r,o-r certs/*
- Lanciare il servizio in debug mode:
/usr/custom/freeradius/sbin/radiusd -X
oppure (piu' verboso):
/usr/custom/freeradius/sbin/radiusd -Xxx
- Lanciare il servizio come daemon:
/etc/init.d/radiusd start
- Start automatico al boot
chkconfig --add radiusd chkconfig --level 35 radiusd on
- Eseguire un banale test di autenticazione:
/usr/custom/freeradius/bin/radtest test mypassword localhost 10 mysecret
(verificare il file di log /var/log/messages)
Aggiornamento del file delle autenticazioni per i visitatori
Per le sedi che usano l'applicazione a valenza nazionale per la Gestione Ospiti (o piu' propriamente Gestione Visitatori), e' possibile sincronizzare sul radius server le username che possono avere accesso alla rete INFN-Web tramite il Captive Portal tino.
- Creare il file GOsync.sh
- All'interno dello script, modificare nel comando wget la linea sotto indicata inserendo la username e la password assegnate alla sede (senza l'apice iniziale):
'--post-data='USER=<sede>&PASS=<GOpassword_for_sede>&USER_FORMAT=#USER##TAB##TAB#Auth-Type+:=+Local,+Cleartext-Password+:=+"#PWD#"#NL#' \
- Quindi inserire lo script GOsync.sh a crontab con la seguente linea (senza l'apice iniziale):
'*/10 * * * * /usr/custom/bin/GOsync.sh
- In tal modo lo script aggiornera' ogni 10 minuti il file users.guests sincronizzando le credenziali dei visitatori che hanno accesso autorizzato nella vostra sede
- Tale file viene utilizzato dal radius server per l'autenticazione dei visitatori tramite il Captive Portal della Wireless LAN con SSID INFN-Web
Configurazione del metodo di autenticazione PEAP-MSCHAPv2 --> KerberosV MIT
Per le sedi che usano kerberosV come protocollo di autenticazione, e' possibile fare in modo che l'autenticazione di tipo PEAP-MSCHAPv2 venga demandata a kerberosV. PEAP-MSCHAPv2 e' il metodo standard di autenticazione dei supplicant Windows ed e' supportato anche dalle piattaforme Mac OS X e Linux.
Nota: perche' cio' sia possibile occorre che il kdc sia configurato per supportare l'encryption "arcfour-hmac:normal" (che corrisponde all'hash della password utilizzato da NTLM). Se non lo fosse occorre aggiungere tale encryption nel kdc.conf e forzare un cambio password, per gli utenti interessati, per poter utilizzare l'encryption appena inserita.
Per implementare tale metodo di autenticazione c'e' necessita' di creare una nuova struttura di tipo client-server basata sul servizio kcrap. Kcrap e' un s/w free realizzato da Jonathan Chen e modificato da Dan Fuhry per adattarlo all'uso con freeradius
Riferimenti:
Il s/w con le modifiche di Dan Fuhry, e' stato installato e testato ai LNF da Sandro Angius. Tuttavia, per eliminare qualche piccolo malfunzionamento e per adattarlo alle esigenze dell'INFN, Sandro ha dovuto effettuare alcune modifiche, di cui le piu' importanti sono:
- eliminazione della parte che esegue la patch a freeradius (questo step e' fondamentale per poter liberamente installare le nuove versioni di freeradius via via che vengono rilasciate, senza dipendere dal rilascio di patch aggiornate di kcrap)
- conseguente realizzazione di un task aggiuntivo, chiamato kcrapclient, con le funzioni di interfaccia tra freeradius e kcrap server
- ritorno della NT_KEY con cifratura MD4 da parte del server verso il client (suggerito da Sandro e realizzato da Dan)
- inserimento dei log sulla parte kcrap server
- inserimento di output di debug ed eliminazione di alcuni bug
- aggiunta qua e la di istruzioni per cancellazione e/o eliminazione di buffer di memoria non piu' usati.
Alcune di queste modifiche sono state inglobate da Dan Fuhry nella sua versione del s/w. A seguito di queste modifiche sono stati creati due nuovi pacchetti di distribuzione (by Sandro Angius):
Il primo e' da utilizzare per chi ha kerberosV MIT versione 1.6, il secondo e' da utilizzare per chi ha kerberosV MIT versione 1.9. Il primo tarball dovrebbe funzionare anche con kerberosV versione 1.7, ma non e' stato testato con tale versione. Infatti soltanto nella versione 1.9 di kerberosV cambia il metodo di accesso al DB delle credenziali, ed e' per questo che il kcrap server e' stato modificato per quella versione.
Installazione di kcrap server
Il s/w kcrap server va installato su un kdc. Per motivi di sicurezza, e' caldamente consigliato di utilizzare un secondary kdc. Per installare kcrap server e' necessario rispettare i seguenti prerequisiti:
- avere installato i seguenti RPMs:
- openssl-devel
- krb5-devel
Per l'installazione seguire i seguenti passi:
- si consiglia di avere anche i sorgenti kerberosV della versione installata sul server kdc, altrimenti kcrap utilizzera' un kdb.h stub che potrebbe non essere compatibile. Se i sorgenti di kerberos sono gia' stati installati, passare allo step successivo.
mkdir /root/kcrap cd /root/kcrap wget http://web.mit.edu/kerberos/dist/krb5/1.6/krb5-1.6.1-signed.tar tar xf krb5-1.6.1-signed.tar tar xzf krb5-1.6.1.tar.gz cd krb5-1.6.1/src/ ./configure
- scaricare il tarball di kcrap (versione LNF) ed eseguire i seguenti comandi (modificare il prefix secondo le proprie necessita' e modificare il with-mit-krb5-src con l'indicazione ove sono gli include files dei sorgenti di kerberos):
tar xzf kcrap-0.2.3-LNF.tgz cd kcrap-0.2.3-LNF/ ./configure --prefix=/usr/custom/kcrap --with-mit-krb5-src=/root/kcrap/krb5-1.6.1/src/include/ --with-server CFLAGS=-I/usr/include/et LIBS=-lkadm5srv make make install ln -s /usr/custom/kcrap/lib/libkcrap.so /usr/lib/libkcrap.so ldconfig
- creare il file /etc/kcrap_server.conf, ad esempio:
[kcrap_server]
port = 1999
realm = LNF.INFN.IT
[realms]
LNF.INFN.IT = {
database_name = /var/kerberos/krb5kdc/principal
key_stash_file = /var/kerberos/krb5kdc/.k5.LNF.INFN.IT
}
- Nella sezione 'logging' del file /etc/krb5.conf inserire una riga del tipo:
...
[logging]
kcrap_server = SYSLOG:INFO:LOCAL3 ## metodo consigliato: i log vengono inviati al SYSLOG con severity INFO e facility LOCAL3
##kcrap_server = FILE:/var/log/kcrap.log ## metodo sconsigliato, alcuni errori non avrebbero il formato con data e ora, etc.
...
- Opzionalmente si puo' configurare la parte client anche sul server (per effettuare test di funzionamento); modificare il file /etc/krb5.conf alla sezione 'realms', nel proprio dominio kerberos, e inserire una riga del tipo (inserire il nodo stesso):
...
[realms]
LNF.INFN.IT = {
...
...
kcrap = kcrapsrv1.lnf.infn.it:1999
}
...
- Configurare iptables per consentire l'accesso al kcrap server solo dai radius server autorizzati; per ogni radius server inserire una regola del tipo:
iptables -A INPUT -m state --state NEW -s 193.206.84.29/255.255.255.255 -m udp -p udp --dport 1999 -j ACCEPT
(ovviamente prima della necessaria direttiva di drop finale dei pacchetti udp)
- Creare il file /etc/init.d/kcrap (segue esempio):
#!/bin/bash
#
# kcrap_server Start and stop the KCRAP server.
#
# chkconfig: - 35 65
# description: Kerberos Challenge Response Authentication Protocol Daemon.
# processname: kcrap_server
# config: /etc/sysconfig/kcrap_server
#
# Get config.
. /etc/sysconfig/network
# Get config.
[ -r /etc/sysconfig/kcrap_server ] && . /etc/sysconfig/kcrap_server
# Source function library.
. /etc/rc.d/init.d/functions
RETVAL=0
prog="KCRAP Server"
kcrap_server=/usr/custom/kcrap/sbin/kcrap_server
# Sheel functions to cut down on useless shell instances.
start() {
[ -x $kcrap_server ] || exit 5
echo -n $"Starting $prog: "
daemon ${kcrap_server}
RETVAL=$?
echo
[ $RETVAL = 0 ] && touch /var/lock/subsys/kcrap_server
}
stop() {
echo -n $"Stopping $prog: "
killproc ${kcrap_server}
RETVAL=$?
echo
[ $RETVAL = 0 ] && rm -f /var/lock/subsys/kcrap_server
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
status)
status ${kcrap_server}
RETVAL=$?
;;
condrestart)
if [ -f /var/lock/subsys/kcrap_server ] ; then
stop
start
fi
;;
*)
echo $"Usage: $0 {start|stop|status|restart|condrestart}"
RETVAL=2
;;
esac
exit $RETVAL
- Lanciare il servizio come daemon:
/etc/init.d/kcrap start
- Start automatico al boot
chkconfig --add kcrap chkconfig --level 35 kcrap on
Procedure di postinstallazione:
Per testare che tutto funzioni, creare temporaneamente l'utente kerberos con username user e password SecREt01, quindi lanciare il seguente comando:
## /usr/custom/kcrap/bin/kcrapclient <username> <challenge> <response> /usr/custom/kcrap/bin/kcrapclient user 0123456789abcdef 25a98c1c31e81847466b29b2df4680f39958fb8c213a9cc6
e verificare che la stringa di ritorno sia:
NT_KEY: 3f373ea8e4af954f14faa506f8eebdc4
verificare anche che cambiando una cifra (esadecimale) della challenge o della response l'autenticazione fallisce.
Note:
Se il syslog e' configurato per i livelli a partire da info il log sara' del tipo:
Mar 27 17:21:18 kdcs3 kcrap[8649]: Kcrap server started. Mar 27 17:21:26 kdcs3 kcrap[8649]: Authentication for username 'user' from 193.206.84.123 succeeded. Mar 27 17:21:28 kdcs3 kcrap[8649]: Authentication for username 'user' from 193.206.84.123 failed. Mar 27 17:27:07 kdcs3 kcrap[8649]: Authentication for username 'user' from 193.205.228.102 succeeded. Mar 27 17:27:08 kdcs3 kcrap[8649]: Authentication for username 'user' from 193.205.228.102 failed.
mentre con i livelli da debug si ottiene:
Mar 27 17:27:09 kdcs3 kcrap[8649]: Datagram of 600 bytes received from address: 193.206.84.123. Mar 27 17:27:09 kdcs3 kcrap[8649]: Request for username 'user' from 193.206.84.123 with challenge 0xbd50a3fccd292811. Mar 27 17:27:09 kdcs3 kcrap[8649]: Authentication for username 'user' from 193.206.84.123 succeeded. Mar 27 17:27:10 kdcs3 kcrap[8649]: Datagram of 600 bytes received from address: 193.206.84.123. Mar 27 17:27:10 kdcs3 kcrap[8649]: Request for username 'user' from 193.206.84.123 with challenge 0xbd50a3fccd292811. Mar 27 17:27:10 kdcs3 kcrap[8649]: Authentication for username 'user' from 193.206.84.123 succeeded.
Installazione di kcrap client
Per installare kcrapclient sul server radius e' necessario rispettare i seguenti prerequisiti:
- avere installato i seguenti RPMs:
- krb5-libs
- krb5-devel
Quindi seguire le istruzioni:
- scaricare il tarball di kcrap (versione LNF) ed eseguire i seguenti comandi (modificare il prefix secondo le proprie necessita'):
tar xzf kcrap-0.2.3-LNF.tgz cd kcrap-0.2.3-LNF/ ./configure --prefix=/usr/custom/kcrap CFLAGS=-I/usr/include/et LIBS=-lkadm5srv make make install ln -s /usr/custom/kcrap/lib/libkcrap.so /usr/lib/libkcrap.so ldconfig
- modificare il file /etc/krb5.conf alla sezione 'realms', nel proprio dominio kerberos, e inserire delle righe del tipo (una per ogni kcrapserver):
...
[realms]
LNF.INFN.IT = {
...
...
kcrap = kcrapsrv1.lnf.infn.it:1999
kcrap = kcrapsrv2.lnf.infn.it:1999
kcrap = kcrapsrv3.lnf.infn.it:1999
}
...
- Accertarsi che radiusd (owner del radius daemon) abbia i diritti di esecuzione di kcrapclient, altrimenti:
chmod a+rx /usr/custom/kcrap/bin/kcrapclient
- Se non esiste gia', creare e posizionare in /etc il keytab file (krb5.keytab) per il radius server del tipo:
- host/<FQDN>@REALM
e dare i diritti di lettura a radiusd (owner del radius daemon):
chown root:radiusd /etc/krb5.keytab chmod g+r /etc/krb5.keytab
Procedure di postinstallazione:
Per testare che tutto funzioni, lanciare il seguente comando:
## /usr/custom/kcrap/bin/kcrapclient <username> <challenge> <response> /usr/custom/kcrap/bin/kcrapclient user 0123456789abcdef 25a98c1c31e81847466b29b2df4680f39958fb8c213a9cc6
e verificare che la stringa di ritorno sia:
NT_KEY: 3f373ea8e4af954f14faa506f8eebdc4
verificare anche che cambiando una cifra (esadecimale) della challenge o della response l'autenticazione fallisce.
Integrazione con freeradius
Una volta installato kcrap (server e client) si puo' fare in modo che l'autenticazione PEAP-MSCHAPv2 venga demandata da freeradius a kerberos tramite kcrap:
* Modificare il file modules/mschap
...
mschap {
...
## ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"
ntlm_auth = "/usr/custom/kcrap/bin/kcrapclient %{%{Stripped-User-Name}:-%{%{User-Name}:-None}} %{%{mschap:Challenge}:-00} %{%{mschap:NT-Response}:-00}"
...
}
* Quindi far ripartire freeradius
/etc/init.d/radiusd restart
A questo punto si puo' provare a configurare un supplicant affinche' utilizzi il protocollo di autenticazione PEAP-MSCHAPv2, e tentare l'autenticazione con le proprie credenziali kerberos
Nota: quando tutto funziona, ricordarsi di rimuovere la username user da kerberos!