If you use Azure AD to host your user accounts, you may want to create conditional access policies for when employees attempt to access certain cloud applications. An example might be an enterprise resource planning solution, an employee benefits site or a password manager. A couple of conditions you can assign might be:

• Require MFA as an extra layer of authentication beyond passwords to reduce the risk of unauthorized access even if credentials are compromised.
• Require that access be only granted from Azure joined devices.

Conditional access policies allow you to safeguard sensitive information and apply stricter controls only where they're most needed. They may also aid in complying with various regulatory requirements and helps mitigate risks associated with remote work.

In this example I am going to create a conditional access policy for LastPass, a password management tool. To create a conditional access policy for a specific cloud application, sign into the Microsoft Intune Admin Center and navigate to Devices > Conditional Access. Click "New policy" to start configuring the new conditional access policy.

Give the policy a descriptive name and go to assignments. For users I chose a group comprised of all IT workers that regularly access many applications. I then selected the two LastPass cloud applications that our organization uses as shown in the screenshot below:

Then under Access Controls I will create two conditions for granted access. The first is MFA and the second is that the user must be using a compliant device as shown below.

For added security you can specify a sign in frequency under the Session category. Assigning a sign-in frequency requires users to re-authenticate periodically when accessing cloud applications or resources. As shown in the screenshot below, administrators can customize the frequency based on the sensitivity of the applications or data. In this case I am requiring users to reauthenticate each day.

Given the increasing ease with which passwords can be compromised, relying solely on password authentication is no longer a secure method for controlling access. In response to this vulnerability, many companies are now widely implementing Multi-Factor Authentication (MFA) to strengthen their cybersecurity defenses. MFA adds an essential layer of security by requiring multiple forms of verification, such as passwords, security tokens, or biometric scans. This added layer of protection makes it significantly harder for unauthorized individuals to access sensitive data.

Intune provides multiple secure authentication alternatives. Some built in options include Passwordless MFA that includes phishing resistant methods that use Microsoft Authenticator. It also includes the use of FIDO2 security keys and Windows Hello for Business. Intune. In the case of FIDO2 keys, you can restrict authentication to specific manufacturers.

Custom Authentication Strengths

 Microsoft Intune provides administrators with the flexibility to create tailored authentication requirements that can precisely match their organization's security needs. Administrators can create up to 15 custom authentication strength using the following authentication methods:

• Password
• SMS
• Voice call
• Microsoft Authenticator app (push notification)
• OATH hardware token
• OATH software token
• Windows Hello for Business
• FIDO2 security key
• Certificate-based authentication

You can use different combinations to enforce specific authentication methods for different scenarios. For instance, different authentication strengths can be required based on whether users are accessing resources from inside or outside the corporate network. Stronger authentication methods can also be required for users or sign-ins deemed high-risk.

To create new authentication strengths using Microsoft Intune Admin Center and navigate to Conditional Access > Authentication strengths and click "New authentication strength". Then select the desired authentication method. In the example below I made a authentication strength for Passkeys FIDO2.

I then clicked the advanced options and chose checked Microsoft Authenticator (Preview).

Then click create and you are one.

Creating a Conditional Access Policy

Now let’s use the new authentication strength in a conditional access policy. Return back to Conditional Access and click “Create New Policy.” Then do the following:

• Give the policy a descriptive name such as "Require FIDO2 for Passwordless Access".
• Under "Users and groups", select the users or groups you want this policy to apply to.
• Under "Cloud apps or actions", select the applications you want to protect as shown in the screenshot below

You can then choose the conditions that will trigger the policy such as User risk level, device platform or location.

To configure the Access controls, go to Grant and select Require authentication strength" and select an existing custom strength. You can also create a new authentication strength here as well.

The Grant section will now show 1 control selected as shown below.

Now Set "Enable policy" to "On" and create the policy. You have now created a conditional access policy with your custom authentication strength.

The Microsoft Intune Admin Center enables you to create Conditional Access policies based on locations for additional granular control over access to organizational resources. This feature is particularly valuable for entities with geographically limited operations, such as school districts, government institutions, or regional businesses.

For instance, if your organization's users are primarily located within a single country, you can implement a policy that restricts logins from all other countries. This approach significantly enhances your security posture by mitigating risks associated with global cyber threats.

By leveraging Named Locations in Conditional Access policies, you can effectively:

1. Block access attempts from unexpected geographical areas

