Hi, I have a server A proxying requests to server B (having LDAP enabled), and a client C requesting A. When I try to connect from A to B with radclient it works. Logs say : Login OK: [blabla2] (from client rad1-eee port 0) When I try to connect from C to A : Login incorrect (ldap: Bind credentials incorrect: Invalid credentials): [blabla2/?Q?#%?????)[~???dW???ŝ7?g-m?[˵] (from client rad1-eee port 0) I don't get why the credentials differ while proxying, which conf file should I check to understand this? Is this part coming from an ldap conf problem or from radiusd.conf problem? /?Q?#%?????)[~???dW???ŝ7?g-m? Thanks for your help. Here's the site-available/default file content : server default { listen { type = auth ipaddr = * port = 0 limit { max_connections = 16384 lifetime = 0 idle_timeout = 30 } } listen { ipaddr = * port = 0 type = acct limit { } } authorize { filter_username preprocess chap mschap digest suffix eap { ok = return } files -sql expiration logintime pap } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } mschap digest eap } preacct { preprocess acct_unique suffix files } accounting { -sql exec attr_filter.accounting_response } session { } post-auth { update { &reply: += &session-state: } remove_reply_message_if_eap Post-Auth-Type REJECT { -sql attr_filter.access_reject eap remove_reply_message_if_eap } Post-Auth-Type Challenge { } } pre-proxy { } post-proxy { eap } }
On Oct 19, 2020, at 11:39 AM, Julien COCHENNEC <julien.cochennec@ac-orleans-tours.fr> wrote: I have a server A proxying requests to server B (having LDAP enabled), and a client C requesting A.
When I try to connect from A to B with radclient it works. Logs say :
Login OK: [blabla2] (from client rad1-eee port 0)
That's good.
When I try to connect from C to A :
Login incorrect (ldap: Bind credentials incorrect: Invalid credentials): [blabla2/?Q?#%?????)[~???dW???ŝ7?g-m?[˵] (from client rad1-eee port 0)
And that's the same problem people have seen for 20 years. The shared secret is wrong.
I don't get why the credentials differ while proxying, which conf file should I check to understand this? Is this part coming from an ldap conf problem or from radiusd.conf problem?
The password is coming from the client.
Here's the site-available/default file content :
Why? *all* of the documentation says to post the output of "radiusd -X". And all of the documentation says "don't post configuration files". If you run the server in debugging mode as ALL of the documentation says, it will TELL YOU what's wrong. Alan DeKok.
Ok, thanks a lot Alan, let's do it right then, sorry for missing the docs, I thought I read it all though. A is radiusA.domain, IP 172.29.179.49 B is radiusB.domain, IP 172.29.49.89 C is IP 172.29.188.249 1) When I try to connect from A to B : echo "User-Name=***,User-Password=***" | radclient radiusB.domain:1812 auth *** Sent Access-Request Id 133 from 0.0.0.0:50763 to 172.29.49.89:1812 length 67 Received Access-Accept Id 133 from 172.29.49.89:1812 to 172.29.179.49:50763 length 20 2) When I try to connect from C to A : echo "User-Name=***,User-Password=***" | radclient radiusA.domain:1812 auth *** Sent Access-Request Id 253 from 0.0.0.0:44465 to 172.29.179.49:1812 length 67 Received Access-Reject Id 253 from 172.29.179.49:1812 to 172.29.188.249:44465 length 20 (0) -: Expected Access-Accept got Access-Reject 3) On A in debug mode : (0) Received Access-Request Id 49 from 172.29.188.249:59565 to 172.29.179.49:1812 length 67 (0) User-Name = "***" (0) User-Password = "***" (0) # Executing section authorize from file /etc/raddb/sites-enabled/default (0) authorize { (0) policy filter_username { (0) if (&User-Name) { (0) if (&User-Name) -> TRUE (0) if (&User-Name) { (0) if (&User-Name =~ / /) { (0) if (&User-Name =~ / /) -> FALSE (0) if (&User-Name =~ /@[^@]*@/ ) { (0) if (&User-Name =~ /@[^@]*@/ ) -> FALSE (0) if (&User-Name =~ /\.\./ ) { (0) if (&User-Name =~ /\.\./ ) -> FALSE (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) { (0) if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\.(.+)$/)) -> FALSE (0) if (&User-Name =~ /\.$/) { (0) if (&User-Name =~ /\.$/) -> FALSE (0) if (&User-Name =~ /@\./) { (0) if (&User-Name =~ /@\./) -> FALSE (0) } # if (&User-Name) = notfound (0) } # policy filter_username = notfound (0) [preprocess] = ok (0) [chap] = noop (0) [mschap] = noop (0) [digest] = noop (0) suffix: Checking for suffix after "@" (0) suffix: No '@' in User-Name = "***", looking up realm NULL (0) suffix: No such realm "NULL" (0) [suffix] = noop (0) eap: No EAP-Message, not doing EAP (0) [eap] = noop (0) [files] = noop (0) [expiration] = noop (0) [logintime] = noop (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available (0) [pap] = noop (0) } # authorize = ok (0) ERROR: No Auth-Type found: rejecting the user via Post-Auth-Type = Reject (0) Failed to authenticate the user (0) Using Post-Auth-Type Reject (0) # Executing group from file /etc/raddb/sites-enabled/default (0) Post-Auth-Type REJECT { (0) attr_filter.access_reject: EXPAND %{User-Name} (0) attr_filter.access_reject: -->*** (0) attr_filter.access_reject: Matched entry DEFAULT at line 11 (0) [attr_filter.access_reject] = updated (0) [eap] = noop (0) policy remove_reply_message_if_eap { (0) if (&reply:EAP-Message && &reply:Reply-Message) { (0) if (&reply:EAP-Message && &reply:Reply-Message) -> FALSE (0) else { (0) [noop] = noop (0) } # else = noop (0) } # policy remove_reply_message_if_eap = noop (0) } # Post-Auth-Type REJECT = updated (0) Delaying response for 1.000000 seconds Waking up in 0.3 seconds. Waking up in 0.6 seconds. (0) Sending delayed response (0) Sent Access-Reject Id 49 from 172.29.179.49:1812 to 172.29.188.249:59565 length 20 Waking up in 3.9 seconds. (0) Cleaning up request packet ID 49 with timestamp +3 Ready to process requests Le 19/10/2020 à 17:45, Alan DeKok a écrit :
On Oct 19, 2020, at 11:39 AM, Julien COCHENNEC <julien.cochennec@ac-orleans-tours.fr> wrote: I have a server A proxying requests to server B (having LDAP enabled), and a client C requesting A.
When I try to connect from A to B with radclient it works. Logs say :
Login OK: [blabla2] (from client rad1-eee port 0) That's good.
When I try to connect from C to A :
Login incorrect (ldap: Bind credentials incorrect: Invalid credentials): [blabla2/?Q?#%?????)[~???dW???ŝ7?g-m?[˵] (from client rad1-eee port 0) And that's the same problem people have seen for 20 years.
The shared secret is wrong.
I don't get why the credentials differ while proxying, which conf file should I check to understand this? Is this part coming from an ldap conf problem or from radiusd.conf problem? The password is coming from the client.
Here's the site-available/default file content : Why? *all* of the documentation says to post the output of "radiusd -X". And all of the documentation says "don't post configuration files".
If you run the server in debugging mode as ALL of the documentation says, it will TELL YOU what's wrong.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Julien Cochennec Pôle de compétences - gestion des identités Mél julien.cochennec@ac-orleans-tours.fr Tél 02 38 83 48 88 DSI - Rectorat d'Orléans-Tours 10 Rue Molière 45000 Orléans www.ac-orleans-tours.fr
On Oct 20, 2020, at 2:26 AM, Julien Cochennec <julien.cochennec@ac-orleans-tours.fr> wrote:
Ok, thanks a lot Alan, let's do it right then, sorry for missing the docs, I thought I read it all though.
A is radiusA.domain, IP 172.29.179.49
B is radiusB.domain, IP 172.29.49.89
C is IP 172.29.188.249
1) When I try to connect from A to B :
echo "User-Name=***,User-Password=***" | radclient radiusB.domain:1812 auth *** Sent Access-Request Id 133 from 0.0.0.0:50763 to 172.29.49.89:1812 length 67 Received Access-Accept Id 133 from 172.29.49.89:1812 to 172.29.179.49:50763 length 20
You're debugging the server by looking at the output of "radclient". Just... no.
2) When I try to connect from C to A :
echo "User-Name=***,User-Password=***" | radclient radiusA.domain:1812 auth *** Sent Access-Request Id 253 from 0.0.0.0:44465 to 172.29.179.49:1812 length 67 Received Access-Reject Id 253 from 172.29.179.49:1812 to 172.29.188.249:44465 length 20 (0) -: Expected Access-Accept got Access-Reject
3) On A in debug mode :
(0) Received Access-Request Id 49 from 172.29.188.249:59565 to 172.29.179.49:1812 length 67 ... (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available
That seems pretty clear. How are users supposed to be authenticated? Where are the passwords stored? Alan DeKok.
Le 20/10/2020 à 13:53, Alan DeKok a écrit :
You're debugging the server by looking at the output of "radclient".
Just... no.
Ok, this one was just about to mention it "works". Sorry.
... (0) pap: WARNING: No "known good" password found for the user. Not setting Auth-Type (0) pap: WARNING: Authentication will fail unless a "known good" password is available That seems pretty clear.
How are users supposed to be authenticated? Where are the passwords stored?
Oh yes, sorry, the password is stored on an ldap server that B is tied to. The first radclient test was meant to check the password was fine. It is.
-- Julien Cochennec Pôle de compétences - gestion des identités
Mél julien.cochennec@ac-orleans-tours.fr Tél 02 38 83 48 88
DSI - Rectorat d'Orléans-Tours 10 Rue Molière 45000 Orléans www.ac-orleans-tours.fr
On Oct 20, 2020, at 8:36 AM, Julien Cochennec <julien.cochennec@ac-orleans-tours.fr> wrote:
Le 20/10/2020 à 13:53, Alan DeKok a écrit :
You're debugging the server by looking at the output of "radclient".
Just... no.
Ok, this one was just about to mention it "works". Sorry.
Having a case which works is definitely useful. But why are you STILL not looking at the debug output? We tell people to run the server in debugging mode because it *helps*. In this case, you can look at the debug output for the case which works, and compare it to the debug output for the case which doesn't work. The differences between the two outputs is VERY important. Just... please. Follow the docs, READ THE DEBUG OUTPUT. Every message you send with the *wrong* information just wastes your time, and ours.
How are users supposed to be authenticated? Where are the passwords stored?
Oh yes, sorry, the password is stored on an ldap server that B is tied to.
So.... READ THE DEBUG OUTPUT YOU POSTED TO THE LIST. This isn't difficult. Does the debug output show it using the "ldap" module? No? Then... what's wrong? Hint: This isn't a trick question.
The first radclient test was meant to check the password was fine. It is.
So... READ the debug output for the first "radclient" test. See what it's doing. Honestly, it's frustrating as hell to write the docs, and then spend 20 years telling people "read the debug output". Yet pretty much every day there are people who fight tooth and nail against doing just that. Why? Alan DeKok.
Ok, really sorry. I did read it. I read a lot of docs about FreeRadius (most of it on the wiki) in a very short amount of time, so if I missed that doc, again, sorry. Which doc are we talking about BTW? I may have missed it, and I swear I did read a lot of docs since 4 months, mostly about ldap, proxy, clients and realms. I found the docs I read very useful, and it was a lot to compute, I'm a Radius noob, doing what I can. I searched for many messages on this list before posting, I didn't manage to see, in all the infos in the output, which one was useful, sorry for that too. For example, I thought the "No eap message" was the problem, but it looks like it isn't. I didn't get where to look. The debug information is on A, which is supposed to be a "pure" proxy, no auth, just proxying. But the Ldap is on B, which is a home server that does only Ldap auth for proxied requests. I first thought the proxy was modifying the password but had no idea why and found nothing about it. I totally understand it is frustrating for you to write so much content people don't read. It's been 4 months reading and testing for me, and I'm still lost in the debug output, you may not believe it, but it's frustrating too, I'm helpless. It's the second thing I read, after the Kibana log parsing result. I althought thought a realm (null or default) was missing in my conf, but found nothing to confirm this. Thanks for your help anyway Alan. Le 20/10/2020 à 15:05, Alan DeKok a écrit :
So.... READ THE DEBUG OUTPUT YOU POSTED TO THE LIST.
-- Julien Cochennec Pôle de compétences - gestion des identités Mél julien.cochennec@ac-orleans-tours.fr Tél 02 38 83 48 88 DSI - Rectorat d'Orléans-Tours 10 Rue Molière 45000 Orléans www.ac-orleans-tours.fr
Hi Julien, Sorry I'm no expert here and I don't know how to fix your problem, but I can see some things wrong with what you are doing. Please try: 1) check your proxy config on server A (your earlier email showed that it was probably proxying, and your later email showed it probably not proxying) 2) confirm your shared secret on server A matches server B (your earlier email indicated that it was wrong) 3) if you still can't get it working, post the "radiusd -X" output from server A as per https://wiki.freeradius.org/guide/Users%20Mailing%20List Regards, Geoffrey. On Tue, Oct 20, 2020 at 11:44:51PM +1030, Julien Cochennec wrote:
Ok, really sorry. I did read it.
I read a lot of docs about FreeRadius (most of it on the wiki) in a very short amount of time, so if I missed that doc, again, sorry.
Which doc are we talking about BTW? I may have missed it, and I swear I did read a lot of docs since 4 months, mostly about ldap, proxy, clients and realms.
I found the docs I read very useful, and it was a lot to compute, I'm a Radius noob, doing what I can.
I searched for many messages on this list before posting, I didn't manage to see, in all the infos in the output, which one was useful, sorry for that too.
For example, I thought the "No eap message" was the problem, but it looks like it isn't.
I didn't get where to look.
The debug information is on A, which is supposed to be a "pure" proxy, no auth, just proxying.
But the Ldap is on B, which is a home server that does only Ldap auth for proxied requests.
I first thought the proxy was modifying the password but had no idea why and found nothing about it.
I totally understand it is frustrating for you to write so much content people don't read.
It's been 4 months reading and testing for me, and I'm still lost in the debug output, you may not believe it, but it's frustrating too, I'm helpless.
It's the second thing I read, after the Kibana log parsing result.
I althought thought a realm (null or default) was missing in my conf, but found nothing to confirm this.
Thanks for your help anyway Alan.
Le 20/10/2020 à 15:05, Alan DeKok a écrit :
So.... READ THE DEBUG OUTPUT YOU POSTED TO THE LIST.
-- Julien Cochennec Pôle de compétences - gestion des identités
Mél julien.cochennec@ac-orleans-tours.fr Tél 02 38 83 48 88
DSI - Rectorat d'Orléans-Tours 10 Rue Molière 45000 Orléans www.ac-orleans-tours.fr
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Geoffrey D. Bennett <g@netcraft.com.au> http://www.netcraft.com.au Senior Systems Engineer, Netcraft Australia +61 8 8133 3333 ----- Copyright Notice All rights reserved. Other than for the internal business use of the Customer, no part of this publication may be reprinted, reproduced, stored in a retrieval system or transmitted in any form or by any means without prior permission in writing from Netcraft Australia Pty Ltd. This document contains confidential information of Netcraft Australia Pty Ltd. In consideration of receipt of this document, the Customer agrees to maintain such information in confidence and not to reproduce or otherwise disclose this information to any person outside the group directly responsible for the evaluation of its contents.
When you join the mailing list, the message you get says: read http://wiki.freeradius.org/list-help That recommendation is repeated at least weekly, if not daily on this list. The "man" pages and all other documentation says "run the server in debug mode". So... where *else* do we need to put that documentation in order for people to find it? The issue here is that you're hiding information. Every messages contains *new* information which you didn't mention before. When you post the debug output, you edit it to delete most of the useful information. When the documentation says "don't do that". So the debug output is largely useless. You're trying *very* hard to make it difficult for us to help you. This is not helpful. In the end, the configuration you want is pretty simple. It shouldn't take 4 months to configure the server to (a) proxy a packet from one system to another, and (b) authenticate a user against LDAP. Ask *simple* questions. "How do I do X?" You will get helpful answers. If your questions are instead "I tried to do a bunch of stuff and it didn't work", then the only possible answer is "maybe do different stuff?" How do you proxy packets from one system to the other? Read proxy.conf. Configure a realm "example.com". Then, send packets containing "username@example.com". It's that simple. So... what did you do? Did you configure a realm? If so, how? You said that you spent 4 months reading documentation. That's nice... but what did you *do* to configure the server? We need to know what. For some reason, you're not telling us. And I don't know why. If you *do* tell us what you did, then we can give useful advice, and pretty quickly. Until then, we're stuck, because you're not telling us anything useful. Alan DeKok.
Hi Proxying is done 'per hop'. You have an incorrect shared secret at one of the hops. Things are fine between A+B? Then the issue is between B+C. The joy can be multiple as the shared secret problem/typo may be just in one direction too. Or, even better, one of the hops doing something like terminating the EAP tunnel and proxying the inner tunnel conversation etc. Always fun alan On Tue, 20 Oct 2020, 18:25 Alan DeKok, <aland@deployingradius.com> wrote:
When you join the mailing list, the message you get says: read http://wiki.freeradius.org/list-help
That recommendation is repeated at least weekly, if not daily on this list. The "man" pages and all other documentation says "run the server in debug mode".
So... where *else* do we need to put that documentation in order for people to find it?
The issue here is that you're hiding information. Every messages contains *new* information which you didn't mention before. When you post the debug output, you edit it to delete most of the useful information. When the documentation says "don't do that". So the debug output is largely useless.
You're trying *very* hard to make it difficult for us to help you. This is not helpful.
In the end, the configuration you want is pretty simple. It shouldn't take 4 months to configure the server to (a) proxy a packet from one system to another, and (b) authenticate a user against LDAP.
Ask *simple* questions. "How do I do X?" You will get helpful answers. If your questions are instead "I tried to do a bunch of stuff and it didn't work", then the only possible answer is "maybe do different stuff?"
How do you proxy packets from one system to the other? Read proxy.conf. Configure a realm "example.com". Then, send packets containing "username@example.com". It's that simple.
So... what did you do? Did you configure a realm? If so, how?
You said that you spent 4 months reading documentation. That's nice... but what did you *do* to configure the server? We need to know what. For some reason, you're not telling us. And I don't know why. If you *do* tell us what you did, then we can give useful advice, and pretty quickly.
Until then, we're stuck, because you're not telling us anything useful.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (5)
-
Alan Buxey -
Alan DeKok -
Geoffrey D. Bennett -
Julien COCHENNEC -
Julien Cochennec