On Tue, 5 Nov 2002, Alan DeKok wrote:
> So run the server in debugging mode, as it suggests in the README,
> the documention, and in the FAQ.
>
I'll start here with an apology to the list. This was inexcusable on my
part. Thanks for going easy.
Here's the debugging info as requested. In my users file, I added:
DEFAULT Auth-Type = Kerberos
Reply-Message = "Hello, Brian"
to the top. clients.conf has the proper information for localhost, so I
ran "radtest mbjohn [password] localhost 0 testing123". Below is what I
got from debugging on the server. I'm not sure what's needed, and it's
rather verbose using the -xx option, so for brevity, I'm just posting from
the "Listening on IP address..." part. I'll be happy to provide anything
before, if needed.
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp.
Ready to process requests.
Thread 1 waiting to be assigned a request
Thread 2 waiting to be assigned a request
Thread 3 waiting to be assigned a request
Thread 4 waiting to be assigned a request
Thread 5 waiting to be assigned a request
rad_recv: Access-Request packet from host 127.0.0.1:1032, id=111, length=55
Thread 1 assigned request 0
--- Walking the entire request list ---
Threads: total/active/spare threads = 5/1/4
Waking up in 5 seconds...
Thread 1 handling request 0, (1 handled so far)
User-Name = "mbjohn"
User-Password = "(t\342uf\275H4\351_\350\321\023\224\230\367"
NAS-IP-Address = 255.255.255.255
NAS-Port-Id = "0"
modcall: entering group authorize
modcall[authorize]: module "preprocess" returns ok
rlm_realm: Looking up realm NULL for User-Name = "mbjohn"
rlm_realm: No such realm NULL
modcall[authorize]: module "suffix" returns noop
modcall[authorize]: module "files" returns notfound
modcall: group authorize returns ok
auth: No authenticate method (Auth-Type) configuration found for the request:
Rejecting the user
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
Thread 1 waiting to be assigned a request
rad_recv: Access-Request packet from host 127.0.0.1:1032, id=111, length=55
Sending Access-Reject of id 111 to 127.0.0.1:1032
--- Walking the entire request list ---
Threads: total/active/spare threads = 5/0/5
Waking up in 3 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 111 with timestamp 3dc92509
Nothing to do. Sleeping until we see a request.
MASTER: exit on signal (2)
I then added the appropriate info for a remote client in clients.conf, ran
"radtest mbjohn [password] 152.3.2.153 0 testing123" and got this
debugging information from the server:
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp.
Ready to process requests.
Thread 3 waiting to be assigned a request
Thread 4 waiting to be assigned a request
Thread 5 waiting to be assigned a request
rad_recv: Access-Request packet from host 152.16.0.183:1031, id=64, length=55
Thread 1 assigned request 0
--- Walking the entire request list ---
Threads: total/active/spare threads = 5/1/4
Waking up in 5 seconds...
Thread 1 handling request 0, (1 handled so far)
User-Name = "mbjohn"
User-Password = "'\322\220\221\356P\3505M\355\221\3104\305\316\355"
NAS-IP-Address = 255.255.255.255
NAS-Port-Id = "0"
modcall: entering group authorize
modcall[authorize]: module "preprocess" returns ok
rlm_realm: Looking up realm NULL for User-Name = "mbjohn"
rlm_realm: No such realm NULL
modcall[authorize]: module "suffix" returns noop
modcall[authorize]: module "files" returns notfound
modcall: group authorize returns ok
auth: No authenticate method (Auth-Type) configuration found for the request:
Rejecting the user
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
Thread 1 waiting to be assigned a request
rad_recv: Access-Request packet from host 152.16.0.183:1031, id=64, length=55
Sending Access-Reject of id 64 to 152.16.0.183:1031
--- Walking the entire request list ---
Threads: total/active/spare threads = 5/0/5
Waking up in 3 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 64 with timestamp 3dc925b2
Nothing to do. Sleeping until we see a request.
MASTER: exit on signal (2)
And this is what I got on the client side (which is nearly identical to
what I got on localhost, which is why it wasn't posted above. Imagine
%s/152.3.2.153/127.0.0.1/g and %s/user-0-183.wireless.duke.edu/hythloth/g,
if you will, everything else is identical):
Sending Access-Request of id 195 to 152.3.2.153:1812
User-Name = "mbjohn"
User-Password = "\212\215\033s\220\361]\237\267\2760pc\016\206"
NAS-IP-Address = user-0-183.wireless.duke.edu
NAS-Port-Id = "0"
Re-sending Access-Request of id 195 to 152.3.2.153:1812
User-Name = "mbjohn"
User-Password = "\212\215\033s\220\361]\237\267\2760pc\016\206"
NAS-IP-Address = user-0-183.wireless.duke.edu
NAS-Port-Id = "0"
rad_recv: Access-Reject packet from host 152.3.2.153:1812, id=195, length=20
And lastly, just to make sure I could authenticate against the radius
server at all, I added:
DEFAULT Password = "mbjohn"
Reply-Message = "Hello, Brian"
To the top of the users file. After doing "radtest mbjohn mbjohn
152.3.2.153 0 testing123" from the remote machine, I got this from the
server:
Listening on IP address *, ports 1812/udp and 1813/udp, with proxy on 1814/udp.
Ready to process requests.
Thread 5 waiting to be assigned a request
rad_recv: Access-Request packet from host 152.16.0.183:1031, id=68, length=55
Thread 1 assigned request 0
--- Walking the entire request list ---
Threads: total/active/spare threads = 5/1/4
Waking up in 5 seconds...
Thread 1 handling request 0, (1 handled so far)
User-Name = "mbjohn"
User-Password = "\341c\201\205\304\002&\361\212\322\315\016Vl6\276"
NAS-IP-Address = 255.255.255.255
NAS-Port-Id = "0"
modcall: entering group authorize
modcall[authorize]: module "preprocess" returns ok
rlm_realm: Looking up realm NULL for User-Name = "mbjohn"
rlm_realm: No such realm NULL
modcall[authorize]: module "suffix" returns noop
users: Matched DEFAULT at 1
modcall[authorize]: module "files" returns ok
modcall: group authorize returns ok
rad_check_password: Found Auth-Type Local
auth: type Local
auth: user supplied User-Password matches local User-Password
radius_xlat: 'Hello, Brian'
Sending Access-Accept of id 68 to 152.16.0.183:1031
Reply-Message = "Hello, Brian"
Finished request 0
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
Waking up in 1 seconds...
MASTER: exit on signal (2)
And from the client:
Sending Access-Request of id 68 to 152.3.2.153:1812
User-Name = "mbjohn"
User-Password =
"\341c\201\205\304\002&\361\212\322\315\016Vl6\276"
NAS-IP-Address = user-0-183.wireless.duke.edu
NAS-Port-Id = "0"
rad_recv: Access-Accept packet from host 152.3.2.153:1812, id=68,
length=34 Reply-Message = "Hello, Brian"
So using just a simple Password in the server appears to work.
> > I noticed that there doesn't seem to be
> > any entry in it for rlm_krb5. Does there need to be something in there?
>
> If you want it to do Kerberos authentication, yes.
Ah, OK, I thought so. Me thinks this is the problem (or at least a big
chunk of it).
> > Also, in one of the mails Alan answered he mentioned that the kerberos
> > daemon does all the work. Does this mean that kerberos server must be
> > running on the same machine as the radius server?
>
> No. It just means that the RADIUS server must somehow be able to
> access the kerberos server.
>
This is definitely good news. Thanks Alan.
I've tried to include as much as possible without including a bunch of
unnecessary parts, but please let me know if there's something else that's
needed and I'll be happy to supply it.
Thanks again,
Brian
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
