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

UTM Email is basically the technology of 2013. The features used there and the technology used there is not adjusted to modern requirements. SFOS Email does the same like UTM and it is stuck in the same situation.

You can go one step back and talk about: What to do with attachments? If you talk to UTM Customers, they start to "Quarantine" those Emails and the Admin is doing there "one per day" cleanup process. Is this actually "the way to go"? How does the Admin actually decide to release the Email? I saw UTM customer "downloading" the Email to there windows machine and looking at the attachment with Notepad++. 

In CEMA: You strip the attachment, the Email will go to the Recipient but the attachment is "bill.docs.txt" with "Your email was stripped, go to IT". IT can then check the Attachment, as the attachment is in the Quarantine. They can do a Intelix Report of this Email as well. Then they release the Email to the user and the user get the original Email with the original Attachment. See:  Quarantine and policy enhancements 

Another approach: Using different Policies for different situations: Accept DOCX from one Domain, but not from ANYBODY. Then add other approaches like "Quarantine this Email and Strip from the others". This is technology coming from SEA (Sophos Email Appliance). 

CEMA, as it is a Central Cloud Based Solution, uses AI as well. https://ai.sophos.com/demos/ You can watch how it works here. Every Link within every Email is being checked and replaced by the AI Engine and can be blocked by users to access it. It is called Time of Click. You talk about "Web Filtering". But what about a mobile phone? I can click on the Link with my phone, which could be not behind a firewall? How do you do inspection of a iOS Phone anyway? 

Then based on AI, CEMA uses the AI to score an Email to find an Impersonation - Which means, does the attacker try to figure out a "look a like domain" and send you an Email? For Example: S0phos.com 

SPF helps your for MAIL-FROM Spoofing. What about FROM Spoofing? I can use a perfectly fine domain, call it attacker.com, send a Email called badguy@attacker.com as MAIL-FROM, your UTM will check the SPF but then i rewrite the FROM to "printer@sophos.com". Sounds familiar? This was/is a normal attack chain. And SPF cannot deal with this. See: https://www.usenix.org/system/files/sec21-shen-kaiwen.pdf You need some sort of AI to prevent this from happening. CEMA has it. 

Looking at XDR: You can fetch every data from CEMA into XDR. Which means, if you find an Suspicious Attachment within your company: Check the "origin" of this Email by query the Datalake and check: Came it via Email - who sent it? When? What did Intelix say about this Attachment, who else got this Attachment etc. See: https://techvids.sophos.com/watch/ZXbHeYH2bxj9JcuhQRs6TN

Talking about "old stuff": Greylisting is dead. Modern solutions do this with own technologies: Sophos Labs, as they hold the MX Records, can actually in real time see Campaigns. So they are able to see some attacks pilling up and with a modern approach of technologies, you can start to delay such emails first on the Gateway and check what is going on, until you release this to the customer Email Server. This is automated and observed by Analysts within SophosLabs. No way to do this on a decentralized solution like a firewall, as getting back the telemetry and trying to figure out what is going on takes to long. 

Looking into the future: If you want to go the direction to M365 or others, CEMA is able to support that with Mailflow and not doing a MX Record rewriting. 

I can do more, if you want. But that is just a rough overview of CEMAs Toolkit compared to UTM/SFOS. 

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. 

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