XGS 19.6: AD user prefetch icl. Mail attribute

I do always recommend to move to CEMA instead. There is/was a promo to move to CEMA instead of using the Email Protection on SFOS. 

So comparing UTM to CEMA, CEMA is far ahead of protection, detection and usability.

Thank you for your reply - but the question was not "How can I spent again more money" and "How can I implement more cloud solutions" (in an explicit NON-cloud driven company) - but:

"How can I get (back) a basic functionality for an on prem environment?"

And with a short view on CEMA I cannot see any better functionality than we had with Sophos SG and its CLI. Is the XGS so much worse than the SG that CEMA comes in the game?

Or did I miss a killer-feature of CEMA?

Edit: 

"Email Time-of-Click URL Rewriting" is supposed to be based on grey/black-lists which should apply to the SFOS webfilter, too. So if any user clicks on a suspicious link the webfilter should block that, too.
DKIM, SPF, user callout a.s.o. is implemented, too.

Mailbox-URL-Rewriting applies only to M365 mailboxes which don´t have.

So seriously: what is the killer feature of CEMA I am overlooking?

Cheers - Chris

LuCar Toni Sorry for the delay - we are on holiday since yesterday.

Thank you for the explanations - meanwhile I noticed that VPN Authentication itself is triggering the creation of a local user - so this is fine to me.

But: How can I be sure to authenticate only users from a dedicated VPN-user-group in AD for VPN? Right now every user with an valid account in AD gets VPN. Under the AD Authentication Services I imported the special user group - but it is created on the XGS without any user. So I decided to put every remote authenticated user into that group and assign that group VPN rights - but unfortunately now everyone in my AD gets VPN.

How can I request only a special group? Adding this to the search query does not help...

SFOS will check for the Backend Membership and if the user matches the groups you selected for SSLVPN, they can authenticate. 

It is not SSL it is IPSEC and / or L2TP.

And I checked it again and again:

user in AD Group "VPN-User" or not - everyone in the AD gets the right to use VPN when authenticated via AD-connection-service AND I tick the opportunity to add new user automatically to this "imported" AD Group on the XGS.

Members of that group do have the right for IPSEC / L2TP.

I simply cannot find the place like on the SG where I can say: ONLY AD members of that special AD group are allowed to connect.

So I do not understand why I can "import" an AD group when this group is not imported but only created as an empty local group. There is no difference visible to me between a locally created empty group and "importing an AD group" - which is created at the XGS empty as well.

So you can do the trick by: Create a firewall rule, which uses Groups. IPsec is not using the backend membership feature: https://doc.sophos.com/nsg/sophos-firewall/19.5/help/en-us/webhelp/onlinehelp/AdministratorHelp/Authentication/Servers/AD/AuthenticationADMultipleGroupMembershipSupport/index.html 

So you can simply create a firewall rule, which does your trick (VPN to LAN), allow your users and then nobody expect those clients, you want to have in your network can connect "through" the firewall. In the end, it is the same outcome: No connection if not in the group. 

This would allow you to "not care" if you use SSLVPN, IPsec or L2TP, as the firewall will do the same rule set for all 3 modules. 

SFOS uses the authentication process to update the group membership and reflect all groups of this particular user. Therefore a moving of a group is reflected within the next login and not "whenever the next prefetch is". This approach is in a real scenario most likely the better approach towards speed. 

Thank you for the clarification that the XGS does not care about AD group members for main VPN protocols. This is a bit disappointing.

So when I have to build a crutch via firewall - deny access from WAN for non AD-VPN-user-group - will it affect other legal users, too? For instance

- OWA access to on prem exchange from outside?

-. SSH to some DMZ-systems with no need to VPN

- Webservers we are hosting (Jiira, confluence... authenticated against AD, too)

And to your last poimt: "SFOS uses the authentication process to update the group membership and reflect all groups of this particular user. Therefore a moving of a group is reflected within the next login and not "whenever the next prefetch is". This approach is in a real scenario most likely the better approach towards speed." 

Of course it is better than prefetching users - thats why I preferred RADIS on the SG -  but how does the XGS reflect it?

I "imported" an AD group, lets call it "finance" - the XGS created that group as an empty group. Whenever a user is logging into the user portal it makes no difference if that user is a member of AD group "finance" - it was never added to that "imported" group on the XGS. Of course: when I select "add new authenticated users to group" and select "finance" - then EVERY new user becomes a member of that XGS-group - regardless of being a member in my AD or not.

So when an admin would be able to see real AD-groupmemberships on XGS?

Let me circle back on this: 

So essentially you can let everybody connect to the firewall via VPN. But the important part is the "Who is allowed to connect to what facility" part. This can be done by User / Group based level on Firewall. So in the end, it does not matter, what group your user is in, he/she can build VPN (SSL/IPsec/L2TP) and you purely control everything via firewall rules. This make it easier to build up a security principle, which is the same, regardless of the way you connect to your firewall.

(Even better if you look into the way of doing it via ZTNA). 

This is only controlling VPN to X (LAN, DMZ etc.). 

