Configuring FreeRadius with LDAP for WPA2 Enterprise

Question

I need help configuring freeradius with WPA2 Enterprise via LDAP.

LDAP normally works for other services, however, it does not work for WPA2E.

We have also managed WPA2E to work with hard coded username/password fine. So we know all the components on their own work, but do not work together.

We have the freeradius server configured fine to work with the LDAP service.

Any help is appreciated

Here is my ldap setting for free radius modules/ldap file (mostly irrelevant for this issue)

ldap {
    server = "ldapmaster.domain.com,ldapslave.domain.com"
    identity = "uid=binder,ou=services,dc=security,dc=domain,dc=com"
    password = asdfasdfasdf
    basedn = "ou=internal,ou=users,dc=security,dc=domain,dc=com"
    filter = "(mail=%{%{Stripped-User-Name}:-%{User-Name}})"
    ldap_connections_number = 5
    max_uses = 0
    timeout = 4
    timelimit = 3
    net_timeout = 1

    tls {
            start_tls = yes
            require_cert    = "never"
    }

    dictionary_mapping = ${confdir}/ldap.attrmap
    password_attribute = userPassword
    edir_account_policy_check = no

    keepalive {
            idle = 60
            probes = 3
            interval = 3
    }}

Also have the following setup for eap.conf

eap {
default_eap_type = peap
timer_expire     = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
max_sessions = 4096

md5 {
}

leap {
}

gtc {
        auth_type = PAP
}

tls {
        certdir = ${confdir}/certs
        cadir = ${confdir}/certs
        private_key_password = whatever
        private_key_file = ${certdir}/server.key
        certificate_file = ${certdir}/server.pem
        CA_file = ${cadir}/ca.pem
        dh_file = ${certdir}/dh
        random_file = /dev/urandom
        CA_path = ${cadir}
        cipher_list = "DEFAULT"
        make_cert_command = "${certdir}/bootstrap"

        cache {
              enable = no
              max_entries = 255
        }

        verify {
        }
}

ttls {
        default_eap_type = md5
        copy_request_to_tunnel = no
        use_tunneled_reply = no
        virtual_server = "inner-tunnel"
}


peap {
        default_eap_type = mschapv2
        copy_request_to_tunnel = no
        use_tunneled_reply = no
        virtual_server = "inner-tunnel"
}

mschapv2 {
}}

Also have two sites enabled, default and inner-tunnel:

default

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

inner-tunnel

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

Here is a sample log I am seeing in the debug logs:

https://gist.github.com/anonymous/10483144

Solution

You appear to of removed the symlink between sites-available/inner-tunnel and sites-enabled/inner-tunnel

If you look in the log it's complaining it can't find the inner-tunnel server, which it requires to perform MSCHAPv2 auth in the TLS tunnel of the PEAP authentication.

server  {
  PEAP: Setting User-Name to [email protected]
Sending tunneled request
        EAP-Message = 0x0205001a01656d72654071756269746469676974616c2e636f6d
        FreeRADIUS-Proxied-To = 127.0.0.1
        User-Name = "[email protected]"
server inner-tunnel {
No such virtual server "inner-tunnel"
} # server inner-tunnel

You add the symlink back, and list the ldap module at the top of the authorize section in the inner-tunnel server. You will also need to map the attribute holding the user's Cleartext-Password to the User-Password attribute, using the ldap attrmap file.

If you do not have the user's Cleartext-Password in the directory (for example if it's hashed), then you should use EAP-TTLS-PAP, and list the LDAP module in the authenticate section of the inner-tunnel server, then add:

if (User-Password) {
    update control {
        Auth-Type := LDAP
    }
}

To the authorize section of the inner-tunnel server.