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
> <packetfence-users@lists.sourceforge.net> 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
>> <packetfence-users@lists.sourceforge.net> 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. <ype...@gmail.com> 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:tjmullic...@yahoo.com]
>>>>>
>>>>> Sent: Friday, December 29, 2017 9:34 AM
>>>>> To: packetfence-users@lists.sourceforge.net
>>>>> 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
>>>>> <packetfence-users@lists.sourceforge.net> 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:fdur...@inverse.ca]
>>>>> Sent: Thursday, December 28, 2017 5:17 PM
>>>>> To: E.P.; packetfence-users@lists.sourceforge.net
>>>>> 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:packetfence-users@lists.sourceforge.net]
>>>>> Sent: Thursday, December 28, 2017 3:30 PM
>>>>> To: packetfence-users@lists.sourceforge.net
>>>>> 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://sdm.link/slashdot
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PacketFence-users mailing list
>>>>> PacketFence-users@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Fabrice Durand
>>>>> fdur...@inverse.ca :: +1.514.447.4918 (x135) :: 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://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> PacketFence-users mailing list
>>>>> PacketFence-users@lists.sourceforge.net
>>>>> 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://sdm.link/slashdot
>>> _______________________________________________
>>> PacketFence-users mailing list
>>> PacketFence-users@lists.sourceforge.net
>>> 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://sdm.link/slashdot
>>
>>
>> _______________________________________________
>> PacketFence-users mailing list
>> PacketFence-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/packetfence-users
>
> --
> Fabrice Durand
> fdur...@inverse.ca :: +1.514.447.4918 (x135) :: 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://sdm.link/slashdot
> _______________________________________________
> PacketFence-users mailing list
> PacketFence-users@lists.sourceforge.net
> 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://sdm.link/slashdot
_______________________________________________
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users