2. Reduce the attack surface for brute force and credential stuffing attacks

3. Minimize the risk of unauthorized access from foreign IP addresses

By restricting access from unfamiliar or high-risk locations, organizations can reduce the risk of unauthorized access and potential security breaches.

Create Country Locations

To create these location areas, you need to navigate to Devices > Conditional Access > Named Locations. Here you can create locations according to Countries, IP addresses and Multifactor Authentication Trusted IPs as shown below.

Let’s say you want to create a conditional access policy that stops all login attempts from other countries. Click Countries location and select all countries outside of your own as shown here.

Once you've defined the Named Location, you can proceed to create a corresponding Conditional Access policy. Configure the policy to use the location condition, selecting the Named Location you've previously defined. You may want to initially enable the policy in "Report-only" mode. This allows you to monitor its potential impact without affecting user access. You also need to be mindful of employees who travel internationally as this may require you to:

a) Create exceptions for specific users or groups

b) Implement a process to temporarily modify the policy for traveling employees

c) Create a traveling policy that allows access from all countries and assign it to anyone traveling temporarily.

The screenshot below shows how anyone attempting access from all other countries of the world will be blocked.

Other Location Scenarios

You can also create locations based on IP addresses or ranges. You can use these locations for a variety of instances. For instance, you can create policies that differentiate between office locations and remote work environments that apply security measures differently for set locations. You also may be receiving failed login attempts from a certain IP address and make a conditional access policy to block it.

You can also create trusted IP locations to coincide with your MFA conditional access policies. In this scenario, all logins except those originating from your trusted IP ranges. Users connecting from trusted locations will not be prompted for MFA, while those connecting from outside these ranges will need to complete MFA.

One of the first objectives of a hacker upon infiltrating a network is to gain access to a privileged identity within your organization. One of the more powerful privileged accounts in your network is probably an Intune admin as these accounts weld a lot of power. Should one of those accounts get compromised, they can do significant list of things to your MDM environment such as deploy a malicious application to your corporate devices such as ransomware or backdoor apps. They could also deploy a harmful PowerShell script or other executable script.

MAA is like MFA

With the rapidly expanding threat landscape of today, relying on a single password to secure user accounts is no longer viable. This is why multifactor authentication (MFA) is now considered best practice, as it provides an additional security layer to protect digital identities. Now let’s apply that same logic to your Intune environment.

You cannot risk the compromise of a single Intune admin account that can then execute malicious tasks at will. Like MFA, Multi Admin Approval (MAA) adds an extra layer of security by requiring multiple administrators to approve certain critical actions before they can be executed. This means that if you create a new policy to deploy an application, that policy will not be enabled until a member of the assigned approval group authorizes the action.

When a Tenant account attempts to modify a resource protected by an access policy, Intune implements withholds applying the change until a member of the designated approval group reviews and authorizes it. This process ensures that critical changes undergo additional scrutiny before implementation. The approver has the authority to either approve the change and allow it to proceed or reject it which will block it entirely.

How to Configure MAA in Intune

Note there are some prerequisites that must be met prior to enabling MAA:

• Multi admin approval requires a minimum of two administrator accounts within your tenant
• Creating an access policy requires that your account be assigned either the Intune Service Administrator role or Azure Global Administrator role.
• To qualify as an approver, an account must belong to the group assigned to the access policy for a specific type of resource.

To enable MAA for Intune go to the Microsoft Endpoint Manager admin center and navigate to Tenant Administration > Multi Admin Approval > select Access policies and click Create as shown in the screenshot below.

Create a name for the MAA policy and select either Scripts or Apps for the Profile type as shown below.

Next is the Approvers page where you will click “Add groups” and select the group of users that will act as approvers for this policy.

Then review and click Create to finalize and save the policy.

Approving Requests

So now let’s say you create an Intune policy to deploy a new application. A new step will be required for you to include the business justification for your request. Rather than an active policy, it is submitted as a request and awaits approval. You can monitor the status of your requests on the MAA page. There you will see a list of all your submitted requests, along with their current status.

The status of your requests can be one of the following:

• Pending: The request is waiting for approval from another administrator.
• Approved: The request has been approved and the changes have been applied.
• Rejected: The request was rejected by an approver.
• Canceled: The request was canceled by you or another administrator.

To approve the request of another admin, simply navigate to Pending requests and select the specific request you want to approve. Make sure that all administrators involved in the approval process are notified of pending actions.

