In my previous blog post, I explained how we can use FIDO2 security keys to perform password-less authentication with Azure AD. You can access it using Step-by-Step Guide: Azure AD password-less sign-in using FIDO2 Security keys
We also can use FIDO2 security keys to sign-in to Azure AD Joined or Hybrid Azure AD Joined Windows 10 devices. In this demo, I am going to demonstrate how we can enable FIDO2 security key sign-in using Azure AD and Microsoft Intune.
Before enabling password-less authentication with FIDO2 security keys, make sure you have,

1. Azure AD and Intune – Make sure you have valid Azure AD and Intune subscription in place.
2. Azure AD Join on Hybrid Azure AD joined Windows 10 Devices – If it is Azure AD Join device, it should run at least Windows 10 version 1903. If it is Hybrid Azure AD joined device at least it should be running Windows 10 Insider Build 18945
3. FIDO2 Security keys – The good people at eWBM provided eWBM Goldengate security key G320 (USB-C) and eWBM Goldengate security key G310 (USB-A) for testing. I will be using eWBM Goldengate security key G320 (USB-C) in this demo with Surface Pro 7.

4. Azure AD user account which completed the FIDO2 security key enrolment process – This explained in details via my previous post http://www.rebeladmin.com/2020/03/step-step-guide-azure-ad-password-less-sign-using-fido2-security-keys/

In this demo, I am going to use a user called Megan Bowen (meganb@M365x620957.onmicrosoft.com) for testing. I already have an Azure AD join device ready for her. It is showing as compliant in the Microsoft Intune portal.

Enable Windows Hello for Business with Intune

Before we create a device configuration profile, we need to enable Windows Hello for Business with FIDO2 security key support. To do that,

