Machine auth fails but user auth works
I have FreeRadius 3.0.4 and authenticate to AD. My user authentication works but machine auth fails with certificate errors. I was using the same Windows 10 machine to test both scenarios. I attached the debug logs in both tests. What could be the reasons for the machine auth problem? Below are some of my configurations: mods-available/mschap: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}" mods-available/eap: default_eap_type = peap peap { tls = tls-common default_eap_type = mschapv2 copy_request_to_tunnel = yes use_tunneled_reply = yes # proxy_tunneled_request_as_eap = yes virtual_server = "inner-tunnel" # soh = yes # soh_virtual_server = "soh-server" # require_client_cert = yes } mschapv2 { # send_error = no } proxy.conf: realm LOCAL { } realm NULL{ } realm uoguelph.ca { } realm DEFAULT { authhost = prod1-east.eduroam.ca:1812 accthost = prod1-east.eduroam.ca:1813 secret = nostrip } Thanks! Dennis Xu
Machine Auth client appears to be using the wrong CA. Your proxy.conf doesn't look to good either, surprised eduroamUS haven't contacted you as you'll be sending loads of invalid junk upstream for no purpose. Should use unlang to check realm is valid and then update control proxy-to-realm to eg 'eduroam' and define eduroam target in proxy.conf alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
In both user and machine auth cases, I use the same certificate installed on FreeRadius. I don't understand why machine auth complains the CA error, but no issues for user auth? I don't use certificates on client machines and there is no special configuration about certificates in the machine auth case. This setup is still in lab, so eduroam has not contacted me about anything. Will look into unlang, thanks for the suggestion. Dennis ----- Original Message ----- From: "Alan Buxey" <A.L.M.Buxey@lboro.ac.uk> To: dxu@uoguelph.ca, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, December 3, 2015 3:02:17 PM Subject: Re: Machine auth fails but user auth works Machine Auth client appears to be using the wrong CA. Your proxy.conf doesn't look to good either, surprised eduroamUS haven't contacted you as you'll be sending loads of invalid junk upstream for no purpose. Should use unlang to check realm is valid and then update control proxy-to-realm to eg 'eduroam' and define eduroam target in proxy.conf alan -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Dec 3, 2015, at 4:24 PM, Dennis Xu <dxu@uoguelph.ca> wrote:
In both user and machine auth cases, I use the same certificate installed on FreeRadius. I don't understand why machine auth complains the CA error, but no issues for user auth?
You have to enable the CA for each user / machine identity.
I don't use certificates on client machines and there is no special configuration about certificates in the machine auth case.
The client system still has to trust the RADIUS server. The *only* way to do this is to install the CA certificate on the client. Alan DeKok.
I have configured the client to trust server certificate and installed the server certificate on client "Trusted Root CA certificate store" and still the same thing. Then I also unchecked the "validate server certificate" at the client, still cannot connect but see a different message at FreeRadius debug: (75) eap_peap : processing EAP-TLS (75) eap_peap : eaptls_verify returned 7 (75) eap_peap : Done initial handshake (75) eap_peap : eaptls_process returned 7 (75) eap_peap : FR_TLS_OK (75) eap_peap : Session established. Decoding tunneled attributes (75) eap_peap : Peap state send tlv failure (75) eap_peap : Received EAP-TLV response (75) eap_peap : The users session was previously rejected: returning reject (again.) (75) eap_peap : *** This means you need to read the PREVIOUS messages in the debug output (75) eap_peap : *** to find out the reason why the user was rejected (75) eap_peap : *** Look for "reject" or "fail". Those earlier messages will tell you (75) eap_peap : *** what went wrong, and how to fix the problem SSL: Removing session a38778fb8d95f898711428a550cca28f33c0704bedf61bf9cd5fb56bb744a8d8 from the cache (75) ERROR: eap : Failed continuing EAP PEAP (25) session. EAP sub-module failed (75) eap : Failed in EAP select (75) [eap] = invalid (75) } # authenticate = invalid (75) Failed to authenticate the user (75) Login incorrect (eap: Failed continuing EAP PEAP (25) session. EAP sub-module failed): [host/CCS-252.cfs.uoguelph.ca] (from client WLC2504 port 1 cli c4-8e-8f-f8-96-33) (75) Using Post-Auth-Type Reject (75) # Executing group from file /etc/raddb/sites-enabled/default (75) Post-Auth-Type REJECT { (75) attr_filter.access_reject : EXPAND %{User-Name} (75) attr_filter.access_reject : --> host/CCS-252.cfs.uoguelph.ca (75) attr_filter.access_reject : Matched entry DEFAULT at line 11 (75) [attr_filter.access_reject] = updated (75) eap : Reply already contained an EAP-Message, not inserting EAP-Failure (75) [eap] = noop (75) remove_reply_message_if_eap remove_reply_message_if_eap { (75) if (&reply:EAP-Message && &reply:Reply-Message) (75) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (75) else else { (75) [noop] = noop (75) } # else else = noop (75) } # remove_reply_message_if_eap remove_reply_message_if_eap = noop (75) } # Post-Auth-Type REJECT = updated Now client does not validate server certificate now, does FR server need to validate client certificate? Thanks. Dennis ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: dxu@uoguelph.ca, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Thursday, December 3, 2015 4:33:14 PM Subject: Re: Machine auth fails but user auth works On Dec 3, 2015, at 4:24 PM, Dennis Xu <dxu@uoguelph.ca> wrote:
In both user and machine auth cases, I use the same certificate installed on FreeRadius. I don't understand why machine auth complains the CA error, but no issues for user auth?
You have to enable the CA for each user / machine identity.
I don't use certificates on client machines and there is no special configuration about certificates in the machine auth case.
The client system still has to trust the RADIUS server. The *only* way to do this is to install the CA certificate on the client. Alan DeKok.
The log days to look further up. ..you need to look further up. And yes. Server needs to check client. It is mutual authentication. Same CA as the AD? Alan
PEAP does not need to check certificate on client. It is not EAP-TLS. Is there an option to disable the client side certificate validation? No we don't have PKI, so not the same CA as AD. It is just a third party trusted CA from Thawte. Dennis ----- Original Message ----- From: "Alan Buxey" <A.L.M.Buxey@lboro.ac.uk> To: dxu@uoguelph.ca, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org>, "Alan DeKok" <aland@deployingradius.com> Sent: Friday, December 4, 2015 10:10:53 AM Subject: Re: Machine auth fails but user auth works The log days to look further up. ..you need to look further up. And yes. Server needs to check client. It is mutual authentication. Same CA as the AD? Alan
On 4 Dec 2015, at 14:23, Dennis Xu <dxu@uoguelph.ca> wrote:
PEAP does not need to check certificate on client. It is not EAP-TLS. Is there an option to disable the client side certificate validation?
No we don't have PKI, so not the same CA as AD. It is just a third party trusted CA from Thawte.
You need to bundle as much of the certificate chain as required in the server certificate file, to allow the client to establish the trust relationship from one of its roots to your certificate. So you need your server cert, and the intermediary CAs all concatenated together in the same file. Easiest to do this with PEM, as you can just cat >> the base64 armoured certs together. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
I have listed all root and intermediate CAs in the eap file: certificate_file = ${certdir}/ThawteCert.cer # Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802.1x (EAP) authentication. # In that case, this CA file should contain # *one* CA certificate. # ca_file = ${cadir}/SSL_PrimaryCA.pem ca_file = ${cadir}/SSL_SecondaryCA.pem ca_file = ${cadir}/thawte_Premium_Server_CA.pem The server certificate and its configuration should be ok, otherwise the user authentication would fail as well. If the server is trying to valid client certificate, it will fail for sure as there is no certificate on clients and I don't think that is required for PEAP. Dennis ----- Original Message ----- From: "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Friday, December 4, 2015 2:29:42 PM Subject: Re: Machine auth fails but user auth works
On 4 Dec 2015, at 14:23, Dennis Xu <dxu@uoguelph.ca> wrote:
PEAP does not need to check certificate on client. It is not EAP-TLS. Is there an option to disable the client side certificate validation?
No we don't have PKI, so not the same CA as AD. It is just a third party trusted CA from Thawte.
You need to bundle as much of the certificate chain as required in the server certificate file, to allow the client to establish the trust relationship from one of its roots to your certificate. So you need your server cert, and the intermediary CAs all concatenated together in the same file. Easiest to do this with PEM, as you can just cat >> the base64 armoured certs together. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 4, 2015, at 5:24 PM, Dennis Xu <dxu@uoguelph.ca> wrote:
I have listed all root and intermediate CAs in the eap file:
... ca_file = ${cadir}/SSL_PrimaryCA.pem ca_file = ${cadir}/SSL_SecondaryCA.pem ca_file = ${cadir}/thawte_Premium_Server_CA.pem
You do realize that doesn't work, right? Please *follow instructions*. Arran said:
So you need your server cert, and the intermediary CAs all concatenated together in the same file.
What part of that is unclear?
The server certificate and its configuration should be ok, otherwise the user authentication would fail as well.
No.
If the server is trying to valid client certificate, it will fail for sure as there is no certificate on clients and I don't think that is required for PEAP.
It's not. The client is trying to verify the server certificate and failing. Because you're not following instructions. Alan DeKok.
On 4 Dec 2015, at 17:24, Dennis Xu <dxu@uoguelph.ca> wrote:
I have listed all root and intermediate CAs in the eap file:
You're using confusing terminology. 'client side' certificate validation refers to the client validating the server certificate, not validating the client's certificate. I honestly have no idea what you mean, please clarify your requirements using the correct terminology.
certificate_file = ${certdir}/ThawteCert.cer
# Trusted Root CA list # # ALL of the CA's in this list will be trusted # to issue client certificates for authentication. # # In general, you should use self-signed # certificates for 802.1x (EAP) authentication. # In that case, this CA file should contain # *one* CA certificate. # ca_file = ${cadir}/SSL_PrimaryCA.pem ca_file = ${cadir}/SSL_SecondaryCA.pem ca_file = ${cadir}/thawte_Premium_Server_CA.pem
The server certificate and its configuration should be ok, otherwise the user authentication would fail as well.
Well that's wrong, the certificates must be concatenated into a single file. Nice syntax you've invented there, it's certainly not supported or one that works. -- Alan D any issues with throwing a validation error unless a CONF_PAIR is marked up with PW_TYPE_MULTI?
If the server is trying to valid client certificate, it will fail for sure as there is no certificate on clients and I don't think that is required for PEAP.
It's not, and the server doesn't explicitly request a client certificate for PEAP. That only happens for EAP-TLS. If the supplicant is presenting a certificate it's probably some snake oil cert that Microsoft auto generates, or something provided via AD. I'm fairly certain the OpenSSL API doesn't include an option to ignore client certificates if they're presented. It assumes no TLS peer would be so broken as to present a certificate it didn't want to use as part of authenticating itself. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Dec 4, 2015, at 5:38 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
-- Alan D any issues with throwing a validation error unless a CONF_PAIR is marked up with PW_TYPE_MULTI?
That's a good idea. Even for 3.0. There are enough people inventing syntax that we should be more careful with sanity checks. There may be a few configuration items which are allowed more than once, but they should all be marked up with MULTI. Alan DeKok.
On Fri, Dec 04, 2015 at 05:38:47PM -0500, Arran Cudbard-Bell wrote:
-- Alan D any issues with throwing a validation error unless a CONF_PAIR is marked up with PW_TYPE_MULTI?
That sounds like it would be helpful for people. Matthew (not Alan D...) -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On 4 Dec 2015, at 18:05, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Fri, Dec 04, 2015 at 05:38:47PM -0500, Arran Cudbard-Bell wrote:
-- Alan D any issues with throwing a validation error unless a CONF_PAIR is marked up with PW_TYPE_MULTI?
That sounds like it would be helpful for people.
Matthew (not Alan D...)
Ok, added to v3.1.x Matthew (not Alan D...)! I'm against back porting to v3.0.x because it's potentially a breaking change. If people have multiple values in their config and are relying on the fact that only the first one is processed and the later ones ignored (as we were in a few of the test server configs), it'd break that. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Dec 5, 2015, at 11:28 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Ok, added to v3.1.x Matthew (not Alan D...)!
"git push" ?
I'm against back porting to v3.0.x because it's potentially a breaking change.
I'm adding a warning. Let's hope people read it.
If people have multiple values in their config and are relying on the fact that only the first one is processed and the later ones ignored (as we were in a few of the test server configs), it'd break that.
That should be fixed... Alan DeKok.
On 5 Dec 2015, at 12:27, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 5, 2015, at 11:28 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Ok, added to v3.1.x Matthew (not Alan D...)!
"git push" ?
Pushed yesterday: ff5abe3031256040f07ea73eb2478ddbfbe71d96
I'm against back porting to v3.0.x because it's potentially a breaking change.
I'm adding a warning. Let's hope people read it.
Ok.
If people have multiple values in their config and are relying on the fact that only the first one is processed and the later ones ignored (as we were in a few of the test server configs), it'd break that.
That should be fixed...
It's where we set something like logdir, then included radiusd.conf. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hello Alan/Arran, Just started to work on this again today. I put the server cert and all intermediate CAs into the same file and changed the /mods-available/eap file as below: certificate_file = ${certdir}/all_certs.pem ca_file = ${cadir}/all_certs.pem Machine auth still failed but with different outputs. I don't see the "tlsv1 alert unknown ca" errors anymore. Would you please check the debug outputs again and advise? Thanks. Dennis ----- Original Message ----- From: "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Saturday, December 5, 2015 12:30:28 PM Subject: Re: Machine auth fails but user auth works
On 5 Dec 2015, at 12:27, Alan DeKok <aland@deployingradius.com> wrote:
On Dec 5, 2015, at 11:28 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
Ok, added to v3.1.x Matthew (not Alan D...)!
"git push" ?
Pushed yesterday: ff5abe3031256040f07ea73eb2478ddbfbe71d96
I'm against back porting to v3.0.x because it's potentially a breaking change.
I'm adding a warning. Let's hope people read it.
Ok.
If people have multiple values in their config and are relying on the fact that only the first one is processed and the later ones ignored (as we were in a few of the test server configs), it'd break that.
That should be fixed...
It's where we set something like logdir, then included radiusd.conf. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Dec 8, 2015, at 11:35 AM, Dennis Xu <dxu@uoguelph.ca> wrote:
Just started to work on this again today. I put the server cert and all intermediate CAs into the same file and changed the /mods-available/eap file as below: certificate_file = ${certdir}/all_certs.pem ca_file = ${cadir}/all_certs.pem
Machine auth still failed but with different outputs. I don't see the "tlsv1 alert unknown ca" errors anymore.
Would you please check the debug outputs again and advise?
You've deleted the useful portions, which is unhelpful. Post ALL of the debug output. And don't waste our time with edited portions of it. Since you can't solve the problem, you don't know which pieces are useful, and which aren't. So don't edit the debug output. Alan DeKok.
Here I have the complete eap file and debug outputs. Thanks. ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: dxu@uoguelph.ca, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 11:39:55 AM Subject: Re: Machine auth fails but user auth works On Dec 8, 2015, at 11:35 AM, Dennis Xu <dxu@uoguelph.ca> wrote:
Just started to work on this again today. I put the server cert and all intermediate CAs into the same file and changed the /mods-available/eap file as below: certificate_file = ${certdir}/all_certs.pem ca_file = ${cadir}/all_certs.pem
Machine auth still failed but with different outputs. I don't see the "tlsv1 alert unknown ca" errors anymore.
Would you please check the debug outputs again and advise?
You've deleted the useful portions, which is unhelpful. Post ALL of the debug output. And don't waste our time with edited portions of it. Since you can't solve the problem, you don't know which pieces are useful, and which aren't. So don't edit the debug output. Alan DeKok.
Sorry attached the wrong debug file in previous email. Please see this one. Dennis ----- Original Message ----- From: "Dennis Xu" <dxu@uoguelph.ca> To: "Alan DeKok" <aland@deployingradius.com> Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 12:22:36 PM Subject: Re: Machine auth fails but user auth works Here I have the complete eap file and debug outputs. Thanks. ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: dxu@uoguelph.ca, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 11:39:55 AM Subject: Re: Machine auth fails but user auth works On Dec 8, 2015, at 11:35 AM, Dennis Xu <dxu@uoguelph.ca> wrote:
Just started to work on this again today. I put the server cert and all intermediate CAs into the same file and changed the /mods-available/eap file as below: certificate_file = ${certdir}/all_certs.pem ca_file = ${cadir}/all_certs.pem
Machine auth still failed but with different outputs. I don't see the "tlsv1 alert unknown ca" errors anymore.
Would you please check the debug outputs again and advise?
You've deleted the useful portions, which is unhelpful. Post ALL of the debug output. And don't waste our time with edited portions of it. Since you can't solve the problem, you don't know which pieces are useful, and which aren't. So don't edit the debug output. Alan DeKok.
I see one difference between my machine auth and user auth cases: User auth: (18) mschap : Creating challenge hash with username: dxu (18) mschap : Client is using MS-CHAPv2 Executing: /usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}: (18) mschap : EXPAND --username=%{%{mschap:User-Name}:-00} (18) mschap : --> --username=dxu (18) mschap : EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (18) mschap : --> --username=dxu (18) ERROR: mschap : No NT-Domain was found in the User-Name (18) mschap : EXPAND --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} (18) mschap : --> --domain=CFS.UOGUELPH.CA (18) mschap : Creating challenge hash with username: dxu (18) mschap : EXPAND --challenge=%{%{mschap:Challenge}:-00} (18) mschap : --> --challenge=5cf265648d2f7da7 (18) mschap : EXPAND --nt-response=%{%{mschap:NT-Response}:-00} (18) mschap : --> --nt-response=5f4067f8278986cb3b524f75e1af8eef82e7753376f06191 Program returned code (0) and output 'NT_KEY: 0DB0BDD00DBF8F89BB011EB4035FE849' (18) mschap : Adding MS-CHAPv2 MPPE keys (18) [mschap] = ok (18) } # Auth-Type MS-CHAP = ok MSCHAP Success Machine auth: (19) mschap : Creating challenge hash with username: host/CCS-252.cfs.uoguelph.ca (19) mschap : Client is using MS-CHAPv2 Executing: /usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}: (19) mschap : EXPAND --username=%{%{mschap:User-Name}:-00} (19) mschap : --> --username=CCS-252$ (19) mschap : EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (19) mschap : --> --username=host/CCS-252.cfs.uoguelph.ca (19) mschap : EXPAND --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} (19) mschap : --> --domain=cfs (19) mschap : Creating challenge hash with username: host/CCS-252.cfs.uoguelph.ca (19) mschap : EXPAND --challenge=%{%{mschap:Challenge}:-00} (19) mschap : --> --challenge=9845f8f1049eec1c (19) mschap : EXPAND --nt-response=%{%{mschap:NT-Response}:-00} (19) mschap : --> --nt-response=c1ee140e5d85a62db9d4dd943a841a0f317a77521e0c26e0 Program returned code (1) and output 'Logon failure (0xc000006d)' (19) mschap : External script failed (19) ERROR: mschap : External script says: Logon failure (0xc000006d) (19) ERROR: mschap : MS-CHAP2-Response is incorrect (19) [mschap] = reject (19) } # Auth-Type MS-CHAP = reject The EXPAND domain value from user auth is "domain=CFS.UOGUELPH.CA" which is correct, but it got "domain=cfs" in the machine auth case. I am not sure if that is important. ----- Original Message ----- From: "Dennis Xu" <dxu@uoguelph.ca> To: "Alan DeKok" <aland@deployingradius.com> Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 12:23:51 PM Subject: Re: Machine auth fails but user auth works Sorry attached the wrong debug file in previous email. Please see this one. Dennis ----- Original Message ----- From: "Dennis Xu" <dxu@uoguelph.ca> To: "Alan DeKok" <aland@deployingradius.com> Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 12:22:36 PM Subject: Re: Machine auth fails but user auth works Here I have the complete eap file and debug outputs. Thanks. ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: dxu@uoguelph.ca, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 11:39:55 AM Subject: Re: Machine auth fails but user auth works On Dec 8, 2015, at 11:35 AM, Dennis Xu <dxu@uoguelph.ca> wrote:
Just started to work on this again today. I put the server cert and all intermediate CAs into the same file and changed the /mods-available/eap file as below: certificate_file = ${certdir}/all_certs.pem ca_file = ${cadir}/all_certs.pem
Machine auth still failed but with different outputs. I don't see the "tlsv1 alert unknown ca" errors anymore.
Would you please check the debug outputs again and advise?
You've deleted the useful portions, which is unhelpful. Post ALL of the debug output. And don't waste our time with edited portions of it. Since you can't solve the problem, you don't know which pieces are useful, and which aren't. So don't edit the debug output. Alan DeKok.
On Dec 8, 2015, at 12:39 PM, Dennis Xu <dxu@uoguelph.ca> wrote:
I see one difference between my machine auth and user auth cases: ... Machine auth: (19) mschap : Creating challenge hash with username: host/CCS-252.cfs.uoguelph.ca (19) mschap : Client is using MS-CHAPv2 Executing: /usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}: (19) mschap : EXPAND --username=%{%{mschap:User-Name}:-00} (19) mschap : --> --username=CCS-252$ (19) mschap : EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (19) mschap : --> --username=host/CCS-252.cfs.uoguelph.ca (19) mschap : EXPAND --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} (19) mschap : --> --domain=cfs (19) mschap : Creating challenge hash with username: host/CCS-252.cfs.uoguelph.ca (19) mschap : EXPAND --challenge=%{%{mschap:Challenge}:-00} (19) mschap : --> --challenge=9845f8f1049eec1c (19) mschap : EXPAND --nt-response=%{%{mschap:NT-Response}:-00} (19) mschap : --> --nt-response=c1ee140e5d85a62db9d4dd943a841a0f317a77521e0c26e0 Program returned code (1) and output 'Logon failure (0xc000006d)' (19) mschap : External script failed (19) ERROR: mschap : External script says: Logon failure (0xc000006d) (19) ERROR: mschap : MS-CHAP2-Response is incorrect (19) [mschap] = reject (19) } # Auth-Type MS-CHAP = reject
The EXPAND domain value from user auth is "domain=CFS.UOGUELPH.CA" which is correct, but it got "domain=cfs" in the machine auth case. I am not sure if that is important.
It would seem to be important. FreeRADIUS is working correctly. As you configured it. If you want it to work, figure out how to use the correct domain for machine authentication. It will then work. Alan DeKok.
Hi,
I see one difference between my machine auth and user auth cases:
yep
(18) mschap : EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (18) mschap : --> --username=dxu (18) ERROR: mschap : No NT-Domain was found in the User-Name (18) mschap : EXPAND --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} (18) mschap : --> --domain=CFS.UOGUELPH.CA
no NT-Domain found so its using your provided value in the config
(19) mschap : EXPAND --username=%{%{mschap:User-Name}:-00} (19) mschap : --> --username=CCS-252$ (19) mschap : EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (19) mschap : --> --username=host/CCS-252.cfs.uoguelph.ca (19) mschap : EXPAND --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} (19) mschap : --> --domain=cfs
NT-domain provided by client....so its using that....and not your provided realm. so, if you want it to work, ignore the NT-domain provided by the client (here, we dont have the -domain=%{%{mschap:NT-Domain}.... part at all in the ntlm_auth line... it all hits the configured realm in samba that ntlm_auth/winbind uses alan
On Tue, Dec 08, 2015 at 12:39:33PM -0500, Dennis Xu wrote:
The EXPAND domain value from user auth is "domain=CFS.UOGUELPH.CA" which is correct, but it got "domain=cfs" in the machine auth case. I am not sure if that is important.
Unless you have more than one domain, I would personally just hardcode the domain into the ntlm_auth command in the config. I do that here. It's one less thing to go wrong. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Yes I do hardcode the domain into the /etc/raddb/mods-available/mschap file: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}" If I understand correctly from other posts, if client specify a domain name, it will use that domain name regardless of the ntlm_auth configuration? As far as the client side, it is configured with cfs.uoguelph.ca domain, I am sure why it would use domain cfs. Are there any other places to check for the domain being used by machine auth? ----- Original Message ----- From: "Matthew Newton" <mcn4@leicester.ac.uk> To: dxu@uoguelph.ca, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 4:22:39 PM Subject: Re: Machine auth fails but user auth works On Tue, Dec 08, 2015 at 12:39:33PM -0500, Dennis Xu wrote: The EXPAND domain value from user auth is "domain=CFS.UOGUELPH.CA" which is correct, but it got "domain=cfs" in the machine auth case. I am not sure if that is important. Unless you have more than one domain, I would personally just hardcode the domain into the ntlm_auth command in the config. I do that here. It's one less thing to go wrong. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Tue, Dec 08, 2015 at 04:42:21PM -0500, Dennis Xu wrote:
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA}
That's not hardcoded. Hardcoded means setting --domain=CFS.UOGUELPH.CA i.e. no expansion so nothing else can change the setting.
--challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"
If I understand correctly from other posts, if client specify a domain name, it will use that domain name regardless of the ntlm_auth configuration?
%{mschap:...} is magic as far as I am concerned. :) If you want clients to change the domain name, sure set that up. But as I wrote before if you know that all clints are talking to the same domain, why allow them to fiddle with the settings? (My view here may not be consistent with others on this, but it's what I do.) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
I changed to "--domain=CFS.UOGUELPH.CA" and now it does not get any domains for machine authentication: (8) mschap : Creating challenge hash with username: host/CCS-252.cfs.uoguelph.ca (8) mschap : Client is using MS-CHAPv2 Executing: /usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=CFS.UOGUELPH.CA --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}: (8) mschap : EXPAND --username=%{%{mschap:User-Name}:-00} (8) mschap : --> --username=CCS-252$ (8) mschap : EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (8) mschap : --> --username=host/CCS-252.cfs.uoguelph.ca (8) mschap : Creating challenge hash with username: host/CCS-252.cfs.uoguelph.ca (8) mschap : EXPAND --challenge=%{%{mschap:Challenge}:-00} (8) mschap : --> --challenge=683ac434c3c89a99 (8) mschap : EXPAND --nt-response=%{%{mschap:NT-Response}:-00} (8) mschap : --> --nt-response=55082eea2ef4b8b9d7fb4985c654723659cdee6d13ebe2ef Program returned code (1) and output 'Logon failure (0xc000006d)' (8) mschap : External script failed (8) ERROR: mschap : External script says: Logon failure (0xc000006d) (8) ERROR: mschap : MS-CHAP2-Response is incorrect (8) [mschap] = reject (8) } # Auth-Type MS-CHAP = reject Dennis ----- Original Message ----- From: "Matthew Newton" <mcn4@leicester.ac.uk> To: "Dennis Xu" <dxu@uoguelph.ca> Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 4:54:13 PM Subject: Re: Machine auth fails but user auth works On Tue, Dec 08, 2015 at 04:42:21PM -0500, Dennis Xu wrote: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} That's not hardcoded. Hardcoded means setting --domain=CFS.UOGUELPH.CA i.e. no expansion so nothing else can change the setting. <blockquote> --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}" If I understand correctly from other posts, if client specify a domain name, it will use that domain name regardless of the ntlm_auth configuration? %{mschap:...} is magic as far as I am concerned. :) </blockquote> If you want clients to change the domain name, sure set that up. But as I wrote before if you know that all clints are talking to the same domain, why allow them to fiddle with the settings? (My view here may not be consistent with others on this, but it's what I do.) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
I changed to "--domain=CFS.UOGUELPH.CA" and now it does not get any domains for machine authentication:
do...you did more than that...for some reason you now have *2* --username bits!!
Executing: /usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=CFS.UOGUELPH.CA --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}:
thus:
(8) mschap : EXPAND --username=%{%{mschap:User-Name}:-00} (8) mschap : --> --username=CCS-252$
(8) mschap : EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (8) mschap : --> --username=host/CCS-252.cfs.uoguelph.ca
...err, yes...and NOW the server uses this broken version. delete that second entry so just CCS-252$ is used as you had before. alan
On Tue, Dec 08, 2015 at 11:38:16PM +0000, A.L.M.Buxey@lboro.ac.uk wrote:
(8) mschap : EXPAND --username=%{%{mschap:User-Name}:-00} (8) mschap : --> --username=CCS-252$
(8) mschap : EXPAND --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} (8) mschap : --> --username=host/CCS-252.cfs.uoguelph.ca
...err, yes...and NOW the server uses this broken version. delete that second entry so just CCS-252$ is used as you had before.
Ug. I'd just take the --challenge=683ac434c3c89a99 and --nt-response=55082eea2ef4b8b9d7fb4985c654723659cdee6d13ebe2ef and test them with ntlm_auth on the command line with different combinations of --username and --domain to find out what actually works. Then use that as a basis to work out what the config should be. If these are machines joined to a domain then won't they have certificates auto-enrolled from the domain anyway? In which case I'd just stick to PEAP/EAP-MSCHAPv2 for users and EAP-TLS for the machines. More conventional and faster auth as well. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Finally made it work. This is the working configuration for me: ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --domain=CFS.UOGUELPH.CA --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}" It works for both user and machine authentication. Thank you for everyone's help! Dennis ----- Original Message ----- From: "A L M Buxey" <A.L.M.Buxey@lboro.ac.uk> To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Cc: "Dennis Xu" <dxu@uoguelph.ca> Sent: Tuesday, December 8, 2015 6:40:53 PM Subject: Re: Machine auth fails but user auth works Hi,
But as I wrote before if you know that all clints are talking to the same domain, why allow them to fiddle with the settings?
exactly. either hardcode it in config or REMOVE the option :) alan
Hi,
ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{mschap:User-Name}:-00} --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"
If I understand correctly from other posts, if client specify a domain name, it will use that domain name regardless of the ntlm_auth configuration?
no. --domain=%{%{mschap:NT-Domain}:-CFS.UOGUELPH.CA} this means, set domain to be the value of NT-Domain from MSCHAP....and if no such value exists (as provided by the client), then set it to be CFS.UOGUELPH.CA instead. the docs are clear on how this works
As far as the client side, it is configured with cfs.uoguelph.ca domain, I am sure why it would use domain cfs. Are there any other places to check for the domain being used by machine auth?
no. its windows and windows does weird and interesting things regarding domains...it probably knows that its in uoguelph.ca and so is removing that part. anyway, just remove the option. alan
I guess you did not receive the email below? The attachment file has all debug outputs and I am sending it again. ----- Original Message ----- From: "Dennis Xu" <dxu@uoguelph.ca> To: "Alan DeKok" <aland@deployingradius.com> Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 12:23:51 PM Subject: Re: Machine auth fails but user auth works Sorry attached the wrong debug file in previous email. Please see this one. Dennis ----- Original Message ----- From: "Dennis Xu" <dxu@uoguelph.ca> To: "Alan DeKok" <aland@deployingradius.com> Cc: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 12:22:36 PM Subject: Re: Machine auth fails but user auth works Here I have the complete eap file and debug outputs. Thanks. ----- Original Message ----- From: "Alan DeKok" <aland@deployingradius.com> To: dxu@uoguelph.ca, "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Sent: Tuesday, December 8, 2015 11:39:55 AM Subject: Re: Machine auth fails but user auth works On Dec 8, 2015, at 11:35 AM, Dennis Xu <dxu@uoguelph.ca> wrote:
Just started to work on this again today. I put the server cert and all intermediate CAs into the same file and changed the /mods-available/eap file as below: certificate_file = ${certdir}/all_certs.pem ca_file = ${cadir}/all_certs.pem
Machine auth still failed but with different outputs. I don't see the "tlsv1 alert unknown ca" errors anymore.
Would you please check the debug outputs again and advise?
You've deleted the useful portions, which is unhelpful. Post ALL of the debug output. And don't waste our time with edited portions of it. Since you can't solve the problem, you don't know which pieces are useful, and which aren't. So don't edit the debug output. Alan DeKok.
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan Buxey
-
Alan DeKok -
Arran Cudbard-Bell -
Dennis Xu -
Matthew Newton