[Packetfence-users] Trouble with RADIUS and Captive Portal auth

[Sallee, Stephen (Jake)]

OK! I have the RADIUS server setup correctly and ntlm_auth returns OK, so I know that it works. However when I try to use the radius for the captive portal auth I get an error on the client that says invalid login or password. However I see that the user is accepted in the radius debug:

rad_recv: Access-Request packet from host 127.0.0.1 port 34053, id=170, length=66
User-Name = "***@umhb.edu"
User-Password = ********************************************
NAS-IP-Address = 127.0.0.1
server packetfence {
+- entering group authorize {...}
[suffix] Looking up realm "umhb.edu" for User-Name = "***@umhb.edu"
[suffix] Found realm "umhb.edu"
[suffix] Adding Stripped-User-Name = "Jake.Sallee"
[suffix] Adding Realm = "umhb.edu"
[suffix] Authentication realm is LOCAL.
++[suffix] returns ok
++[preprocess] returns ok
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry DEFAULT at line 1
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
GOT CLONE 1493856848 0x69520f0
rlm_perl: Added pair User-Name = ***@umhb.edu
rlm_perl: Added pair User-Password = ********************************************
rlm_perl: Added pair Realm = umhb.edu
rlm_perl: Added pair Stripped-User-Name = Jake.Sallee
rlm_perl: Added pair NAS-IP-Address = 127.0.0.1
rlm_perl: Added pair Auth-Type = Accept
++[perl] returns noop
Found Auth-Type = Accept
Auth-Type = Accept, accepting the user
+- entering group post-auth {...}
++[exec] returns noop
rlm_perl: Added pair User-Name = ***@umhb.edu
rlm_perl: Added pair User-Password = ********************************************
rlm_perl: Added pair Realm = umhb.edu
rlm_perl: Added pair NAS-IP-Address = 127.0.0.1
rlm_perl: Added pair Stripped-User-Name = Jake.Sallee
rlm_perl: Added pair Auth-Type = Accept
++[perl] returns ok
} # server packetfence
Sending Access-Accept of id 170 to 127.0.0.1 port 34053
Finished request 0.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 0 ID 170 with timestamp +7
Ready to process requests.

In the message log I get the following:

NAC01 radiusd_pf[11971]: warning: mac address is empty or invalid in this request. It could be normal on certain radius calls

And in the packetfence.log I get:

May 16 17:15:02 redir.cgi(0) INFO: 10.11.30.12 not resolvable, generating error page (ModPerl::ROOT::ModPerl::PerlRun::usr_local_pf_cgi_2dbin_redir_2ecgi::handler)
May 16 17:15:02 redir.cgi(0) INFO: could not resolve 10.11.30.12 to mac in ARP table (pf::iplog::ip2macinarp)
May 16 17:15:02 redir.cgi(0) WARN: could not resolve 10.11.30.12 to mac (pf::iplog::ip2mac)

BUT the node shows up in the node table with the correct MAC... what could be causing this?

Also, when trying to auth through the captive portal it seems that the user is ALWAYS accepted no matter what, I tested this by entering gibberish into the username and password fields and I still got an access accept from the radius server. I am pretty sure this is not supposed to happen.

Jake Sallee
Godfather of Bandwidth
Network Engineer
University of Mary Hardin-Baylor
900 College St.
Belton, Texas
76513
Fone: 254-295-4658
Phax: 254-295-4221

[Olivier Bilodeau]

Post by Sallee, Stephen (Jake)
However when I try to use the radius for the
captive portal auth I get an error on the client that says invalid login

authentication::radius is meant to authenticate a user on another RADIUS
server (an existing source for authentication). It makes little sense to
use it locally you should use authentication::local instead which would
be way lighter.