SFOS will check the live user and have all group information at that time and use it for all groups. So if you connected for example via SSLVPN, SFOS knows the groups you are in and if you allow SSH for your Domain Admins, only your admin account can build up SSH through the firewall. It will move the "Destination allow list" to the "Service allow list". 

Important is: SFOS uses a Primary Group approach. So every user has to be in one primary group. This is "first match" of the group window. Therefore you can reorder the group window, and SFOS will go from top to bot to find the first matching group and throw the user into this group. 

Under Users and "Backend Membership" you see all the groups of all users in the current stage. So primary group will be the "Show Member" Group, but SFOS knows all other groups as well. 

Unfortunately I am to dumb to check all this as an advantage. Sorry, maybe it is much to late here in germany.

I just tested the following:

IPSEC-VPN - allowed group: "open group"

"Firewall authentication methods" - first: AD-server, Default group = Open group

No special firewall rule added to restrict users by groups or so.

created a "TEst-user" with membership of AD group "finance"

"Test-user" cannot connect to VPN: Authentication failed.

User is not created at XGS.

"Test-user" can login into user portal.

"Test-User" is created locally.

Group member: "open group" - but "Other group memberships" is empty. I thought that here should be "finance" right now?

After user was created via user-portal-login that "test-user" can connect via IPSEC.

Why he could not use VPN before although he should be able to authenticate? Why it is working when I set other group, eg. "VPN-user" as "default group" and allow this group under IPSEC VPN?

My confusion is complete right now.... :-( 

So - as far as i recall - SFOS does not create users based on an Authentication process of IPsec VPN due the integration of groups there. This means, back in the day (prior to the group support) you had to create the user first. This never changed, we still need the user first, we simply replaced the need of selecting all users with the group. But still it needs to exists in the first place. 

But: The backend membership groups should be updated, which is odd to me. Can you post some screenshots of the logviewer - authentication and your AD, which shows this user be in the group you imported? 

It is important: The name has to match the name in SFOS. Did you import it from the AD? 

Hi Toni,

I am back from holiday an fixed the updated additional groupmembership - so that is working.

Still anyone (!) who is in our AD is able to login into user portal authenticated against RADIUS and can do L2TP.

So the question is:

How can I do a firewall rule to DENY access for users which are NOT member of the VPN group "VPN-users"?

I tried to add No1 rule: If member of VPN-group THEN ALLOW VPN=>LAN/DMZ

and added No2 rule: DENY VPN=>DMZ/LAN

in the hope that if No1 does not match automatically No2 comes in places - but this did not the trick. Anyone with VPN cann get to systems in DMZ/LAN regardless of being member of "VPN-users".

So what should I set up?

Thank you & Cheers - Chris

Finally I found a solution for my initial question and the question about authenticating L2TP to AD user group:

1.) On the RADIUS Server:

make sure there is a network rule which includes both:
- AD group membership "VPN users" AND

- client IPv4 address from the XGS

Make sure there is no other rule like "all authenticated windows users" later enabled.

Make sure there is no other rule with no combined group AND client-IP address (e.g. for WLAN auth...)

2.) On XGS:

- configure AD Authentication server with

"Display name attribute" = "displayname" and

"Email address attribute" = "mail"

- The FIRST AD group you have to import must be ""VPN Users"

- Under "Authentication" - "Services" change the default group to "VPN users"

- configure the RADIUS Authentication server

- put the RADIUS Authentication Server at the first line for Firewall and IPSEC/L2TP

Now I can confirm that:

1.) Non existent users (on the XGS) with NO AD membership of "VPN users" cannot authenticate within a L2TP connection attempt

2.) Non existent users (on the XGS) WITH AD membership of "VPN users" can authenticate within a L2TP connection attempt

3.) As soon as they connected with L2TP for the first time the users is created on the XGS, the AD group membership is visible under "Other group memberships" AND, tadaaa: with the correct E-mail address 

Finally I found a solution for my initial question and the question about authenticating L2TP to AD user group:

1.) On the RADIUS Server:

make sure there is a network rule which includes both:
- AD group membership "VPN users" AND

- client IPv4 address from the XGS

Make sure there is no other rule like "all authenticated windows users" later enabled.

Make sure there is no other rule with no combined group AND client-IP address (e.g. for WLAN auth...)

2.) On XGS:

- configure AD Authentication server with

"Display name attribute" = "displayname" and

"Email address attribute" = "mail"

- The FIRST AD group you have to import must be ""VPN Users"

- Under "Authentication" - "Services" change the default group to "VPN users"

- configure the RADIUS Authentication server

- put the RADIUS Authentication Server at the first line for Firewall and IPSEC/L2TP

Now I can confirm that:

1.) Non existent users (on the XGS) with NO AD membership of "VPN users" cannot authenticate within a L2TP connection attempt

2.) Non existent users (on the XGS) WITH AD membership of "VPN users" can authenticate within a L2TP connection attempt

3.) As soon as they connected with L2TP for the first time the users is created on the XGS, the AD group membership is visible under "Other group memberships" AND, tadaaa: with the correct E-mail address