On 19/04/2018 19:28, Alan Buxey wrote:
> eapol_test never used to be part of the installed wpa_supplicant package
> but various distros have changed their policy and now provide it (after
> tickets being submitted from people like myself).
>
> Freeradius comes with several config scripts that can be used with
> eapol_test (in src/test)
>
> alan
>
> On Thu, 19 Apr 2018, 18:12 Stefan Winter, <stefan.winter at restena.lu> wrote:
>
>> Hello,
>>
>> Now that's something to investigate.
>>
>> AFAIK, FreeRADIUS sends the certificate it has in config to the client.
>> It doesn't check anything special (beyond well-formedness of the PEM file).
>>
>> The error you are seeing in freeradius -X is most likely because
>> FreeRADIUS /receives/ this error message from the /client/.
>>
>> If it were a genuine error inside FreeRADIUS, things wouldn't work for
>> Windows clients.
>>
>> So you should probably take a very close look at eapol_test's debug
>> output. If it is the one rejecting the incoming TLS server cert, then it
>> will print out something. If you're unlucky, it will just print the same
>> error message it is afterwards also sending to the server, but with a
>> bit of luck there is a bit more detail on its side.
>>
>> You aren't by any chance doing this work for an eduroam participant? If
>> so, our compliance check tools could be unleashed on the IdP FreeRADIUS;
>> I'd only need to know the realm then.
>>
>> Also, eapol_test is part of the wpa_supplicant suite (but indeed not
>> compiled by all distros). So your self-compiled version was just as good
>> as the distro-supplied you now have.
>>
>> And the wpa_supplicant.conf is also being considered when using
>> eapol_test. I'm surprised you get an EAP conversation going with a
>> config file that has only two lines? You are relying on plentiful of
>> defaults there. You would usually need to configure at least a username
>> to use for the login attempt? Where do you supply that?
>>
>> Greetings,
>>
>> Stefan Winter
>>
>> Greetings,
>>
>> Stefan Winter
>> -
>> List info/subscribe/unsubscribe? See
>> http://www.freeradius.org/list/users.html
> -
> List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
This is all my bad as I try to deconstruct what my distro is doing.
First to answer some of your queries, I am running eapol_test with the
following command:
eapol_test -a10.0.2.15 -p1812 -sSEKRET
-ceapol_test-eaptls-standard.conf -r0
and the conf file contains:
network={
ssid="DoesNotMatterForThisTest"
key_mgmt=WPA-EAP
eap=TLS
identity="test"
password="test"
ca_cert="/etc/raddb/certs/ca.pem"
client_cert="/etc/raddb/certs/test at example.org.pem"
private_key="/etc/raddb/certs/test at example.org.pem"
private_key_passwd="whatever"
eapol_flags=3
}
It is now working correctly. The problem I had was that the distro does
not create a client.pem in its own certificate structure so I was
linking to the server.pem and this worked fine without the certificate
extensions. When I flipped back to the default installation and certs I
was still pointing my client cert to the server.pem file albeit in the
correct folder. Changing it to the correct client.pem and all works. So
a big sorry for wasting your time.
But if you can help me with my other issue I'd really appreciate it. In
a domain environment, the user_name appears as "user/machine.domain" and
for the life of me I cannot find out how to strip the machine.domain
off. Bear in mind the "machine" changes with every client so it could be
laptop1.domain or desktopXYZ.domain. From other posts it seems like I
need to use proxy.conf but I can't work out how. Even if I hardcode a
realm as machine.domain, it does not seem to strip it with:
realm machine.domain {
auth_pool = my_auth_failover
}
I've also seen a reference to a LOCAL realm but I don't understand
what to do with it.
Nick