search

inverse-inc / packetfence

PacketFence is a fully supported, trusted, Free and Open Source network access control (NAC) solution. Boasting an impressive feature set including a captive-portal for registration and remediation, centralized wired and wireless management, powerful BYOD management options, 802.1X support, layer-2 isolation of problematic devices; PacketFence can be used to effectively secure networks small to very large heterogeneous networks.
https://packetfence.org
GNU General Public License v2.0
1.29k stars 274 forks source link

Unable use User_Role in VPN-Access request from FortiGate #6355

Open cdcrawford opened 3 years ago

cdcrawford commented 3 years ago

Describe the bug When we have a user account log into the FortiClient, connected to a FortiGate. The Radius Authentication request is sent to PacketFence, which processes it without a problem.

But, we're not able to assign a role to that request. So, it is not able to send back the appropriate group membership to the FortiGate to complete the login request.

To Reproduce Steps to reproduce the behavior:

  1. Configure a FortiGate to send Radius to PacketFence
  2. Create a Fortinet::FortiGate switch
  3. Use either VLAN or RoleMap (we had both act the same way)
  4. Create a Authentication Source that has a filter in it, which assigns the user a particular role.
  5. Create a RadiusFilter to send back the Fortinet-Group-Name
  6. Log into the FortiClient
  7. See the Authentication in the Audit
  8. No additional information in the reply.

Radius Logs RADIUS Request User-Name = "chris" NAS-IP-Address = 10.10.20.10 Called-Station-Id = "10.10.20.10" Calling-Station-Id = "10.10.10.10" NAS-Identifier = "FortiGate" Proxy-State = 0x313631 NAS-Port-Type = Virtual Acct-Session-Id = "46906026" Event-Timestamp = "May 11 2021 10:23:26 ADT" Connect-Info = "vpn-ssl" Message-Authenticator = 0xcc6237fa515961d575f802b4a0908044 Fortinet-Vdom-Name = "root" MS-CHAP-Challenge = 0x92ae68a2ac66124ad164042f4f38c45b MS-CHAP2-Response = 0x7e00806b361b428955e2c7df110c101a8be4000000000000000050fe07df152cd08c0445ee178820959c7bb361acf054930c Stripped-User-Name = "chris" Realm = "null" FreeRADIUS-Client-IP-Address = packetfenceVIP PacketFence-Domain = "DOMAIN" PacketFence-KeyBalanced = "2276c8900707b1d83ae8bfcaa3008c39" PacketFence-Radius-Ip = "packetfence1" PacketFence-NTLMv2-Only = "--allow-mschapv2" User-Password = "**" SQL-User-Name = "chris"

RADIUS Reply MS-CHAP2-Success = 0x7e533d45464232384144444444433243304643323339413633424430303635354336354243423341423039 Proxy-State = 0x313631

Radius Filter [SSLVPN-NetAdmin] status=enabled top_op=and description=test sslvpn scopes=returnRadiusAccessAccept merge_answer=yes condition=switch._ip == "172.18.1.90" && user_role == "SSLVPN-NetAdmin" answer.0=reply:Fortinet-Group-Name = VPN-ITS-NetServ

Authentication Source image

Expected behavior I'd expect the user role to be able to called in the Radius Filter and send the correct reply based on the filter.

Ideally, this would be handled through the RoleMap on the switch and would be done automatically with the need for a Radius Filter

Additional context This is related to a ticket logged into the mailing list with the subject of FortiGate VPN Auth based on AD Group Membership. Fabrice seems to have a handle on the fix.

I also have a non-production FortiGate, and non-production PacketFence Cluster at the ready if testing is needed. I can also spin up a ZEN instance if it makes it easier for you to test. I realize that you may not have every

cdcrawford commented 2 years ago

Seems to be fixed by PR: #6684