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:
1. il primo record definisce l'utente test con password mypassword (utile per i test e per il monitoring)
2. il secondo record demanda al modulo kerberos l'autenticazione degli utenti con username del tipo: <username>@lnf.infn.it
3. 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
4. il quarto record, forse e' inutile, ma rifiuta l'autenticazione di chi inserisce la username con realm DEFAULT (per motivi di sicurezza)
5. 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)
6. 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!

Buona fortuna!

— Massimo Pistoni 2012/03/29 23:00

Table of Contents