Now, lets say that you do have a use case for a locally hosted
authentication source in FreeRADIUS then you should create a separate
"site" (FreeRADIUS' virtual-servers) for it without the PacketFence perl
module and trying to avoid the PacketFence's /etc/raddb/users entry.

Why? Because PacketFence always accepts non-EAP connections by design so
it's able to re-direct to the captive portal (you need _some_ network to
reach a captive portal). But if you intend to use the FreeRADIUS site
for authentication then it should be a proper CHAP (or is it PAP?)
FreeRADIUS server.

I hope I made things clearer.

Cheers!

[Sallee, Stephen (Jake)]

I agree that if the users were on the local box authen::local would be the best choice, but all of my users are in our AD. What I need the captive portal to do is authenticate them against our AD and assign them a vlan based on the domain in the username.

I am going to look into creating a custom site in FR to do the captive portal auth, I know it can be done ... looks like I will be trudging through learning it ... wish me luck! Thanks for the info.

Jake Sallee
Godfather of Bandwidth
Network Engineer
University of Mary Hardin-Baylor
900 College St.
Belton, Texas
76513
Fone: 254-295-4658
Phax: 254-295-4221

-----Original Message-----
From: Olivier Bilodeau [mailto:***@inverse.ca]
Sent: Tuesday, May 17, 2011 8:01 AM
To: packetfence-***@lists.sourceforge.net
Subject: Re: [Packetfence-users] Trouble with RADIUS and Captive Portal auth

Post by Sallee, Stephen (Jake)
However when I try to use the radius for the captive portal auth I get
an error on the client that says invalid login or password. However I

authentication::radius is meant to authenticate a user on another RADIUS server (an existing source for authentication). It makes little sense to use it locally you should use authentication::local instead which would be way lighter.

Now, lets say that you do have a use case for a locally hosted authentication source in FreeRADIUS then you should create a separate "site" (FreeRADIUS' virtual-servers) for it without the PacketFence perl module and trying to avoid the PacketFence's /etc/raddb/users entry.

Why? Because PacketFence always accepts non-EAP connections by design so it's able to re-direct to the captive portal (you need _some_ network to reach a captive portal). But if you intend to use the FreeRADIUS site for authentication then it should be a proper CHAP (or is it PAP?) FreeRADIUS server.

I hope I made things clearer.

Cheers!
--
Olivier Bilodeau
***@inverse.ca :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)

[Olivier Bilodeau]

Post by Sallee, Stephen (Jake)
I agree that if the users were on the local box authen::local would be the best choice, but all of my users are in our AD. What I need the captive portal to do is authenticate them against our AD and assign them a vlan based on the domain in the username.

AD authentication should be done with the authentication::ldap module.
I'm pretty sure it's covered in one of our guides.

Domain-based VLAN assignment will need a bit more work.
You could:
a) create several authenti...:ldap with one for each domain and there
would be a drop down available on the captive portal to chose the domain
then you alter the pf::web::custom to categorize the nodes properly then
modify pf::vlan::custom to return VLANs based on said categories

b)
- add something in pf::web::custom to categorize the node based on
domain using a regexp on the username then modify pf::vlan::custom to
return VLANs based on said categories

[Sallee, Stephen (Jake)]

add something in pf::web::custom to categorize the node based on domain using a regexp on the username then modify pf::vlan::custom to return VLANs based on said categories

Actually Inverse already did something very similar for me they helped me make the following change to my vlan::custom file:

if (defined($user_name) && $user_name =~ /\@umhb/i) {
return $switch->getVlanByName('customVlan1');
} elsif (defined($user_name) && $user_name =~ /\@cru/i) {
return $switch->getVlanByName('customVlan2');
}

This should have the net effect of returning cutomVlan1 for my users in the umhb.edu domain and customVlan2 for the users in my Cru domain. My problem is that I don't seem to be getting that far. The user is accepted (right now the user is accepted no matter what but I am looking into that) but for some reason it doesn't seem like FR is telling PF that the user is good to go and to accept them.

Jake Sallee
Godfather of Bandwidth
Network Engineer
University of Mary Hardin-Baylor
900 College St.
Belton, Texas
76513
Fone: 254-295-4658
Phax: 254-295-4221


