Re: Upgrading from 1.0.2 to 2.0.0 problems
On Thursday 17 January 2008 02:44:13 Alan DeKok wrote: [EMAIL PROTECTED] wrote: you are calling the unix auth module before suffix - therefore the magic hasnt yet happened. I'd try putting the unix module after the modules that play around with User-Name i.e. the order in the default configuration is wrong, too. I've fixed it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Thanks to both you and Alan Buxey for the help. That was exactly the problem. Now I need to deal with the old legacy users file entries. *ick!* Wm - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upgrading from 1.0.2 to 2.0.0 problems
William wrote: What I am trying to do is set up my main realm to handle either no realm or deal with the default realm, I'm not sure what you mean by that. Do you want those requests to both be proxied, or handled in the local server? Talking about the local server as a main realm confuses things. The problem I am having is that I do not wish to proxy it back to itself to handle the realm (puts it in my log twice, and debug shows it re-submitting it back to itself). Where do I look to solve this? I'm not sure I see a problem. If you have N realms, you can configure each one to be proxied. By default, anything *not* proxied is handled locally. Trying to use the configuration provided as a template. The first causes [EMAIL PROTECTED] to fail, and the second causes it to re-submit it to the server for authentication. How do I fix this, or where is there some detailed documentation on how to configure this? Configure... what, exactly? I think you're getting stuck on trying to make particular configurations work. You should instead state the requirements as clearly as possible. Odds are that a simple configuration will be straightforward. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upgrading from 1.0.2 to 2.0.0 problems
On Wednesday 16 January 2008 16:39:38 Alan DeKok wrote: Configure... what, exactly? I think you're getting stuck on trying to make particular configurations work. You should instead state the requirements as clearly as possible. Odds are that a simple configuration will be straightforward. Fair enough. What I have is one local radius server. We will need to proxy later, but for now, I just want to get local users properly authenticated. The situation is that we have a lot of legacy users who only enter a username, without realm information, and passwords for their connections. Those work fine. When newer users enter [EMAIL PROTECTED] for their password I need to strip off the realm, and authenticate that user. Our old system used the strip directive to do this. I cannot figure out how 2.0 does this. The problem becomes that if they put a different realm on the username, we will need to either proxy it (later configuration issue, not for now) or reject it. We currently use the Linux system password file for authentication, though that is planned for migration to SQL at a later date. Wm - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upgrading from 1.0.2 to 2.0.0 problems
William wrote:
The situation is that we have a lot of legacy users who only enter a
username,
without realm information, and passwords for their connections. Those work
fine. When newer users enter [EMAIL PROTECTED] for their password I need to
strip off the realm, and authenticate that user.
In 2.0, add the following to proxy.conf:
realm example.com {
}
Once that's done, the default configuration in 2.0 will treat
[EMAIL PROTECTED] the same as user. See the debug output, where it
shows it stripping the realm.
Our old system used the strip directive to do this. I cannot figure out how
2.0 does this. The problem becomes that if they put a different realm on the
username, we will need to either proxy it (later configuration issue, not for
now) or reject it.
Later, add a home server configuration to the realm, and it will be
proxied.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upgrading from 1.0.2 to 2.0.0 problems
On Wednesday 16 January 2008 16:58:09 Alan DeKok wrote:
William wrote:
The situation is that we have a lot of legacy users who only enter a
username, without realm information, and passwords for their connections.
Those work fine. When newer users enter [EMAIL PROTECTED] for their
password I need to strip off the realm, and authenticate that user.
In 2.0, add the following to proxy.conf:
realm example.com {
}
Once that's done, the default configuration in 2.0 will treat
[EMAIL PROTECTED] the same as user. See the debug output, where it
shows it stripping the realm.
Our old system used the strip directive to do this. I cannot figure out
how 2.0 does this. The problem becomes that if they put a different
realm on the username, we will need to either proxy it (later
configuration issue, not for now) or reject it.
That causes anyone using [EMAIL PROTECTED] to fail, yet if they just use
username it works. (Debug output below)
rad_recv: Access-Request packet from host 192.168.1.64 port 32775, id=35,
length=62
User-Name = test
User-Password = mytest4
NAS-IP-Address = 127.0.0.2
NAS-Port = 0
Framed-Protocol = PPP
+- entering group authorize
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[unix] returns updated
rlm_realm: No '@' in User-Name = test, looking up realm NULL
rlm_realm: No such realm NULL
++[suffix] returns noop
WARNING: Deprecated conditional expansion :-. See man unlang for details
expand: %{Stripped-User-Name:-%{User-Name}} - test
users: Matched entry DEFAULT at line 172
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
rad_check_password: Found Auth-Type
auth: type PAP
+- entering group PAP
rlm_pap: login attempt with password mytest4
rlm_pap: Using CRYPT encryption.
rlm_pap: User authenticated successfully
++[pap] returns ok
Login OK: [test/mytest4] (from client flyer port 0)
Sending Access-Accept of id 35 to 192.168.1.64 port 32775
Framed-Protocol = PPP
Framed-Compression = Van-Jacobson-TCP-IP
Finished request 0.
Going to the next request
Waking up in 0.9 seconds.
Waking up in 4.0 seconds.
Cleaning up request 0 ID 35 with timestamp +7
Ready to process requests.
rad_recv: Access-Request packet from host 192.168.1.64 port 32775, id=43,
length=76
User-Name = [EMAIL PROTECTED]
User-Password = mytest4
NAS-IP-Address = 127.0.0.2
NAS-Port = 0
Framed-Protocol = PPP
+- entering group authorize
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[unix] returns notfound
rlm_realm: Looking up realm netonecom.net for User-Name
= [EMAIL PROTECTED]
rlm_realm: Found realm netonecom.net
rlm_realm: Adding Stripped-User-Name = test
rlm_realm: Proxying request from user test to realm netonecom.net
rlm_realm: Adding Realm = netonecom.net
rlm_realm: Authentication realm is LOCAL.
++[suffix] returns noop
WARNING: Deprecated conditional expansion :-. See man unlang for details
expand: %{Stripped-User-Name:-%{User-Name}} - test
users: Matched entry DEFAULT at line 172
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
rlm_pap: WARNING! No known good password found for the user. Authentication
may fail because of this.
++[pap] returns noop
auth: No authenticate method (Auth-Type) configuration found for the request:
Rejecting the user
auth: Failed to validate the user.
Login incorrect: [EMAIL PROTECTED]/mytest4] (from client flyer port 0)
Found Post-Auth-Type Reject
+- entering group REJECT
expand: %{User-Name} - [EMAIL PROTECTED]
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 1 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 1
Sending Access-Reject of id 43 to 192.168.1.64 port 32775
Waking up in 4.9 seconds.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upgrading from 1.0.2 to 2.0.0 problems
Hi,
the first request looks like this.NOTE the test order...
rad_recv: Access-Request packet from host 192.168.1.64 port 32775, id=35,
User-Name = test
+- entering group authorize
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[unix] returns updated
^^^
++[suffix] returns noop
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns updated
rad_check_password: Found Auth-Type
auth: type PAP
+- entering group PAP
rlm_pap: login attempt with password mytest4
rlm_pap: Using CRYPT encryption.
rlm_pap: User authenticated successfully
++[pap] returns ok
Login OK: [test/mytest4] (from client flyer port 0)
second test looks like this:
rad_recv: Access-Request packet from host 192.168.1.64 port 32775, id=43,
User-Name = [EMAIL PROTECTED]
+- entering group authorize
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[unix] returns notfound
^^^
rlm_realm: Looking up realm netonecom.net for User-Name
= [EMAIL PROTECTED]
rlm_realm: Found realm netonecom.net
rlm_realm: Adding Stripped-User-Name = test
rlm_realm: Proxying request from user test to realm netonecom.net
rlm_realm: Adding Realm = netonecom.net
rlm_realm: Authentication realm is LOCAL.
++[suffix] returns noop
WARNING: Deprecated conditional expansion :-. See man unlang for details
expand: %{Stripped-User-Name:-%{User-Name}} - test
users: Matched entry DEFAULT at line 172
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
rlm_pap: WARNING! No known good password found for the user.
Authentication
may fail because of this.
++[pap] returns noop
auth: No authenticate method (Auth-Type) configuration found for the request:
Rejecting the user
you are calling the unix auth module before suffix - therefore the magic
hasnt yet happened. I'd try putting the unix module after the modules
that play around with User-Name
alan
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: Upgrading from 1.0.2 to 2.0.0 problems
[EMAIL PROTECTED] wrote: you are calling the unix auth module before suffix - therefore the magic hasnt yet happened. I'd try putting the unix module after the modules that play around with User-Name i.e. the order in the default configuration is wrong, too. I've fixed it. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