1. Log in to Azure Portal as Global Administrator ( https://portal.azure.com/ )
2. Search for Intune in the search box and click on it.

3. Then click on Device Enrolment

4. In the new window click on Windows enrollment | Windows Hello for Business

5. Select Enable for Configure Windows Hello for Business. Then keep the default settings.

6. Also, select Enable for Use security keys for sign-in

This will enable FIOD2 security key support.

7. At the end click on Save to apply the changes.

In an organization, we add users to roles, groups, and applications to allow them to do certain tasks. Some of these tasks may not be carried out frequently. Is there a better way to handle these types of access, how we can ensure a user only have the relevant permissions when they required?

Azure AD Access packages allow administrators to manage access permissions to groups, applications and SharePoint sites in a more efficient way. Internal and external users will have relevant permissions to do their tasks only when they required. It will reduce the manual review of the user account permissions. The relevant policies will ensure who can request access, how the access requests are handled and when the access permissions will be revoked.

Azure AD access packages can use to,

• Manage membership of Azure AD groups
• Manage membership of Office 365 groups
• Manage membership of SharePoint sites
• Mange membership of Azure AD applications

In this post, I am going to demonstrate how we can manage access permissions using Azure AD Access Package.

In my demo environment, I have a user called Debra Berger. She is going to work on a new recruiting campaign. As part of her job, she has to access LinkedIn application. At the moment only members of sg-Finance & sg-Sales and Marketing groups have access to it. Debra Berger is not a member of both groups. She only needs this app for the new campaign. So, let’s go ahead and create an access package for this.

To do this,

1. Log in to Azure Portal as Global Administrator https://portal.azure.com/

2. Go to Menu and click on Azure Active Directory

3. Then click on Identity Governance

4. Click on Access packages

5. Then click on New access package

6. It will open a new wizard to create access packages. Provide name, description, and catalog for the new access package. By default, the catalog is set to General, if required you can create your own. Once settings are in click on Next: Resource roles >

OpenVPN is an open-source VPN protocol that is trusted by many cloud service providers to provide site-to-site, point-to-site, and point-to-point connectivity to cloud resources. Now Azure AD authentication also works with OpenVPN protocol. This means we can use Azure AD features such as conditional access, user-based policies, Azure MFA with VPN authentication. In this Demo, I am going to demonstrate how to configure OpenVPN for Azure point-to-site VPN and then how to integrate Azure AD authentication with it. 

Prerequisites

1. To configure OpenVPN, first, we need to have a working point-to-site setup. The native Azure point-to-site VPN setup uses Azure certificate authentication. I wrote an article about it before and it can be accessed using http://www.rebeladmin.com/2018/07/step-step-guide-azure-point-site-vpn/

So, before we start, please go ahead and configure the VPN gateway with certificate authentication.  

2. Also, I am going to use Azure PowerShell for configuration. Please make sure you have the Azure PowerShell module installed. More info about it can find under https://docs.microsoft.com/en-us/powershell/azure/install-az-ps?view=azps-2.6.0

Configure OpenVPN for Azure P2S VPN

1. Launch PowerShell console and connect to Azure using Connect-AzAccount (Using Global Administrator Account)

2. Then I ran Get-AzVirtualNetworkGateway -ResourceGroupName REBELVPNRG to review my VPN gateway configuration. Here REBELVPNRG is the resource group it belongs to. 

3. Then let's go ahead and change the VPN client protocol to OpenVPN using,

$vpngw = Get-AzVirtualNetworkGateway -ResourceGroupName REBELVPNRG -name REBEL-VPN-GW

Set-AzVirtualNetworkGateway -VirtualNetworkGateway $vpngw -VpnClientProtocol OpenVPN

In the above, REBEL-VPN-GW is the VPN gateway name.

Multi-factor authentication is no longer a privilege. MFA is providing an additional layer of security for identities. MFA solutions are getting cheaper and cheaper. You even can enable MFA for free on certain online services. Microsoft outlook email is a good example of that. When it comes to cloud services this is more and more important.

Azure MFA is cloud-based multi-factor service which can use to provide two-step verification for Azure AD users. Azure MFA for Azure AD users comes as part of Office 365 or Azure AD P1, P2 subscriptions. When subscriptions are in place, we can enable MFA for users using different methods. 

• Enable MFA for all users – This is the most secure method. We can enable this simply by using Office 365 or Azure Portal.  

• Enable MFA for selected users – If the licenses are an issue, we also can enable MFA for selected users. This can be done using the same portals as above. 

• Enable MFA based on conditional access policies – Let's assume sales users are accessing certain apps from various external networks. Using conditional access policies, I can force MFA authentication for any user who is accessing application A from an untrusted network. This way MFA will only be enabled for certain users. 

So far in Azure Active Directory, if we need to add members to a group, we have to go through a few steps. 

To remove members from a group, we have to select members manually and then remove it. 

This process is still okay for small scale changes. But if it is large scale change, it will take time. Also, engineers can make mistakes by selecting the wrong users. Microsoft now allows us to add and remove users based on CSV files. This is still in the preview stage but it is not too early to test. In this demo, I am going to demonstrate how we can add/remove Azure AD group members using CSV files. 

Add Members 

To add members to Azure AD group using the new CSV method, 

1. Log in to Azure Portal (https://portal.azure.com) as Global Administrator or Group Owner.

2. Go to Azure Active Directory | Groups  

3. In this demo, I am going to add users to "Leadership" group. So, I went ahead and click on it. 

Data encryption is one of the basic requirements when it comes to data protection. Using Windows BitLocker, we can easily encrypt virtual and physical disks. We normally use group policies and system center configuration manager (SCCM) to centrally manage/configure BitLocker. 

We also can use Microsoft Intune to manage BitLocker on Azure AD joined Windows 10 devices. This is done by using Microsoft Intune Device configuration Profiles. I previously wrote an article about configuration profiles and explained how we can use it to standardize device configurations on Azure AD join devices. I highly recommend you to go through it before we continue further with this blog post as it explains the basics about configuration profiles. This aforementioned blog post can access using http://www.rebeladmin.com/2019/09/step-step-guide-standardize-desktop-devices-using-microsoft-intune-device-configuration-profiles/

In this demo, I am going to demonstrate how to manage BitLocker using Microsoft Intune. Before we start, we need to have devices enrolled with Intune. You can find more info about device enrollment using my previous blog posts http://www.rebeladmin.com/2018/11/step-step-guide-enroll-windows-10-devices-microsoft-intune-using-autopilot/

In my demo environment, I have Azure AD joined & Intune enrolled windows 10 device called W2007.

Let's go ahead and setup the relevant device configuration profile. 

To do that, 

1. Log in to Azure Portal (https://portal.azure.com) as Global Administrator and go to All services | Intune or else log in to Intune device management portal directly via https://devicemanagement.microsoft.com  

2. Then click on Device configuration | Profiles

3. In the profiles page, click on + Create profile

In my previous blog post, I have explained how we can apply Microsoft security settings to corporate devices using Intune Security Baselines (http://www.rebeladmin.com/2019/08/step-step-guide-apply-security-baselines-windows-10-devices-using-microsoft-intune/). We can apply similar settings to on-premises devices via group policies. Apart from security settings, we use group policies to standardize device configurations in on-premises environments. As an example, we can block user access to control panel settings by using group policy.

Microsoft Intune Device configuration Profiles allow us to push similar desktop settings to cloud-managed (Azure AD + Intune) devices. This allows organizations to maintain granular control over device settings. In this demo, I am going to demonstrate how to set up and apply Microsoft Intune Device configuration Profile. 

• Device configuration Profiles can use to standardize Android, iOS, macOS, Windows Phone 8.1, Windows 8.1, Windows 10 devices. 

• You need to have your devices enrolled with Intune to use this feature. You can find more info about device enrollment using my previous blog posts http://www.rebeladmin.com/2018/11/step-step-guide-enroll-windows-10-devices-microsoft-intune-using-autopilot/ 

In my demo environment, I have Azure AD joined & Intune enrolled windows 10 device called W2003.

Using device configuration profiles, I am going to,

• Disable user access to Control Panel Settings

• Push corporate proxy server settings to IE (server IP 10.10.10.10 with port 8080)

To do that, 

1. Log in to Azure Portal (https://portal.azure.com) as Global Administrator and go to All services | Intune or else log in to Intune device management portal directly via https://devicemanagement.microsoft.com 

2. Then click on Device configuration | Profiles 

3. In the profiles page, click on + Create profile

Microsoft is releasing security baselines for on-premises Active Directory connected devices using group policies. These are used by many organizations around the globe for decades. Using these security settings, administrators can control the state of the corporate devices and maintain the standards. When we are moving device management to the cloud, we can't use group policy settings as group policies are not working in the same way with Azure AD. But now, by using Microsoft Intune security baseline, we can apply Microsoft recommended pre-defined windows security settings to Intune managed Azure AD joined windows 10 devices. 

• This is only applicable for devices with Windows 10 version 1809 and later
• You need to have your devices enrolled with Intune with relevant licenses to use this feature. You can find more info about device enrollment using my previous blog posts http://www.rebeladmin.com/2018/11/step-step-guide-enroll-windows-10-devices-microsoft-intune-using-autopilot/ 
• Microsoft recommended settings are coming with the "Baseline versions". At the moment there is only one baseline version available (MDM Security Baseline for May 2019). But as new windows versions come, there will be new baseline versions. 
• When a new baseline version is available, we can migrate already existing security profiles to the new baseline version. 

In this blog post, I am going to demonstrate how we can use security baseline policies to enforce security settings. 

In my demo setup, I have Azure AD joined Windows 10 device called W5001.

When I log in to this device, I noticed the user has turned off the Windows defender antivirus protection.

Also, Windows defender firewall is turned off. 

As an administrator, I prefer both these services to stay on in all corporate devices. So let's see how we can do this using Intune security baseline policy. 

"Azure Files" is a managed, cloud-based file share that can access via SMB protocol. Once you create Azure File share it can be accessed from any ware using Windows, Linux or macOS. It can also map as a shared drive to a system. This can be used as a unified, reliable, simple solution to replace traditional file servers. 

In the on-premises Active Directory environment, we use NTFS permissions to control access to folders and file shares. If we are replacing traditional file shares with Azure Files, we need a way to manage access permissions to it in a similar manner. This is applicable if these folders are accessed via "Windows Virtual Desktop" or "Domain-Joined Azure VM". Azure File now supports Azure Active Directory Domain Services (Azure AD DS) authentication. Now we can create NTFS access control lists (ACLs) for Azure File Shares to control access permissions in a granular level. In this demo, we are going to look into this new feature in detail. 

To test this, we need following,

• Valid Azure AD Subscription
  
• Azure AD Domain Services on the Azure AD tenant – We need Azure AD Domain Services enabled for the Azure AD tenant. 
• Domain-Joined Azure VM – This need to be added to the Azure AD Domain Services

In my demo setup, I already have a managed domain called rebeladmlive.onmicrosoft.com

I also have a domain-joined VM called SRV01 which I will be using for the testing. 

There are 3 different methods which we can use to integrate on-premises Active Directory with Azure AD. 

• Pass Password hash synchronization

• Federation using Microsoft AD FS or PingFederate

• Pass-through Authentication 

All above methods allow on-premises users to use their existing domain user names and passwords in order to authenticate in to Azure AD integrated services. However, even users can use same user name and passwords, when they access Azure AD integrated services from corporate device (Domain member), they still have to authenticate via sign in page. Azure AD Seamless SSO allow users to access Azure AD integrated services via corporate devices without re-authentication. Azure AD Seamless SSO can use with password hash synchronization and pass-through authentication method. It is not supported to use with federated authentication method (AD FS already capable of provide SSO).

• Azure AD Seamless SSO feature can enable via Azure AD connect. So, it is not required any additional component in environment. 

• This is a free feature. We do not need to pay anything for it.

• Azure AD Seamless SSO works only in domain-joined devices (no need to be Azure AD join)

• If SSO process is fail for any reason, user can still authenticate using user name and password.

• It is supported to work with browser-based web applications and Office 365 clients with app versions 16.0.8730 and above.

• Azure AD Seamless SSO accepts user names as value associated with userPrincipalName attribute or Azure AD connect Alternate ID attribute. 

• Azure AD Seamless SSO uses the securityIdentifier claim in the Kerberos ticket to find the relevant user object in Azure AD.

• Once Azure AD Seamless SSO is enabled, if an application can forward domain_hint (OpenID Connect) or whr (SAML) parameter to identify tenant and login_hint (OpenID Connect) parameter to identify user, we can log in to Azure AD without typing user names. It is also possible if the application uses unique URL and pass the domain info or tenant info. 

• Once user is logged in via SSO, if required user can still sign out and log in as a different user at any time.