Active directory SSO & Radius Users

Currently using FireboxV, version 12.7.

I've setup SSO using active directory for our internal workstations/users and am successfully using A/D groups, within firewall policies, to control traffic through the firewall . (I've deployed the watchguard client to each workstation and the SSO agent/server is using this as it's primary method of identifying the user with ELM as a backup)

I've then configured IKEv2 VPN, for our users to use on their a/d laptops when working remotely, which uses an internal radius server (NPS) for authentiation against active directory. My VPN users, once connected, then don't seem to be able to use the active directory restricted policies. (Using the scripts etc from Firewall to generate the native windows 10 vpn connection)

Looking at the firewall logs I can see that the username for my vpn users has @ at the end (domain being that configured in the radius settings on the firebox). I realise that this is different from non vpn users (they have thir A/D UPN) which might be why my a/d based policies aren't applying as the firewall treating the vpn user as a different user. Is there anyway of, once the user is authenticated via radius, of then using the A/D SSO authentication as well so that the A/D based policies apply?

I have to use the radius authentication as we have the M/S plugin, on our NPS server, that allows us to use office Azure MFA where we sync our A/D into azure.

Thoughts gratefully received.

Answers

  • I've not used the SSO agent, but check in your NPS configuration what Filter-Id value (RADIUS attribute 11) is being returned to the Firebox.
    Also look at the NPS logs for a user that doesn't have the correct policies to ascertain which NPS policy it applied (and thus which Filter-Id was returned).

    The setups I have this on do show the username on the Firebox as something like "username@domain@domain" which appears to be because the first "username@domain" then gets the second "@domain" from the authentication server name in the Authentication Servers configuration - this is not an issue as far as I've seen, but the NPS server (and its logs) are key to this.

  • Hi Phil. Thanks for replying.

    I was hoping to avoid using attribute 11 to much to return group information (other than allowing users to connect to the VPN) as I'll need to create an NPS policy for each possible combination of groups that I use to control specific access to resources, eg I have a group to control access to youtube, a group for webex and a group for certain social media, which would result in 27 possible combinations (NPS policies and additional groups to apply to specific users to get their correct NPS policy to apply).

    In effect it more than doubles and duplicates the work load having setting up groups within A/D to then have to create a parallel structure within Radius/Atrtribute 11.

  • james.carsonjames.carson Moderator, WatchGuard Representative

    NPS generally passes just the one group. You can try adding IKEv2_Users to those policies.

    If you pull a support file and look inside,
    Fireware_XTM_Support.tgz\Fireware_XTM_Support.tar\support_serial.tgz\support_serial.tar\support\system\auth_session_list.txt
    you'll see the groups every user is landing in listed at the end of every user.

    -James Carson
    WatchGuard Customer Support

Sign In to comment.