The year started with boring and hectic problems, only now had time to
get back to PF.
Well, I knew that I’m getting closer ;)
First of all I did uncomment “packefence-local-auth” sometime ago but
when both Fabrice and you mentioned it again I went through the file
and found a second line with this parameter that was commented.
In the section for “inner-tunnel server” it was still commented.
Now database password encryption type. For some reason it just doesn’t
want to work to me when I had it set to NTLM.
Changed it to Plain-text and then had to recreate the local users to
make it work.
I’m not very concerned about the passwords encryption type for now as
we plan to integrate PF with AD.
By the way, is there any way to restart MariaDB service from PF GUI ?
I couldn’t find it in the “Status-Services” section.
And CentOS says that it is pf-mariadb but it can’t be restarted with
the regular OS script systemctl
Thank you very much, Fabrice and Timothy!
Eugene
*From:*Timothy Mullican [mailto:[email protected]]
*Sent:* Wednesday, January 03, 2018 6:08 AM
*To:* [email protected]
*Cc:* Fabrice Durand; [email protected]
*Subject:* Re: [PacketFence-users] Need an advice and maybe assistance
with FreeRADIUS
Eugene,
Did you uncomment the “packetfence-local-auth” line in
/usr/local/pf/conf/radiusd/packetfence-tunnel ?
Also you will have to change the database password encryption type to
plain or NTLM under Configuration->System Configuration->Main
Configuration->Database passwords hashing mechanism.
I would then try restarting all the PacketFence services. Let me know
if this doesn’t work.
Thanks,
Tim
Sent from mobile phone
On Jan 3, 2018, at 07:50, Fabrice Durand via PacketFence-users
<[email protected]
<mailto:[email protected]>> wrote:
I tried to add the DAS parameter directly in the configuration
file of the AP and it works (CoA), but the limitation is that you
can enable it only on one ssid.
https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
Regards
Fabrice
Le 2017-12-29 à 16:18, Timothy Mullican via PacketFence-users a
écrit :
It may be possible to skip the controller and run the
deauthentication command on the AP itself, but it is product
specific as opposed to the controller API, which is
cross-product. The UniFi code on PacketFence would have to be
modified to support this.
See
https://community.ubnt.com/t5/UniFi-Wireless/Issue-manual-kick-sta-command/m-p/1197157/highlight/true#M95831
Sent from mobile phone
On Dec 29, 2017, at 15:12, Timothy Mullican via
PacketFence-users <[email protected]
<mailto:[email protected]>> wrote:
I am running UniFi AP 3.9.15.8011 and Controller 5.6.26
(I’m using linuxserver/UniFi docker image on CentOS 7.4).
First, make sure you applied the UniFi patch (see
https://community.ubnt.com/t5/UniFi-Wireless/Packetfence-7-1-Out-of-Band-Dynamic-VLAN-with-Unifi/m-p/2134984/highlight/true#M261219).
This enables dynamic VLAN assignment using radius and
802.1x on the PacketFence side. The latest UniFi firmware
also allows dynamic vlan assignment using MAC
authentication (i.e., guest access). If you have any
questions about this let me know and I can help you (also
see my earlier thread).
If you are using the PacketFence captive portal
authentication to assign a user’s VLAN, PacketFence
requires the UniFi controller to deauthenticate clients
from the AP. If you look at
https://github.com/inverse-inc/packetfence/pull/2735/files#diff-8b99f599546e7710d1df6b776d184569,
you can see the deauthentication method used is an HTTPS
API call to the controller running the “kick-sta” command
on the client MAC address. As you are probably aware, the
user must reauthenticate in order to be placed in the
correct VLAN after successfully authenticating.
PacketFence automates this process in several ways
(HTTP/HTTPS, SNMP, Telnet/SSH, RADIUS CoA).
As far as I know, the only way to deauthenticate a client
on the AP is using the Controller API over HTTPS (no
support for CoA yet). If CoA is implemented we should be
able to bypass the controller and send direct client
RADIUS deauthentication requests to the AP.
If you are using 802.1x without the captive portal, you
may be able to get away without relying on the controller,
since the VLAN is only assigned once at logon to the AP,
but I have not tested this yet.
Fabrice may be able to help if I didn’t explain something
correctly above.
Tim
On Dec 29, 2017, at 12:38, E.P. <[email protected]
<mailto:[email protected]>> wrote:
Hi Timothy,
I’m really-really grateful to you and your comments.
May I ask you what firmware level you run on your
Unifi AP ?
And by the way, just out of curiosity, why we need
controller IP address in the settings for AP/switch ?
I thought that the real RADIUS client is the AP
and the controller’s only job is to push settings
including WPA-Enterprise/RADIUS to AP
Eugene
*From:*Timothy Mullican
[mailto:[email protected]]
*Sent:* Friday, December 29, 2017 9:34 AM
*To:* [email protected]
<mailto:[email protected]>
*Cc:* E.P.; Fabrice Durand
*Subject:* Re: [PacketFence-users] Need an advice
and maybe assistance with FreeRADIUS
Eugene,
Just a thought, but can you change the
deauthentication method to HTTPS and specify the
UniFi controller IP? See my setup below:
https://i.imgsafe.org/0c/0cff2c7f19.png
https://i.imgsafe.org/0c/0cff2dfd99.png
My UniFi AP is 192.168.20.7
My UniFi controller is 192.168.20.6
This is my UniFi AP setup:
https://i.imgsafe.org/05/05bbb5eafe.png
https://i.imgsafe.org/05/05bbd86ab4.png
Also please make sure you have the latest UniFi AP
and controller firmware as they were just updated
a few days ago.
See my earlier post on the PacketFence-Users forum
if you have questions.
Tim
Sent from mobile phone
On Dec 29, 2017, at 07:59, Fabrice Durand via
PacketFence-users
<[email protected]
<mailto:[email protected]>>
wrote:
For me it looks that 172.19.254.2 is define twice.
Can you do in /usr/local/pf/raddb:
grep 172.19.254.2 * -r
Also can you try to run radiusd in debug mode
and see if you can see 172.19.254.2 (radiusd
-d /usr/local/pf/raddb -n auth -X)
Regards
Fabrice
Le 2017-12-29 à 01:26, E.P. a écrit :
Nah…
No luck at all, Fabrice. I’m becoming
desperate ;)
I thought it has to do with Unifi
controller (reading it here in other
threads that it is far from being
error-free) but I pointed it to FreeRADIUS
running on DaloRADIUS host and the regular
user authentication worked nice.
I just don’t like DaloRADIUS due to its
limitations and support and hold my
aspiration towards PF.
Well, here we go again, I reconfigured the
entry in switches file and it looks very
simplistic, 172.19.254.2 is the IP address
of Unifi AP.
/[root@PacketFence-ZEN conf]# cat
./switches.conf/
/[172.19.254.2]/
/VoIPCDPDetect=N/
/VoIPDHCPDetect=N/
/deauthMethod=RADIUS/
/description=Test-WAP/
/VoIPLLDPDetect=N/
/radiusSecret=1234567890/
/VlanMap=N/
Someone who uses Unifi may be jump in to
validate my settings please.
In the settings for a specific wireless
network I select “WPA Enterprise” and
select RADIUS profile that I configured
separately pointing to PF IP address. The
RADIUS profile is configured as usual, i.e.
IP address, ports which are 1812/1813 and
shared secret, nothing fancy about it.
Both radius log files show the same
consistent error:
/Dec 29 06:10:24 PacketFence-ZEN
acct[13247]: Dropping packet without
response because of error: Received
Accounting-Request packet from client
172.19.254.2 with invalid Request
Authenticator! (Shared secret is incorrect.)/
//
/Dec 29 06:20:29 PacketFence-ZEN
auth[13273]: Dropping packet without
response because of error: Received packet
from 172.19.254.2 with invalid
Message-Authenticator! (Shared secret is
incorrect.)/
I don’t think I have to start radius in
debugging mode to have more output, do I ?
Eugene
*From:*Durand fabrice
[mailto:[email protected]]
*Sent:* Thursday, December 28, 2017 5:17 PM
*To:* E.P.;
[email protected]
<mailto:[email protected]>
*Subject:* Re: [PacketFence-users] Need an
advice and maybe assistance with FreeRADIUS
Can you try pfcmd configreload hard and
restart radius. (pfcmd service radiusd
restart)
Le 2017-12-28 à 19:20, E.P. a écrit :
I should have made my previous email
shorter because my main question fell
into cracks.
Why do I have an error with the shared
secret? Quoting it here again:
When I test this with a real network
device, Unifi WAP for example, I don’t
go anywhere.
I see that NAD is added, here’s an
entry from radius.log
/Dec 28 07:42:46 PacketFence-ZEN
auth[16806]: Adding client
172.19.254.2/32 with shared secret
"123456"/
When I try to authenticate from an
endpoint to a specific SSID I see this
error in radius-acct.log
/Dec 28 07:38:58 PacketFence-ZEN
acct[16780]: Dropping packet without
response because of error: Received
Accounting-Request packet from client
172.19.254.2 with invalid Request
Authenticator! (Shared secret is
incorrect.)/
I added this WAP under “Policies and
access control” in Switches section
using the shared secret as shown above
and following the admin guide. What am
I doing wrong ?
Here’s how the switches.conf file
looks like after I added this WAP:
/[root@PacketFence-ZEN conf]# cat
./switches.conf/
/[172.19.254.2]/
/VoIPCDPDetect=N/
/VoIPDHCPDetect=N/
/deauthMethod=RADIUS/
/description=Test-WAP/
/VoIPLLDPDetect=N/
/radiusSecret=123456/
/VlanMap=N/
Eugene
*From:*Durand fabrice via
PacketFence-users
[mailto:[email protected]]
*Sent:* Thursday, December 28, 2017
3:30 PM
*To:*
[email protected]
<mailto:[email protected]>
*Cc:* Durand fabrice
*Subject:* Re: [PacketFence-users]
Need an advice and maybe assistance
with FreeRADIUS
Hello Eugene,
in fact for 802.1x you need to use
eapol_test instead of radtest.
(http://deployingradius.com/scripts/eapol_test/)
Also use the port 1812 instead of 18120.
Regards
Fabrice
Le 2017-12-28 à 03:07, E.P. via
PacketFence-users a écrit :
Guys,
I still hope someone with more
experience with PF give me a hand
with this trivial issue (if it is
an issue)
I’m on my way to test PF with baby
steps and just created a user
under Users section in PF GUI.
Then I test it using a simple
command like this and it seems to
work using the local identity store.
/[//root@PacketFence-ZEN bin]#
./pftest authentication test1 123456/
/Testing authentication for "test1"/
//
/Authenticating against local/
/Authentication SUCCEEDED against
local (Authentication successful.)/
/Matched against local for
'authentication' rules/
/set_access_level : User Manager/
/set_unreg_date : 0000-00-00 00:00:00/
/Matched against local for
'administration' rules/
/set_access_level : User Manager/
/set_unreg_date : 0000-00-00 00:00:00/
Then I’m following the admin guide
and want to test this user
authentication using radtest
command as in
/[root@PacketFence-ZEN bin]#
radtest test1 123456
localhost:18120 12 testing123/
/Sent Access-Request Id 136 from
0.0.0.0:45055 to 127.0.0.1:18120
length 75/
/User-Name = "test1"/
/User-Password = "123456"/
/NAS-IP-Address = 172.16.0.222/
/NAS-Port = 12/
/Message-Authenticator = 0x00/
/Cleartext-Password = "123456"/
/Received Access-Reject Id 136
from 127.0.0.1:18120 to 0.0.0.0:0
length 20/
(0)/-: Expected Access-Accept got
Access-Reject/
Why am I rejected here ? Am I not
supposed to use this test1 user to
test RADIUS with the proxy module ?
And finally, when I test this with
a real network device, Unifi WAP
for example, I don’t go anywhere.
I see that NAD is added, here’s an
entry from radius.log
/Dec 28 07:42:46 PacketFence-ZEN
auth[16806]: Adding client
172.19.254.2/32 with shared secret
"123456"/
When I try to authenticate for an
endpoint to a specific SSID I see
this error in radius-acct.log
/Dec 28 07:38:58 PacketFence-ZEN
acct[16780]: Dropping packet
without response because of error:
Received Accounting-Request packet
from client 172.19.254.2 with
invalid Request Authenticator!
(Shared secret is incorrect.)/
I added this WAP under “Policies
and access control” in Switches
section using the shared secret as
shown above and following the
admin guide. What am I doing wrong ?
Here’s how the switches.conf file
looks like after I added this WAP:
/[root@PacketFence-ZEN conf]# cat
./switches.conf/
/[172.19.254.2]/
/VoIPCDPDetect=N/
/VoIPDHCPDetect=N/
/deauthMethod=RADIUS/
/description=Test-WAP/
/VoIPLLDPDetect=N/
/radiusSecret=123456/
/VlanMap=N/
Just to confirm, I’m not doing any
inline mode, nor guest or web
authentication, just pure
WPA-Enterprise with RADIUS
internal users identity store.
Eugene
------------------------------------------------------------------------------
Check out the vibrant tech community on one
of the world's most
engaging tech sites,Slashdot.org
<http://Slashdot.org>!http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
--
Fabrice Durand
[email protected] <mailto:[email protected]> ::
+1.514.447.4918 (x135) ::www.inverse.ca <http://www.inverse.ca>
Inverse inc. :: Leaders behind SOGo
(http://www.sogo.nu) and PacketFence (http://packetfence.org)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of
the world's most
engaging tech sites, Slashdot.org
<http://Slashdot.org>! http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's
most
engaging tech sites, Slashdot.org <http://Slashdot.org>!
http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites,Slashdot.org
<http://Slashdot.org>!http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
--
Fabrice Durand
[email protected] <mailto:[email protected]> :: +1.514.447.4918 (x135)
::www.inverse.ca <http://www.inverse.ca>
Inverse inc. :: Leaders behind SOGo (http://www.sogo.nu) and PacketFence
(http://packetfence.org)
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org <http://Slashdot.org>!
http://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
[email protected]
<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/packetfence-users
