Category: Azure

Azure network design considerations

Posted on by Ivo

Azure networking looks simple at first glance. You create a virtual network in the Azure portal. In the next part, you define a subnet with an IP range. With only a few mouse clicks, there is a network in which you can place resources.  At a certain point in time, organizations are going to install “something” in Azure. In most cases, this involves a test environment for one thing or another. The IT organization arranges access to the Azure Portal so the Azure team can start building.

Virtueel netwerk aanmaken

There is nothing more permanent than a temporary solution. This rule seems to be especially valid for “test” environments in the cloud.

In most cases, the Azure environment needs a connection to the existing infrastructure after some time. This connection is relatively easy to build with the Azure VPN Gateway. You have to make sure you’ve thought it through from the beginning, or else you will run into difficulties. To protect you from difficult situations, here is a list of considerations when designing an Azure network:  

  • Have I thought of an IP Plan?
    • Subnets per resource group
  • Which locations should I connect to Azure?
    • Data Centers
    • Offices
    • 3rd party
  • What technology do I use to connect the sites to Azure?
    • IPSEC site-to-site
    • Express route
    • IPSEC to NVA
    • Cato Networks
  • How do I apply network security within my Azure network?
    • Network security groups
    • Application security groups
    • Network virtual appliances (NVA)
  • What Azure network topology am I going to use?
    • Hub and spoke
    • Vnet peering
  • Is routing needed?
    • User-defined-routes

These topics will help you start designing your Azure network. There is plenty of information on each subject on the Internet. If you get lost in the sea of information, don’t hesitate to contact me. You can always reach me at ask-me@ivo-security.blog. The “keep it simple stupid” philosophy works very well for Azure network design. Nowadays, we should also apply the idea of “safe” to this philosophy.

Hub and spoke ontwerp

In my next blog, I’ll share details of our connection from the on-premises datacenters to Azure. These datacenters connections are not via a Microsoft ExpressRoute. If you suspect we are using IPSEC tunnels, you will be in for a surprise next time. We use one of the most fascinating and secure connections to Azure from our different datacenters.

Follow @lol.it.rofl on instagram for your daily dose of IT humor.

The ultimate list of Microsoft Security portals.

Posted on by Ivo

In addition to being a software vendor, Microsoft is the unknown leader in cybersecurity. The M365 bundles from Microsoft include a complete package of tooling to safeguard “Identities” and “Computers”.

Many traditional security products are not required anymore.
The M365 bundles have the modern version of the security product integrated within. Organizations can achieve significant savings by taking advantage of the functionality within their M365 licenses. 

overview M365 security

Setting up and using Azure Sentinel requires some training. The other products are relatively straightforward. The collaboration among Microsoft security products is outstanding.

The different portals:

Microsoft Defender (for end Endpoint)Security centerhttps://securitycenter.windows.com/
Microsoft Defender for office365https://protection.office.com/threatpolicy
Microsoft 365 admin centerhttps://admin.microsoft.com
Microsoft 365 admin centerhttps://security.microsoft.com/homepage
Endpointmanager(Intune)https://endpoint.microsoft.com/#home
Microsoft 365 compliance centerhttps://compliance.microsoft.com/homepage
Office365 Security & comopliance centerhttps://protection.office.com/homepage
Cloud App Discoveryhttps://portal.cloudappsecurity.com
Cloud App Securityhttps://portal.cloudappsecurity.com
Azurehttps://portal.azure.com
Azur Sentinel https://portal.azure.com
Azure Security Centerhttps://portal.azure.com/#blade/Microsoft_Azure_Security/SecurityMenuBlade/0
Azure Active Directoryhttps://aad.portal.azure.com
Azure Active Directoryhttps://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/Overview
Microsoft Defender for Identityhttps://portal.atp.azure.com/
Azure AD Identity Protectionhttps://portal.azure.com/#blade/Microsoft_AAD_IAM/IdentityProtectionMenuBlade/Overview
Azure  AD Identity Protection (Free version)https://portal.azure.com/#blade/Microsoft_AAD_IAM/SecurityMenuBlade/RiskyUsers
Azure information protection (unified labeling)https://portal.azure.com/#blade/Microsoft_Azure_InformationProtection/DataClassGroupEditBlade/globalBlade

Follow @lol.it.rofl on instagram for your daily dose of IT humor.

Fortigate policies based on Azure Dynamic Groups

Posted on by Ivo

Almost every organization uses groups to assign permissions to employees. For example, these groups grant read or write admissions to a folder. The simple structure of groups keeps it clear for administrators whether they assign permissions to folders or printers or any other resource type.

Within the cloud era, groups are still relevant to assign permissions or resources. However, this requires a different approach.

The administration around group memberships still leaves much to be desired. Employees with many working years often collected a large backpack of group memberships. The dynamics of working have also changed over the years. The workspace tends to be more flexible and more project/team-oriented. To place these requirements in existing group structures is very difficult. In many organizations, there has been a sprawl of groups within their Active Directory.

As a result, many Active Directory contain a jungle of groups. I don’t need to explain why this is bad for IT security.

Azure AD Dynamic Groups

Within Azure AD, you can create groups that are populated based on a user account’s properties. These groups are called Dynamic Groups. For example, a group can be made based on the job title. It is, therefore, relatively easy to create a group with all managers of an organization. This group is also automatically updated. When a member no longer meets the requirements, Azure AD will remove the member.