Traditional cybersecurity approaches have primarily focused on attack prevention through measures like firewalls, antivirus software, and access controls. Recently however, cybersecurity has transitioned to a resiliency mindset. With the rise of advanced persistent threats (APTs), state-sponsored attacks, ransomware, and other sophisticated cyber threats, it has become increasingly difficult to prevent all attacks through traditional security measures alone. Resiliency acknowledges that breaches are likely to occur and focuses on minimizing their impact and ensuring continuity of operations.

At any moment, attackers can begin exploiting a vulnerability that is unknown to anyone in the world except themselves. These zero-day attacks are particularly challenging because you cannot defend against a threat you are unaware of. The compromise of user accounts has also become common place using phishing and credential stuffing attacks. It has become clear that organizations must prepare themselves for the inevitability that such attacks are probably going to occur. By fostering resilience in their systems and networks, they can limit the blast zone and prevent attackers from moving laterally across the network and obtaining greater privileges. A resilient approach acknowledges that breaches are likely to happen and focuses on minimizing their impact and ensuring continuity of operations.

How Group Policy can Help

A primary means of building resilience within your enterprise is to enforce the principle of least privilege (PoLP). PoLP minimizes security risks by ensuring users and systems have only the necessary access to perform their tasks. This reduces the potential attack surface, limits the impact of breaches, and prevents unauthorized access to sensitive data, thereby enhancing overall cybersecurity in an increasingly complex and threat-prone digital environment. Here are some classic Group Policy settings to harden your attack surface.

You can quickly restrict access to the command prompt completely with User Configuration > Administrative Templates > System and enable ‘Prevent access to the command prompt’. For additional security, you can select ‘Disable the command prompt script processing also’ as shown in the screenshot below. This means that any script that attempts to execute a batch file will fail, and users will not be able to run batch scripts manually.

By disabling both the command prompt and script processing, this setting significantly enhances security by reducing the potential for users to execute potentially harmful scripts or commands.

Enforcing the membership of privileged local groups on all your enterprise computers is a crucial aspect of resiliency building. You can achieve this using either Group Policy Preferences or the Security Settings in Group Policy. In the example below, I have chosen the latter approach. I navigated to **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **Restricted Groups**. I then selected the local Administrators group and specified domain admins as the only members, as shown below.

These examples illustrate how you can leverage Group Policy to enhance the resilience of your Windows machines against various threats and vulnerabilities. By implementing settings through Group Policy Administrative Templates and Preferences, you can enforce robust security configurations across your Windows environment.

However, these are just a few of the many resilience-focused measures that can be deployed using Group Policy. In the next installment of this article series, we will explore additional resilient settings and configurations that can be implemented through Group Policy to further fortify your Windows infrastructure against cyber threats, insider risks, and potential misconfigurations.

While security professionals have traditionally recommended that users change their passwords regularly, this mantra is no longer considered a best practice. In fact, there are valid reasons why an organization may choose to even remove the ability for users to change passwords altogether. By restricting password changes, organizations can ensure that password resets and updates are centrally managed and controlled, aligning with their security policies and compliance requirements.

One scenario where restricting password changes can be beneficial is in educational institutions where student usernames are required to contain assigned student ID numbers. Allowing students to change their passwords could lead to inconsistencies and potential issues with account management.

Other examples include environments where shared accounts are used where permitting individual users to change passwords can lead to confusion, disruption, and potential security risks. By removing this ability, organizations can ensure that shared account passwords are managed centrally and consistently.

Some organizations may already have established password management solutions or processes in place, such as Local Administrator Password Solution (LAPS) or third-party password management tools. In these cases, removing the ability for users to change passwords through Intune can help prevent conflicts or inconsistencies with these existing solutions, ensuring a streamlined and cohesive password management approach.

Creating the Necessary Intune Configuration Profile

To prevent users from changing their passwords using the Microsoft Intune admin center go to Devices > Configuration and create a new policy. Select ‘Windows 10 and later’ as the platform and choose ‘Administrative Templates’ as the profile type. Then name the profile and proceed to configuration settings.

You will find the appropriate settings in User Configuration > System > Ctrl+Alt+Del Options and enable ‘Remove Change Password” as shown in the screenshot below.

While restricting the ability for users to change passwords can address certain challenges, it is recommended that organizations carefully evaluate their specific requirements, security policies, and existing processes before implementing such a policy. They should consider any potential complexity issues in terms of password management and user experience that it may introduce.

Security baselines are used to standardize and enforce security configurations across devices to reduce vulnerabilities and ensure compliance. They allow organizations to rapidly deploy a hardened, secure configuration across their managed Windows devices. The baselines contain groups of pre-configured settings recommended by Microsoft's product security teams, saving significant time and effort in researching and testing individual settings. Pre-configured baselines simplify the deployment of security settings to make it easier for IT administrators to apply comprehensive security policies without having to configure each setting manually. By using predefined baselines, administrators can save time and effort compared to developing and implementing custom security policies from scratch.

Security baselines can be deployed using either Group Policy or Microsoft Intune. Group Policy baselines are typically managed by importing the latest Microsoft Security Compliance Toolkit baselines and customizing settings via GPOs while Intune security baselines are managed directly in the Intune admin console, where admins can create profiles based on the built-in Microsoft-provided baselines and customize settings.

While providing a solid security foundation, baselines can also be customized to meet the specific needs of an organization by adjusting the pre-configured security settings as required. You can assign different Intune security baselines to different user or device groups. This allows you to tailor the security configurations based on specific requirements or roles within your organization. After creating the desired security baseline profiles, you can assign each profile to different user or device groups within your Intune environment. This allows you to apply distinct security configurations to different sets of users or devices based on their roles, locations, or other criteria.

Deploying Security Baselines with Intune

To deploy security baselines using the Microsoft Intune admin center, navigate to Endpoint security > Security baseline and select from the available security baselines. For this example, I will choose the 'Security Baseline for Windows 10 and later' and customize it.

After clicking the selected baseline, click the ‘Create profile’ button to create a new profile.

Name the new profile and then proceed to the Configuration settings section. The baseline template has all the settings configured according to best practices by Microsoft engineers. However, there are a couple of settings I want to customize in this case. For instance, the Allow Password Manager setting is configured to Block by default, but in this case, I want to allow it for certain user roles.

Another setting I chose to change is to block outbound traffic which is not the case by default.

Of course, I could also choose to accept all the preconfigured settings as they are and create a profile too. In this case, deploying the preconfigured baseline makes it convenient to blast out best practice security settings.

In the same manner that Intune configuration profiles are created, you need to assign this customized security baseline profile to designated groups and then finish out the wizard. You can create as many profiles of the same security baseline as you want. By assigning different Intune security baselines to different user or device groups, you can effectively implement a tailored and granular security strategy that aligns with the specific needs and risk profiles of various segments within your organization.

Conditional Access policies in Microsoft Intune are designed to enhance security by ensuring that only authorized users under specific conditions can access your organization's applications and services. These policies are a critical component of a zero-trust security model, which assumes breach and verifies each request as though it originates from an uncontrolled network. Conditional Access Policies are a potent security mechanism, yet they require careful management to avoid inadvertently locking out individual users including yourself, or even the entire organization.

Let’s say you have all your users and computers contained within Azure Active Directory and you want to create a conditional access policy that restricts access to the Azure AD portal for only Azure administrators or other privileged users that require access to perform their job duties. To create a conditional access policy using the Microsoft Intune Admin Center you navigate to Devices > Conditional Access and create a new policy.

The default action of this policy will be to block access by default to the Azure AD portal. Thus, under “Include” I have selected All users. Note the warning directly underneath this selection that cautions me about locking myself out as the policy will apply to all users, even the person creating the policy and all high privilege administrators.

Thus, it is imperative that I assign groups that will be excluded from the default action. As shown in the screenshot below, I have selected an assembly of users and groups to exclude.

The next step is to select a Target Resource. The target resource refers to the applications, services, or data that the policy will protect. These resources are what the policy conditions apply to, determining how and when users can access them based on specific criteria such as user identity, device compliance, location, and risk level. Target resources can include cloud applications, which in this case is Windows Azure Service Management as shown below.

For this policy, I will not set any conditions, such as location or device platform, because I intend to block access irrespective of these factors. The final step is to specify what action will be granted to the Azure portal. Here I am going to block access for all users except for those specifically excluded from this policy. Since I have yet to exclude my own account or any group that includes my account, Intune is providing a final warning, cautioning that the policy I'm about to implement will prevent me from accessing the Azure portal.

Conditional Access policies are a powerful tool to enforce least privilege access to your critical resources. However, caution is necessary, as a single unintended click could lead to adverse outcomes.