-----Original Message-----
From: Olivier Bilodeau [mailto:***@inverse.ca]
Sent: Tuesday, May 17, 2011 9:08 AM
To: packetfence-***@lists.sourceforge.net
Subject: Re: [Packetfence-users] Trouble with RADIUS and Captive Portal auth

I agree that if the users were on the local box authen::local would be the best choice, but all of my users are in our AD. What I need the captive portal to do is authenticate them against our AD and assign them a vlan based on the domain in the username.

AD authentication should be done with the authentication::ldap module.
I'm pretty sure it's covered in one of our guides.

Domain-based VLAN assignment will need a bit more work.
You could:
a) create several authenti...:ldap with one for each domain and there would be a drop down available on the captive portal to chose the domain then you alter the pf::web::custom to categorize the nodes properly then modify pf::vlan::custom to return VLANs based on said categories

b)
- add something in pf::web::custom to categorize the node based on domain using a regexp on the username then modify pf::vlan::custom to return VLANs based on said categories


--
Olivier Bilodeau
***@inverse.ca :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)

[Olivier Bilodeau]

Post by Sallee, Stephen (Jake)
My problem is that I don't seem to be getting that far. The user is accepted (right now the user is accepted no matter what but I am looking into that) but for some reason it doesn't seem like FR is telling PF that the user is good to go and to accept them.

As I said earlier, in the captive portal, you should *not* ask
FreeRADIUS for authentication (its configured to talk to switches not to
provide AD authentication), you should use authentication::ldap instead.

[DOMINEAUX Philippe]

Hi,

I try to authenticate in Captive Portal via LDAP auth but PacketFence give me that error:

WARN: Unable to find user '***@icm-institute.org' (authentication::ldap::authenticate)

All the LDAP/AD parameters are configured to feet to your documentation but it seems that it failed.

wbinfo output:
wbinfo -a philippe.domineaux
Enter philippe.domineaux's password:
plaintext password authentication succeeded
Enter philippe.domineaux's password:
challenge/response password authentication succeeded

Any ideas?

Philippe Domineaux
Administrateur Réseau - Network Administrator

ICM - Institut du Cerveau et de la Moelle épinière
CHU Pitié-Salpêtrière
47, bd de l'Hôpital - 75013 Paris
Tél.  + 33 (0)1 57 27 40 42
Fax. + 33 (0)1 57 27 40 39
www.icm-institute.org <http://www.icm-institute.org/> 

-----Message d'origine-----
De : Olivier Bilodeau [mailto:***@inverse.ca]
Envoyé : mercredi 18 mai 2011 15:29
À : packetfence-***@lists.sourceforge.net
Objet : Re: [Packetfence-users] Trouble with RADIUS and Captive Portal auth

Post by Sallee, Stephen (Jake)
My problem is that I don't seem to be getting that far. The user is accepted (right now the user is accepted no matter what but I am looking into that) but for some reason it doesn't seem like FR is telling PF that the user is good to go and to accept them.

As I said earlier, in the captive portal, you should *not* ask FreeRADIUS for authentication (its configured to talk to switches not to provide AD authentication), you should use authentication::ldap instead.

--
Olivier Bilodeau
***@inverse.ca :: +1.514.447.4918 *115 :: www.inverse.ca Inverse inc. :: Leaders behind SOGo (www.sogo.nu) and PacketFence
(www.packetfence.org)

[Olivier Bilodeau]

Post by DOMINEAUX Philippe
All the LDAP/AD parameters are configured to feet to your documentation but it seems that it failed.

LDAP should be tested with ldapsearch, not wbinfo.

Here's a way to do it:
ldapsearch -x -b <LDAPUserBase> -h <LDAPServer> -W -D <LDAPBindDN>
<LDAPUserKey>=username dn

Replace <..> with your info. You'll be prompted for a bind password. If
you can't bind there's your problem.