Azure AD can use almost all user account properties to create membership rules.

The beauty of these Azure AD Dynamic Groups is that Fortigates can use them. (Read here how to set up your Fortigate SAML authentication with Azure AD) Access to resources is granted based on these dynamic groups. The employee can only access resources via the SSL-VPN if their account meets the Dynamic Group’s requirements.

In the examples below, I created two different groups. One is for the security team. The other is for the CSN Microsoft licensing specialists.

Describe the purpose of the dynamic group as concretely as possible and add it to the description

In the examples below, I created two different groups. One is for the security team. The other is for the CSN Microsoft licensing specialists.

Within Azure AD, create a new group. Specify that the membership type is: "Dynamic User". Next, add a "Dynamic query".
In the "Rule builder" you can specify what properties are needed to meet the  group requirrements. In the example below, his job title should have something to do with "security".
Use the "validation rules" to check if the desired members meet the criteria By choosing a number of test persons you can quickly see if the rule works.
This group was created for the Microsoft licensing specialists of CSN Group.

When creating a Dynamic Group a welcome mail is sent to the members. You can disable this behavior in exchange online:

Set-UnifiedGroup -Identity "voorbeeldgroep@domein.nl" UnifiedGroupWelcomeMessageEnable:$false
The groups have been created. The object ID of the group is needed in the Fortigate configuration later on.

The object id of the group is used in the Fortigate configuration

By opening the group you can check if the desired members are present.
We also use the Dynamic Groups to assign the enterprise app "Fortigate SSL-VPN"
Gives a clear name to the attribute here. This will be needed later in the Fortigate configuration.
In the SAML user configuration of the Fortigate, place the name of the group attribute you just created.
In the group configuration of the Fortigate you create the new groups. In these groups, you specify the condition they must meet. In this case, the "group-name" must match the "Object-id" of the group in Azure AD.
The newly created groups can now be used to allocate resources. In other words. They can be used in the Fortigate security policies.

Fortigate and Azure AD: Safe remote access

Posted on by Ivo

Within CSN Group, like the rest of the world, we work mostly from home this year. Our employees, therefore, need access to the resources within our data center from home. And that in a way that does not compromise data security. Consequently, we combine two of the best security products available: Fortigate firewalls and Azure Active Directory (Azure AD). Are you wondering how these products work together? I will explain it below.

Possibly it is redundant, but the security products separately do the following:

Fortigate
A Fortigate is a so-called next-gen firewall. This firewall offers broad protection against countless cyber threats. If properly configured, this firewall will fend off attacks such as ransomware. Also, it provides solutions for connectivity issues. For example, we connect sites to data centers based on SD-WAN technologies. The Fortigates offer the ability to give home workers secure access to network resources. It is a versatile device that will speak to the imagination of most people.

Azure Active Directory (Azure AD)
Azure AD is Microsoft’s Identity Manager. It is sometimes confused with the traditional Windows Active Directory. However, these are independent products. The products do have some similarities. For example, both can distribute authorizations and handle authentication requests. Azure AD also provides a central location for account administration and can address cloud applications’ above issues. For example, log in to Office 365 is handled by Azure AD, and the accounts within Azure AD can be linked to all SaaS applications so that you have one account that you can log in to anywhere. It eliminates the numerous separate accounts you have to remember for each online service.

How does CSN deploy these tools for secure home working?
Our employees who work from home through corona can securely access the necessary resources within the data center through the Fortigate SSL-VPN client. It creates a secure tunnel through the Internet from the endpoint to the Fortigate firewall. To keep things simple for employees, they use the same account as Office365. It includes using the same Multi-Factor Authentication (MFA). In our case, this is a push message that authorizes the login attempt with the push of a button. The diagram below shows the connection and authentication schematically:

What do our employees need to do to set up the connection? Watch it in the video below?

Technical interpretation
Now that we have covered the purpose, we can look at the technical interpretation. SAML handles the authentication. We are dealing with three stakeholders in this configuration:

  1. User: the employee who works from home and wants access to the content.
  2. Identity Provider: the party that contains the identities of the employees, or Azure AD.
  3. Service Provider: the party that provides access to the content, or Fortigate firewall.

Want to read more about the configuration? You’ll find all the details in this guide.

The configuration starts with creating an enterprise application within Azure AD. Enter the Fully Qualified Domain Name (FQDN) or the IP address of the Fortinet.

After the enterprise application is configured you can assign it to users. This authorizes employees to use the application. This can also be done on the basis of groups.

The employee can then easily find the connection by logging into Office365. Here you can find the shortcut.

If you followed the Fortigate-ssl-vpn-tutorial guide, the User and Identity Provider is now configured. Now only the Service Provider remains to be done. In this case, that is the Fortigate firewall. After the certificate is imported into the Fortigate, the SAML configuration can start.

Don’t forget to assign the SSL-VPN portal. SAML authentication is possible for web-access and tunnel-access.

As a final step, we need to provide the firewall with a security policy. In our case, we want to give the SSL-VPN users access to a specific application server with a fileshare and a database.

See the video below for the end user experience to setup an ssl-vpn connection

Read more about the specific security tools here: