Realm and users file.
User for Free Radius mail list
f-radius at pcez.com
Wed Jan 25 21:07:57 CET 2006
Kevin,
I did run this in debug mode before I posted on the list, and could not
quite figure it out. So here is part of the debug out below.
Thanks,
Ken
On Tue, 24 Jan 2006, Kevin Bonner wrote:
> On Monday 23 January 2006 20:37, User for Free Radius mail list wrote:
> > The result is domain2.net will Auth OK them but they cannot get on line
> > because domain1.com will reject them because of the "users" file.
> >
> >
> > How do I fix this problem?
> >
> > Thanks!
> >
> > Ken
>
> Running in debug mode should show you what is happening...have you done this?
> If you have and can't figure it out, post the debug output of an example
> where domain2.net auth fails so we can parse the output and hopefully
> determine what needs changed in your config.
>
> Kevin Bonner
>
I put in some notes <> and changed the IP addresses, names and passwords
to protect the what ever...
Going to the next request
Thread 4 waiting to be assigned a request
--- Walking the entire request list ---
Threads: total/active/spare threads = 5/0/5
Waking up in 3 seconds...
rad_recv: Access-Request packet from host 209.111.111.12:1025, id=95,
length=92
Thread 5 assigned request 14
--- Walking the entire request list ---
Threads: total/active/spare threads = 5/1/4
Waking up in 2 seconds...
Thread 5 handling request 14, (3 handled so far)
User-Name = "joeblow at domain2.net"
User-Password = "xxxxxxxx"
NAS-IP-Address = 209.111.111.12
NAS-Port = 20216
NAS-Port-Type = Async
Service-Type = Framed-User
Framed-Protocol = PPP
State = 0x
Acct-Session-Id = "450788469"
modcall: entering group authorize
modcall[authorize]: module "preprocess" returns ok
rlm_realm: Looking up realm domain2.net for User-Name = "joeblow at domain2.net"
rlm_realm: Found realm domain2.net
rlm_realm: Adding Stripped-User-Name = "joeblow"
rlm_realm: Proxying request from user jowblow to realm domain2.net
rlm_realm: Adding Realm = "domain2.net"
rlm_realm: Preparing to proxy authentication request to realm domain2.net
modcall[authorize]: module "suffix" returns updated
users: Matched orchids at 708
^^^^^^^
< NOTE: this is where it searches the "users" file on domain1.com radius
server for the name "joeblow" and finds it at line 708. But this user name
is in this file for the domain1.com NOT domain2.net. For the realm
domain2.net I do not want it to search the "user" file on the domain1.com
server but just be redirected to the domain2.net server and wait for an
answer. >
modcall[authorize]: module "files" returns ok
modcall: group authorize returns updated
Sending Access-Request of id 5 to 209.111.120.21:1645 <<< this is domain2.net server>
User-Name = "joeblow"
User-Password = "L\013\315\2151F\017[\317\215\212\3150J\313\241"
NAS-IP-Address = 209.111.111.12
NAS-Port = 20216
NAS-Port-Type = Async
Service-Type = Framed-User
Framed-Protocol = PPP
State = 0x
Acct-Session-Id = "450788469"
Proxy-State = "95"
Thread 5 waiting to be assigned a request
rad_recv: Access-Accept packet from host 209.111.120.21:1645, id=5, <<< this is domain2.net server>
length=42
Thread 1 assigned request 14
Waking up in 2 seconds...
Thread 1 handling request 14, (4 handled so far)
Framed-IP-Address = 255.255.255.254
Framed-MTU = 576
Service-Type = Framed-User
Proxy-State = 0x3935
modcall: entering group authorize
modcall[authorize]: module "preprocess" returns ok
rlm_realm: Proxy reply, or no user name. Ignoring.
modcall[authorize]: module "suffix" returns noop
users: Matched orchids at 708
modcall[authorize]: module "files" returns ok
modcall: group authorize returns ok
rad_check_password: Found Auth-Type Reject
rad_check_password: Auth-Type = Reject, rejecting user
auth: Failed to validate the user.
Login incorrect: [joeblow at domain2.net/xxxxxxx] (from client abc8 port 20216)
Delaying request 14 for 1 seconds
Finished request 14
Going to the next request
Thread 1 waiting to be assigned a request
--- Walking the entire request list ---
Threads: total/active/spare threads = 5/0/5
Sending Access-Reject of id 95 to 209.111.111.12:1025
Cleaning up request 10 ID 146 with timestamp 43d57a06
Waking up in 7 seconds...
--- Walking the entire request list ---
Cleaning up request 12 ID 193 with timestamp 43d57a0d
Waking up in 2 seconds...
--- Walking the entire request list ---
Cleaning up request 14 ID 95 with timestamp 43d57a0f
Nothing to do. Sleeping until we see a request.
More information about the Freeradius-Users
mailing list