Re: [PacketFence-users] Windows client automatically login using hostname and hit non-exist realm

2022-11-04 Thread Fabrice Durand via PacketFence-users 
Hello Irvan,

yes it's normal, we did some unlang to mimic the way the realm is set when
packetfence receives a machine authentication.

https://github.com/inverse-inc/packetfence/blob/devel/raddb/policy.d/packetfence#L36

Regards
Fabrice


Le ven. 4 nov. 2022 à 08:34, Irvan via PacketFence-users <
packetfence-users@lists.sourceforge.net> a écrit :

> Hello Ludovic,
>
> Thank you for your explanation.
> How about the realm? According to log, when windows sends computer account
> as login, Packetfence put it on Realm = "binus.local". But we never stup
> that realm.
> Is it normal to?
>
>
>
> Regards,
> Irvan.
>
> On Thu, Nov 3, 2022 at 12:16 AM Zammit, Ludovic 
> wrote:
>
>> Hello Irvan,
>>
>> It looks pretty normal that the windows sends the computer account
>> because it’s the default behavior.
>>
>> What is not normal, is that if you have at least one successful
>> authentication on the wifi with a username password, it should keep that
>> one and not re-ask again.
>>
>> All that can be configured on the SSID profile on windows.
>>
>> Thanks,
>>
>>
>> *Ludovic Zammit*
>> *Product Support Engineer Principal Lead*
>> *Cell:* +1.613.670.8432
>> Akamai Technologies - Inverse
>> 145 Broadway
>> Cambridge, MA 02142
>> Connect with Us:  
>>  
>> 
>> 
>>
>> On Nov 2, 2022, at 1:45 AM, Irvan via PacketFence-users <
>> packetfence-users@lists.sourceforge.net> wrote:
>>
>> Hello Everyone,
>>
>>
>> We have strange behaviour with Windows Client connecting to dot1x WiFi on
>> Packetfence using AD Authentication source.
>>
>> The symptoms are :
>>
>> - When the first time Windows client connect to SSID, it was asked for
>> username and password for login.
>> - But if client forget the SSID and try to reconnect, Windows never asked
>> username and password, it was automatically send hostname as login to
>> packetfence, and accepted by packetfence.
>> - The same thing happened when user comeback in the next day, Windows
>> send hostname as login instead of username and it also accepted by
>> packetfence
>>
>> We don't setup any machine auth, only user auth. Drill down to radius
>> log, we saw that hostname login hit a non-existe realm. Using username and
>> password client hit null realm. But when windows send hostname it hit
>> binus.local realm, which is never exist.
>>
>> Bellow are radius log and realm.conf
>>
>> 1. Using user auth
>> ===
>> Request Time
>> 0
>>
>> RADIUS Request
>> User-Name = "loudy.owen"
>> NAS-IP-Address = 10.21.36.41
>> NAS-Port = 4
>> Service-Type = Framed-User
>> State = 0x6067228e61c0382594e9daec37da5a60
>> Called-Station-Id = "90:3a:72:03:18:90:BinusWifi-Staff.1x"
>> Calling-Station-Id = "70:66:55:34:28:f3"
>> NAS-Identifier = "90-3A-72-03-18-90"
>> NAS-Port-Type = Wireless-802.11
>> Acct-Session-Id = "6361F1F4-03189001"
>> Acct-Multi-Session-Id = "88DA8FBC70CEC821"
>> Event-Timestamp = "Nov  2 2022 11:28:41 WIB"
>> Connect-Info = "CONNECT 802.11"
>> EAP-Message = 0x02a700061a03
>> Chargeable-User-Identity = 0x00
>> Location-Data = 0x31304944170d42696e7573205379616864616e
>> WLAN-Pairwise-Cipher = 1027076
>> WLAN-Group-Cipher = 1027076
>> WLAN-AKM-Suite = 1027073
>> FreeRADIUS-Proxied-To = 127.0.0.1
>> Ruckus-SSID = "BinusWifi-Staff.1x"
>> Ruckus-Wlan-Id = 508
>> Ruckus-Location = "Binus Syahdan"
>> Ruckus-SCG-CBlade-IP = 180933220
>> Ruckus-VLAN-ID = 1220
>> Ruckus-BSSID = 0x903a7243189d
>> Ruckus-Zone-Name = "AP-Zone-Syahdan"
>> Ruckus-Wlan-Name = "VlanPool2"
>> EAP-Type = MSCHAPv2
>> Stripped-User-Name = "loudy.owen"
>> Realm = "null"
>> Called-Station-SSID = "BinusWifi-Staff.1x"
>> PacketFence-Domain = "binus"
>> PacketFence-KeyBalanced = "10a6d36fd6ec338584a72fcbe75f86ba"
>> PacketFence-Radius-Ip = "10.200.210.87"
>> PacketFence-NTLMv2-Only = ""
>> PacketFence-Outer-User = "loudy.owen"
>> Attr-26.25053.155 = 0x5379616864616e2043616d707573
>> User-Password = "**"
>> SQL-User-Name = "loudy.owen"
>>
>> RADIUS Reply
>> EAP-Message = 0x03a70004
>> Message-Authenticator = 0x
>> User-Name = "loudy.owen"
>> REST-HTTP-Status-Code = 200
>>
>> ==
>>
>> 2. Using hostname
>> ===
>> Request Time
>> 0
>>
>> RADIUS Request
>> User-Name = "host/NB202007000166.binus.local"
>> NAS-IP-Address = 10.21.36.41
>> NAS-Port = 4
>> Service-Type = Framed-User
>> State = 0xb4483109b5402b5768b5cf1f24ad1e9e
>> Called-Station-Id = "90:3a:72:03:18:90:BinusWifi-Staff.1x"
>> Calling-Station-Id = "70:66:55:34:28:f3"
>> NAS-Identifier = "90-3A-72-03-18-90"
>> NAS-Port-Type = Wireless-802.11
>> Acct-Session-Id = "6361F350-03189001"
>> Acct-Multi-Session-Id = "3DD47C3ED408529E"
>> Event-Timestamp = "Nov  2 2022 11:34:26 WIB"
>> Connect-Info = "CONNECT 802.11"
>> EAP-Message =

