Password gets changed while proxying
Hi! We're proxying auth requests to another RADIUS service and encounter the following problem: The password seems to get changed somewhere along the way. In our case, a 9 character password arrives as 16 character garbage at the home server, which then -of course- rejects the access request. Unfortunately, we don't have direct access to the home server, but the provider is convinced that the password gets mangled on our side. I can see the correct password in our FreeRADIUS debug logs. Other than preprocess, there's no module, which theoretically could change the password, before the proxy realm . My guess is that this is some sort of double encoding problem… Or maybe that the password doesn't get decoded properly on their side? Has anyone encountered a similar situation? Thanks! JB
Are you sure the RADIUS secret is the right one? On Wed, Oct 2, 2013 at 12:14 PM, JB <list.freeradius@me.com> wrote:
Hi!
We're proxying auth requests to another RADIUS service and encounter the following problem: The password seems to get changed somewhere along the way. In our case, a 9 character password arrives as 16 character garbage at the home server, which then -of course- rejects the access request. Unfortunately, we don't have direct access to the home server, but the provider is convinced that the password gets mangled on our side.
I can see the correct password in our FreeRADIUS debug logs. Other than preprocess, there's no module, which theoretically could change the password, before the proxy realm .
My guess is that this is some sort of double encoding problem… Or maybe that the password doesn't get decoded properly on their side?
Has anyone encountered a similar situation?
Thanks! JB
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yes, we double checked the secret. Am 02.10.2013 um 18:20 schrieb Francois Gaudreault <fgaudreault@cloudops.com>:
Are you sure the RADIUS secret is the right one?
On Wed, Oct 2, 2013 at 12:14 PM, JB <list.freeradius@me.com> wrote: Hi!
We're proxying auth requests to another RADIUS service and encounter the following problem: The password seems to get changed somewhere along the way. In our case, a 9 character password arrives as 16 character garbage at the home server, which then -of course- rejects the access request. Unfortunately, we don't have direct access to the home server, but the provider is convinced that the password gets mangled on our side.
I can see the correct password in our FreeRADIUS debug logs. Other than preprocess, there's no module, which theoretically could change the password, before the proxy realm .
My guess is that this is some sort of double encoding problem… Or maybe that the password doesn't get decoded properly on their side?
Has anyone encountered a similar situation?
Thanks! JB
On 02/10/13 17:30, JB wrote:
Yes, we double checked the secret.
Well, you missed something. There is no other reasonable explanation for the behaviour you're seeing. In *theory* it could be broken MD5 libraries at one end, but that's so unlikely that the possibility can be discarded. You have the shared secret wrong. Check again, using a new shared secret with unambiguous characters i.e. only letters and numbers. Once you've got it working with a simple secret, then change to a complex one.
On 02/10/13 17:14, JB wrote:
Hi!
We're proxying auth requests to another RADIUS service and encounter the following problem: The password seems to get changed somewhere along the way. In our case, a 9 character password arrives as 16 character garbage at the home server, which then -of course- rejects the access request.
You've got the shared secret wrong. This causes password decryption to fail. If you were using Message-Authenticator (as you, and indeed everyone, should be) the entire packet would fail the MA check and be dropped; but since you're not, only the fields encrypted by the shared secret are affected.
Has anyone encountered a similar situation?
Yes, it's called getting the shared secret wrong between two of your servers. To prove this, enable Message-Authenticator validation on the home server. I believe recent versions of FreeRADIUS will include the Message-Authenticator attribute by default. You should see that the home server now refuses to process the request, instead of continuing with a garbled password. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (4)
-
Arran Cudbard-Bell -
Francois Gaudreault -
JB -
Phil Mayers