INFN wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Configurazione Radius v3 per INFN-dot1x ======

Ai LNF e' stata implementata la rete wireless INFN-dot1x secondo le specifiche del progetto [[http://www.ccr.infn.it/index.php?option=com_content&task=view&id=46&Itemid=86|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 {{:strutture:lnf:dr:calcolo:wireless:radius_radius.conf|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 {{:strutture:lnf:dr:calcolo:wireless:radius_eap.conf|../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: {{:strutture:lnf:dr:calcolo:wireless:radius_infn-terena-ca.pem.txt|INFN-TERENA-CA.pem}}


====== ======

**proxy.conf**

  * Modificare {{:strutture:lnf:dr:calcolo:wireless:radius_proxy.conf|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 {{:strutture:lnf:dr:calcolo:wireless:radius_clients.conf|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: {{:strutture:lnf:dr:calcolo:wireless:logger-accept.txt|logger-accept}} e {{:strutture:lnf:dr:calcolo:wireless:logger-reject.txt|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 {{:strutture:lnf:dr:calcolo:wireless:radius_default.txt|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 {{:strutture:lnf:dr:calcolo:wireless:radius_inner-tunnel.txt|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 {{:strutture:lnf:dr:calcolo:wireless:radius_krb5.txt|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 {{:strutture:lnf:dr:calcolo:wireless:radius-inner-eap.txt|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 {{:strutture:lnf:dr:calcolo:wireless:gosync.sh.txt|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 [[http://www.spock.org/|Jonathan Chen]] e modificato da [[http://fuhry.us/|Dan Fuhry]] per adattarlo all'uso con freeradius

Riferimenti: 
  * http://www.spock.org/kcrap/
  * http://fuhry.us/blog/2012/01/01/mschapv2-against-mit-kerberos-yes-you-can/

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):

  * {{:strutture:lnf:dr:calcolo:wireless:kcrap-0.2.3-lnf-k5-1.6.tgz|kcrap-0.2.3-LNF-k5-1.6.tgz}}
  * {{:strutture:lnf:dr:calcolo:wireless:kcrap-0.2.3-lnf-k5-1.9.tgz|kcrap-0.2.3-LNF-k5-1.9.tgz}}

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 {{:strutture:lnf:dr:calcolo:wireless:kcrap.txt|/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 {{:strutture:lnf:dr:calcolo:wireless:radius_mschap.txt|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@lnf.infn.it|Massimo Pistoni]] 2012/03/29 23:00//