Hi, I have a FR setup working fine for wireless clients with either EAP-TLS (computer certificate) or EAP-PEAP (user credentials validated by winbind/AD). I'm trying to expand on that and have wired clients authenticate via 802.1X with EAP-TLS (computer certificate). In my test I'm using the same Windows client that properly authenticates wirelessly with EAP-TLS. I configured its wired interface to use 802.1X with the same local certificate. The FR log indeed shows a "Received Access-Request" which is identical to what I see when it connects wirelessly, except of course for the calling station's MAC addr. The request log also finishes in a similar way with: (38) Found Auth-Type = eap (38) # Executing group from file /etc/raddb/sites-enabled/default (38) authenticate { (38) eap: Peer sent packet with method EAP Identity (1) (38) eap: Calling submodule eap_tls to process data (38) eap_tls: Initiating new TLS session (38) eap_tls: Setting verify mode to require certificate from client (38) eap_tls: [eaptls start] = request (38) eap: Sending EAP Request (code 1) ID 3 length 6 (38) eap: EAP session adding &reply:State = 0x5bf4e1345bf7eccc (38) [eap] = handled (38) } # authenticate = handled (38) Using Post-Auth-Type Challenge (38) # Executing group from file /etc/raddb/sites-enabled/default (38) Challenge { ... } # empty sub-section is ignored (38) Sent Access-Challenge Id 6 from 10.215.144.91:1812 to 10.215.110.190:49154 length 0 (38) EAP-Message = 0x010300060d20 (38) Message-Authenticator = 0x00000000000000000000000000000000 (38) State = 0x5bf4e1345bf7eccc1b644b2a242dee88 (38) Finished request However, FR keeps receiving "Access-Request" messages from the same station without the "State" field. So, could it be that the client is not responding properly (or ignoring/denying) FR's "Access-Challenge"? What should I be looking for and where (I suspect it's all on the client, but I'd like to make sure I don't need to do anything else in FR)? Would it be useful if I posted the full "Access-Request" log? If so, one would be enough if subsequent request messages are the same, I guess (except for msg ID of course). Regards, Vieri
On May 24, 2021, at 6:16 AM, Vieri Di Paola <vieridipaola@gmail.com> wrote:
I have a FR setup working fine for wireless clients with either EAP-TLS (computer certificate) or EAP-PEAP (user credentials validated by winbind/AD).
I'm trying to expand on that and have wired clients authenticate via 802.1X with EAP-TLS (computer certificate).
In my test I'm using the same Windows client that properly authenticates wirelessly with EAP-TLS. I configured its wired interface to use 802.1X with the same local certificate.
Well, maybe.
(38) Sent Access-Challenge Id 6 from 10.215.144.91:1812 to 10.215.110.190:49154 length 0 (38) EAP-Message = 0x010300060d20 (38) Message-Authenticator = 0x00000000000000000000000000000000 (38) State = 0x5bf4e1345bf7eccc1b644b2a242dee88 (38) Finished request
However, FR keeps receiving "Access-Request" messages from the same station without the "State" field.
That means the Windows system is starting the authentication process again.
So, could it be that the client is not responding properly (or ignoring/denying) FR's "Access-Challenge"?
Yes. It doesn't like the servers certificate. So it just stops talking to the server.
What should I be looking for and where (I suspect it's all on the client, but I'd like to make sure I don't need to do anything else in FR)?
It's not FreeRADIUS. It's the client.
Would it be useful if I posted the full "Access-Request" log? If so, one would be enough if subsequent request messages are the same, I guess (except for msg ID of course).
You don't need the full debug output. If you let the server sit for a while, when it gets the next packet, it will print out a huge set of debug messages which tell you what's wrong, and pointing you to the Wiki. Alan DeKok.
On Mon, May 24, 2021 at 1:20 PM Alan DeKok <aland@deployingradius.com> wrote:
On May 24, 2021, at 6:16 AM, Vieri Di Paola <vieridipaola@gmail.com> wrote:
I have a FR setup working fine for wireless clients with either EAP-TLS (computer certificate) or EAP-PEAP (user credentials validated by winbind/AD).
I'm trying to expand on that and have wired clients authenticate via 802.1X with EAP-TLS (computer certificate).
In my test I'm using the same Windows client that properly authenticates wirelessly with EAP-TLS. I configured its wired interface to use 802.1X with the same local certificate.
Well, maybe.
It's the only client certificate available in the Windows mmc console so I'm supposing it is.
(38) Sent Access-Challenge Id 6 from 10.215.144.91:1812 to 10.215.110.190:49154 length 0 (38) EAP-Message = 0x010300060d20 (38) Message-Authenticator = 0x00000000000000000000000000000000 (38) State = 0x5bf4e1345bf7eccc1b644b2a242dee88 (38) Finished request
However, FR keeps receiving "Access-Request" messages from the same station without the "State" field.
That means the Windows system is starting the authentication process again.
OK.
So, could it be that the client is not responding properly (or ignoring/denying) FR's "Access-Challenge"?
Yes. It doesn't like the servers certificate. So it just stops talking to the server.
ie. it does not like the following? /etc/raddb/mods-enabled/eap: certificate_file = ${certdir}/server.pem or the signing authority: /etc/raddb/mods-enabled/eap: ca_file = ${cadir}/ca.pem It puzzles me as to why it does not when connecting with a wire and does when connecting wirelessly.
What should I be looking for and where (I suspect it's all on the client, but I'd like to make sure I don't need to do anything else in FR)?
It's not FreeRADIUS. It's the client.
I'm having a hard time finding a reason for the rejection in the client's event logger. I've searched for EAPhost and the likes, but I didn't find anything that clearly states why there's an authentication problem.
Would it be useful if I posted the full "Access-Request" log? If so, one would be enough if subsequent request messages are the same, I guess (except for msg ID of course).
You don't need the full debug output.
If you let the server sit for a while, when it gets the next packet, it will print out a huge set of debug messages which tell you what's wrong, and pointing you to the Wiki.
With just radiusd -X and FR v.3.0.20 ? The only thing I see even if I wait for a long while is something like this: (625) Sent Access-Challenge Id 21 from 10.215.144.91:1812 to 10.215.110.190:49154 length 0 (625) EAP-Message = 0x010300060d20 (625) Message-Authenticator = 0x00000000000000000000000000000000 (625) State = 0x6680142d668319b34dda38122881c11c (625) Finished request Waking up in 4.9 seconds. ((625) Cleaning up request packet ID 21 with timestamp +8779 I may need to run radiusd with another set of parameters? Regards, Vieri
On May 25, 2021, at 8:01 AM, Vieri Di Paola <vieridipaola@gmail.com> wrote:
It puzzles me as to why it does not when connecting with a wire and does when connecting wirelessly.
Wired / wireless have different configuration systems / locations on Windows. So you need to add certificates to both places in order to do both wired and wireless.
If you let the server sit for a while, when it gets the next packet, it will print out a huge set of debug messages which tell you what's wrong, and pointing you to the Wiki.
With just radiusd -X and FR v.3.0.20 ?
Yes.
The only thing I see even if I wait for a long while is something like this:
(625) Sent Access-Challenge Id 21 from 10.215.144.91:1812 to 10.215.110.190:49154 length 0 (625) EAP-Message = 0x010300060d20 (625) Message-Authenticator = 0x00000000000000000000000000000000 (625) State = 0x6680142d668319b34dda38122881c11c (625) Finished request Waking up in 4.9 seconds. ((625) Cleaning up request packet ID 21 with timestamp +8779
I may need to run radiusd with another set of parameters?
No, the server needs to get *another packet*, as I said above. Alan DeKok.
On Tue, May 25, 2021 at 2:17 PM Alan DeKok <aland@deployingradius.com> wrote:
On May 25, 2021, at 8:01 AM, Vieri Di Paola <vieridipaola@gmail.com> wrote:
It puzzles me as to why it does not when connecting with a wire and does when connecting wirelessly.
Wired / wireless have different configuration systems / locations on Windows. So you need to add certificates to both places in order to do both wired and wireless.
I'm using computer certificates, and I import them with the mmc snap-in. I'll double-check that. Thanks.
If you let the server sit for a while, when it gets the next packet, it will print out a huge set of debug messages which tell you what's wrong, and pointing you to the Wiki.
With just radiusd -X and FR v.3.0.20 ?
Yes.
The only thing I see even if I wait for a long while is something like this:
(625) Sent Access-Challenge Id 21 from 10.215.144.91:1812 to 10.215.110.190:49154 length 0 (625) EAP-Message = 0x010300060d20 (625) Message-Authenticator = 0x00000000000000000000000000000000 (625) State = 0x6680142d668319b34dda38122881c11c (625) Finished request Waking up in 4.9 seconds. ((625) Cleaning up request packet ID 21 with timestamp +8779
I may need to run radiusd with another set of parameters?
No, the server needs to get *another packet*, as I said above.
OK, but I guess it's not getting it. Here's the full radiusd -X log: https://drive.google.com/file/d/1yyh7-e68iC6zfMzZGTnF72SFO8s3lT4P/view?usp=s... On the Windows client side, I noticed that there's a Wired-Autoconfig event log telling me that there was no reply to EAP. Of course, FR *is* replying so maybe it's not getting to the client for some other reason. Will have to dig into this some more. Thanks, Vieri
On May 25, 2021, at 9:10 AM, Vieri Di Paola <vieridipaola@gmail.com> wrote:
On the Windows client side, I noticed that there's a Wired-Autoconfig event log telling me that there was no reply to EAP. Of course, FR *is* replying so maybe it's not getting to the client for some other reason.
That could be it, too. But a lot less common. i.e. if the systems exchange 2-3 packets, then they should be able to exchange ~10 packets for a full EAP session. There's nothing in the middle of the EAP session which will cause IP routing to fail. Alan DeKok.
participants (2)
-
Alan DeKok -
Vieri Di Paola