Re: [PacketFence-users] Windows client automatically login using hostname and hit non-exist realm

2022-11-04 Thread Irvan via PacketFence-users 
Hello Ludovic,

Thank you for your explanation.
How about the realm? According to log, when windows sends computer account
as login, Packetfence put it on Realm = "binus.local". But we never stup
that realm.
Is it normal to?



Regards,
Irvan.

On Thu, Nov 3, 2022 at 12:16 AM Zammit, Ludovic  wrote:

> Hello Irvan,
>
> It looks pretty normal that the windows sends the computer account because
> it’s the default behavior.
>
> What is not normal, is that if you have at least one successful
> authentication on the wifi with a username password, it should keep that
> one and not re-ask again.
>
> All that can be configured on the SSID profile on windows.
>
> Thanks,
>
>
> *Ludovic Zammit*
> *Product Support Engineer Principal Lead*
> *Cell:* +1.613.670.8432
> Akamai Technologies - Inverse
> 145 Broadway
> Cambridge, MA 02142
> Connect with Us:  
>  
> 
> 
>
> On Nov 2, 2022, at 1:45 AM, Irvan via PacketFence-users <
> packetfence-users@lists.sourceforge.net> wrote:
>
> Hello Everyone,
>
>
> We have strange behaviour with Windows Client connecting to dot1x WiFi on
> Packetfence using AD Authentication source.
>
> The symptoms are :
>
> - When the first time Windows client connect to SSID, it was asked for
> username and password for login.
> - But if client forget the SSID and try to reconnect, Windows never asked
> username and password, it was automatically send hostname as login to
> packetfence, and accepted by packetfence.
> - The same thing happened when user comeback in the next day, Windows send
> hostname as login instead of username and it also accepted by packetfence
>
> We don't setup any machine auth, only user auth. Drill down to radius log,
> we saw that hostname login hit a non-existe realm. Using username and
> password client hit null realm. But when windows send hostname it hit
> binus.local realm, which is never exist.
>
> Bellow are radius log and realm.conf
>
> 1. Using user auth
> ===
> Request Time
> 0
>
> RADIUS Request
> User-Name = "loudy.owen"
> NAS-IP-Address = 10.21.36.41
> NAS-Port = 4
> Service-Type = Framed-User
> State = 0x6067228e61c0382594e9daec37da5a60
> Called-Station-Id = "90:3a:72:03:18:90:BinusWifi-Staff.1x"
> Calling-Station-Id = "70:66:55:34:28:f3"
> NAS-Identifier = "90-3A-72-03-18-90"
> NAS-Port-Type = Wireless-802.11
> Acct-Session-Id = "6361F1F4-03189001"
> Acct-Multi-Session-Id = "88DA8FBC70CEC821"
> Event-Timestamp = "Nov  2 2022 11:28:41 WIB"
> Connect-Info = "CONNECT 802.11"
> EAP-Message = 0x02a700061a03
> Chargeable-User-Identity = 0x00
> Location-Data = 0x31304944170d42696e7573205379616864616e
> WLAN-Pairwise-Cipher = 1027076
> WLAN-Group-Cipher = 1027076
> WLAN-AKM-Suite = 1027073
> FreeRADIUS-Proxied-To = 127.0.0.1
> Ruckus-SSID = "BinusWifi-Staff.1x"
> Ruckus-Wlan-Id = 508
> Ruckus-Location = "Binus Syahdan"
> Ruckus-SCG-CBlade-IP = 180933220
> Ruckus-VLAN-ID = 1220
> Ruckus-BSSID = 0x903a7243189d
> Ruckus-Zone-Name = "AP-Zone-Syahdan"
> Ruckus-Wlan-Name = "VlanPool2"
> EAP-Type = MSCHAPv2
> Stripped-User-Name = "loudy.owen"
> Realm = "null"
> Called-Station-SSID = "BinusWifi-Staff.1x"
> PacketFence-Domain = "binus"
> PacketFence-KeyBalanced = "10a6d36fd6ec338584a72fcbe75f86ba"
> PacketFence-Radius-Ip = "10.200.210.87"
> PacketFence-NTLMv2-Only = ""
> PacketFence-Outer-User = "loudy.owen"
> Attr-26.25053.155 = 0x5379616864616e2043616d707573
> User-Password = "**"
> SQL-User-Name = "loudy.owen"
>
> RADIUS Reply
> EAP-Message = 0x03a70004
> Message-Authenticator = 0x
> User-Name = "loudy.owen"
> REST-HTTP-Status-Code = 200
>
> ==
>
> 2. Using hostname
> ===
> Request Time
> 0
>
> RADIUS Request
> User-Name = "host/NB202007000166.binus.local"
> NAS-IP-Address = 10.21.36.41
> NAS-Port = 4
> Service-Type = Framed-User
> State = 0xb4483109b5402b5768b5cf1f24ad1e9e
> Called-Station-Id = "90:3a:72:03:18:90:BinusWifi-Staff.1x"
> Calling-Station-Id = "70:66:55:34:28:f3"
> NAS-Identifier = "90-3A-72-03-18-90"
> NAS-Port-Type = Wireless-802.11
> Acct-Session-Id = "6361F350-03189001"
> Acct-Multi-Session-Id = "3DD47C3ED408529E"
> Event-Timestamp = "Nov  2 2022 11:34:26 WIB"
> Connect-Info = "CONNECT 802.11"
> EAP-Message = 0x020800061a03
> Chargeable-User-Identity = 0x00
> Location-Data = 0x31304944170d42696e7573205379616864616e
> WLAN-Pairwise-Cipher = 1027076
> WLAN-Group-Cipher = 1027076
> WLAN-AKM-Suite = 1027073
> FreeRADIUS-Proxied-To = 127.0.0.1
> Ruckus-SSID = "BinusWifi-Staff.1x"
> Ruckus-Wlan-Id = 508
> Ruckus-Location = "Binus Syahdan"
> Ruckus-SCG-CBlade-IP = 180933220
> Ruckus-VLAN-ID = 1220
> Ruckus-BSSID = 0x903a7243189d
> Ruckus-Zone-Name = "AP-Zone-Syahdan"
> Ruckus-Wlan-Name = "VlanPool2"
> EAP-Type =

[PacketFence-users] 11.2-12.0 upgrade problem

2022-11-04 Thread Ravenhill, Anthony P. via PacketFence-users 
I have a working 11.2 install on Rocky Linux 8.6.

I have made several attempts to upgrade to 12.0 using the recommended automated 
method.

/usr/local/pf/addons/upgrade/do-upgrade.sh runs through without obvious errors, 
however when I restart pf, either directly after the upgrade or by a reboot, 
the following services appear to start up and after a very short period of 
operation (at least as far as the GUI service manager is concerned), fail:

fingerbank-collector
pfipset
radiusd-auth

The reason given for failure is as follows:-

Can't connect to pfconfig on containers-gateway.internal:4 : Invalid 
argument
[1667477664.96915] Failed to connect to config service for namespace 
resource::URI_Filters(), retrying

The main syslog also appears to be full of similar messages generated by other 
pf services as well as the above.

The packetfence-config service appears to be running.

I know very little about docker, am I missing something obvious?

Kind regards

Tony
___
PacketFence-users mailing list
PacketFence-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/packetfence-users