In my previous blog I showed how to setup LAPS for Azure AD. With everything configured correctly, now it is time to retrieve the password for the local administrator account that our policy addresses. To retrieve the password, go to your Azure portal and navigate to Devices > All Devices > Local administrator password recovery (Preview) and find the selected device. Click on Show local administrator password beside the listed device. Navigate to the right and either show the password or click the copy button as shown in the screenshot below.

Armed with the specified password, you can now log into the device using the local administrator credentials and execute tasks that necessitate local admin privileges.

In an earlier blog I talked about Windows LAPS (LAPS2) that was released in April 2023. It was designed to replace the original version of LAPS, now known as Legacy LAPS. We explored its integration in an on-prem AD setting across multiple articles. Today, let's pivot to applying it within the Azure AD framework.

Windows LAPS is designed to help bolster security by minimizing the risk associated with compromised local administrator passwords that could grant unwarranted access to networked Windows devices. A prevalent scenario in many enterprises is the use of a uniform local admin account across all Windows endpoints, characterized by an identical username and password. This poses a significant security gap because if a single account is breached, a threat actor could potentially gain administrative access to every interconnected device. In the case of a school district, once one student gets a hold of the local admin credentials, it doesn’t take long until the entire student body has admin rights, wreaking havoc on the machines.

Windows LAPS ensures each local admin account is assigned a unique password. For instance, if you oversee multiple Windows devices all having a local admin account labeled 'Admin1', Windows LAPS allows you to set a unique password for each of these accounts. Additionally, these passwords come with a specified expiration period, after which a new randomized password is created. While my earlier blog series delved into setting up LAPS via Group Policy, in this piece, we'll explore its configuration using Intune.

PRE-REQUISITES FOR WINDOWS LAPS AZURE AD

The prerequisites for Windows LAPS are few. There is nothing to install because Intune policies are used to configure the LAPS CSP already on the devices. Here is what you need:

• An Intune license
• All computers need to be on Windows 10 or Windows 11 with the April 2023 Cumulative Update installed
• Requires one of the following roles in Azure AD: Global Administrator, Cloud Device Administrator, or Intune Administrator.

Because Azure is cloud based, you can access Windows LAPS from anywhere and Intune’s scalability allows you to easily manage a great many systems. It is important to remember one downside and that is the dependency on the internet. If your internet service is down and you don’t have an alternative means to reach Azure, you will have no way to retrieve the LAPS password. That being said, let’s get to configuring Windows LAPS for Azure AD.

Configuring LAPS for Azure AD

Before you create an Intune policy you must first access your Azure portal (portal.azure.com) and enable LAPS. Navigate to Devices > Device Settings and scroll down. Then turn on the “Enable Azure AD Local Administrator Password Solution” as shown below.

Once that is completed, you can move on to Intune. Using the Microsoft Intune admin center navigate to Endpoint Security > Account protection and click Create Policy. Choose “Windows 10 and later” as the Platform and “Local admin password solution Windows LAPS” as shown in the screenshot below.

After naming the policy it is time to configure settings as shown below. Of course, in this instance we will choose Azure AD only as the Backup Directory.

For the Administrator Account Name, I chose a custom account called fabadmin. If you are using Windows LAPS to manage any custom local administrator account, you must enter the name of that account here. You can leave this field blank if you are configuring LAPS for the built-in administrator, even if you have changed the name from its default name.  

For Password Complexity there are four options:

• Large letters
• Large letters + small letters
• Large letters + small letters + numbers
• Large letters + small letters + numbers + special characters

Note that four options are the default if you don’t select an option.

Post Authentication Actions is used to specify the actions to take upon expiration of the configured grace period which is 12 days in this instance. There are three options here.

• Reset password: upon expiry of the grace period, the managed account password will be reset.
• Reset the password and logoff the managed account: upon expiry of the grace period, the managed account password will be reset and any interactive logon sessions using the managed account will be terminated. (Default behavior)
• Reset the password and reboot: upon expiry of the grace period, the managed account password will be reset, and the managed device will be immediately rebooted.
• Not configured.

If no selection is made, the setting will default to the logoff option.

Post Authentication Reset Delay Sets the delay in hours before the previous actions above is executed. The default is 24 hours which is also the maximum.

With your settings configured, assign relevant scopes, and deploy the rule to the Azure Ad group you want to manage with this policy. In my next blog I will talk about how to retrieve the password from Azure and how to audit LAPS retrieval.