Mastering Azure Conditional Access: A SkyCore Setup Guide for Enhanced Security

Step 1: Understand Conditional Access Fundamentals

Azure Conditional Access operates on an "if-then" logic, where "if" represents conditions (e.g., user, location, device) and "then" represents the access controls enforced (e.g., require MFA, block access). It evaluates various signals to make granular decisions post-first-factor authentication, acting as a crucial element in a Zero Trust security model.

Common signals include user/group identity, IP location, device state, application being accessed, and real-time risk detection from Microsoft Entra ID Protection. Common decisions range from blocking access to granting it with additional requirements like multifactor authentication or a compliant device.

# No direct command for conceptual understanding.
# This step involves reviewing documentation to grasp core concepts.
# Refer to: https://learn.microsoft.com/en-us/entra/identity/conditional-access/overview

Expected result: A clear understanding of how Conditional Access functions as an identity-driven Zero Trust policy engine, making decisions based on signals and enforcing access controls.

Step 2: Verify Prerequisites and Licensing

Before configuring policies, ensure your Microsoft Entra tenant has the necessary licensing and that your administrative account possesses the required roles. Conditional Access functionality is dependent on Microsoft Entra ID P1 or P2 licenses.

# Connect to Microsoft Graph
Connect-MgGraph -Scopes 'User.Read.All','Policy.Read.All','Policy.ReadWrite.ConditionalAccess'

# Check your current user's assigned roles (requires specific permissions, or check via portal)
Get-MgUserAppRoleAssignment -UserId (Get-MgContext).UserId | Select-Object -ExpandProperty DisplayName

# To list Conditional Access policies (requires Conditional Access Administrator or Security Administrator role)
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State

Connect-MgGraph -Scopes 'User.Read.All','Policy.Read.All','Policy.ReadWrite.ConditionalAccess': Establishes a connection to Microsoft Graph with necessary permissions for reading user roles and managing Conditional Access policies.

Get-MgUserAppRoleAssignment -UserId (Get-MgContext).UserId: Retrieves the application role assignments (including Entra ID roles) for the currently connected user.

Get-MgIdentityConditionalAccessPolicy: Lists existing Conditional Access policies in your tenant, allowing you to verify permissions.

Portal alternative: Sign in to the Microsoft Entra admin center. Navigate to Entra ID > Overview > Manage tenants > Licenses to verify license status. For roles, go to Entra ID > Users > All users > Select a user > Assigned roles.

Expected result: Confirmation of active Microsoft Entra ID P1/P2 licenses and verification that your administrative account holds a role like Conditional Access Administrator, Security Administrator, or Global Administrator.

Step 3: Establish Emergency Access Accounts

Emergency access, or 'break-glass,' accounts are critical to prevent administrative lockout in scenarios where Conditional Access policies are misconfigured, or identity services experience outages. These accounts should be highly secured, physical-access controlled, and explicitly excluded from *all* Conditional Access policies.

# No direct CLI for creating 'break-glass' accounts in a specific way beyond standard user creation.
# This step involves creating standard user accounts and assigning them high-privileged roles.
# Ensure these accounts are cloud-only and not synchronized from on-premises directories.

# Example: Assigning Global Administrator role to an existing user (replace 'breakglassuser@yourdomain.com' with actual UPN)
$user = Get-MgUser -UserId 'breakglassuser@yourdomain.com'
$roleId = (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id
New-MgDirectoryRoleMemberByRef -DirectoryRoleId $roleId -Body @{ '@odata.id'="https://graph.microsoft.com/v1.0/users/$($user.Id)" }

# Later, when creating policies, explicitly exclude these accounts.

Get-MgUser -UserId 'breakglassuser@yourdomain.com': Retrieves the user object for the emergency access account.

Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'": Finds the object ID for the Global Administrator role.

New-MgDirectoryRoleMemberByRef: Assigns the Global Administrator role to the specified emergency user account.

Portal alternative: Create a new user in Microsoft Entra admin center > Entra ID > Users > All users > New user > Create new user. Assign roles via Assigned roles > Add assignments. Ensure these accounts are cloud-only. Then, when configuring Conditional Access policies, under Assignments > Exclude > Users and groups, select these emergency access accounts.

Expected result: One or more dedicated emergency access accounts with high-privileged roles (e.g., Global Administrator) are configured, tested, and ready to be excluded from all Conditional Access policies.

Step 4: Define Named Locations

Named locations allow you to define trusted IP ranges or geographic regions that can be used as conditions in your Conditional Access policies. This is useful for scenarios such as not requiring MFA when users are within your corporate network (trusted location) or blocking access from known malicious countries.

# Connect to Microsoft Graph if not already connected
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'

# Define a new IP named location (e.g., your corporate office)
$ipRanges = @('203.0.113.0/24', '198.51.100.0/24') # Replace with your actual IP ranges
$namedLocationName = 'SkyCore Trusted Corporate Network'

New-MgIdentityConditionalAccessNamedLocation -DisplayName $namedLocationName -IpRanges @(
    $ipRanges | ForEach-Object { @{ 'CidrAddress' = $_ } }
) -OdataType '#microsoft.graph.ipNamedLocation'

# Define a new Countries named location (e.g., for blocking specific countries)
$countryLocationName = 'SkyCore Blocked Countries'
$countryCodes = @('RU', 'CN', 'KP') # Example ISO 3166-1 alpha-2 codes

New-MgIdentityConditionalAccessNamedLocation -DisplayName $countryLocationName -CountriesAndRegions @(
    $countryCodes | ForEach-Object { @{ 'CountryOrRegion' = $_; 'Include' = $true } }
) -OdataType '#microsoft.graph.countriesAndRegionsNamedLocation'

New-MgIdentityConditionalAccessNamedLocation: Creates a new named location in Microsoft Entra ID.

-DisplayName: Specifies the user-friendly name for the named location.

-IpRanges: Used for IP-based locations, accepting an array of CIDR addresses.

-CountriesAndRegions: Used for country-based locations, accepting an array of ISO 3166-1 alpha-2 country codes.

-OdataType: Specifies the type of named location (IP or countries/regions).

Portal alternative: In the Microsoft Entra admin center, navigate to Entra ID > Conditional Access > Named locations. Select New location > IP ranges location or New location > Countries/Regions location. Enter the required details and save.

Expected result: Trusted IP ranges (e.g., corporate network) and potentially specific country/region lists are defined as named locations within Microsoft Entra ID, ready for use in Conditional Access policies.

Step 5: Create a Baseline MFA Policy for All Users

Implementing Multi-Factor Authentication (MFA) is one of the most effective security measures. CISA and NIST SP 800-63B strongly recommend MFA for all users, particularly for administrative accounts. This foundational policy requires MFA for all users accessing all cloud apps, utilizing an authentication strength.

# While direct PowerShell for creating a *full* Conditional Access policy definition
# with all conditions and grant controls isn't explicitly provided as a single command in the reference docs,
# you would typically use the Microsoft Graph PowerShell SDK to interact with the underlying Graph API.

# Connect to Microsoft Graph with appropriate permissions
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'

# A conceptual example of creating a Conditional Access policy via PowerShell:
# Note: Constructing the 'Conditions' and 'GrantControls' objects directly in PowerShell
# for a complex policy is intricate and often involves building nested objects or JSON payloads.
# For exact syntax, refer to the Microsoft Graph API documentation for Conditional Access policies.

# Example of a simplified New-MgIdentityConditionalAccessPolicy command structure (not a full working example for the policy below):
# New-MgIdentityConditionalAccessPolicy -DisplayName '01_Require_MFA_for_All_Users' `
# -Conditions @{
#     # Refer to Graph API documentation for full conditions structure
# } `
# -GrantControls @{
#     # Refer to Graph API documentation for full grant controls structure
# } `
# -State 'enabledForReportingButBlocked' # or 'enabled' after testing

# For initial setup, the Microsoft Entra admin center provides a guided, template-based approach.

New-MgIdentityConditionalAccessPolicy: The cmdlet used to create a new Conditional Access policy via Microsoft Graph PowerShell. However, the complex JSON or nested object structure required for -Conditions and -GrantControls is best developed by consulting the Microsoft Graph API documentation directly, as the provided reference documentation for this guide focuses on GUI steps for policy content.

Portal alternative (recommended for initial setup): Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.

1. Navigate to Entra ID > Conditional Access > Policies.
2. Select New policy.
3. Give your policy a name, e.g., '01_Require_MFA_for_All_Users'.
4. Under Assignments > Users or workload identities:
   • Under Include, select All users.
   • Under Exclude: Select Users and groups and choose your organization's emergency access/break-glass accounts. Optionally, exclude directory synchronization accounts (e.g., Microsoft Entra Connect Sync Account) or guest users if you have separate policies for them.
5. Under Target resources > Cloud apps or actions > Include, select All cloud apps.
6. Under Access controls > Grant:
   • Select Grant access.
   • Select Require authentication strength, then choose the built-in Multifactor authentication strength from the list.
   • Select Select.
7. Confirm your settings and set Enable policy to Report-only.
8. Select Create.

Expected result: A new Conditional Access policy is created, named '01_Require_MFA_for_All_Users', configured to require multifactor authentication for all included users accessing all cloud applications. The policy is initially set to "Report-only" mode for testing.

Step 6: Implement MFA for Administrative Roles

Securing administrative accounts is paramount. This policy specifically targets users assigned to privileged Microsoft Entra roles, mandating MFA for their access to any cloud application. This aligns with Microsoft's recommendation for securing security information registration and admin portals.

# Similar to Step 5, for creating the policy via CLI, you would use New-MgIdentityConditionalAccessPolicy.
# The primary difference would be in the 'Users' condition, targeting specific directory roles.

# Example of targeting specific roles in the policy conditions (conceptual):
# -Conditions @{
#     Users = @{
#         IncludeRoles = @(
#             (Get-MgDirectoryRole -Filter "DisplayName eq 'Global Administrator'").Id,
#             (Get-MgDirectoryRole -Filter "DisplayName eq 'Conditional Access Administrator'").Id,
#             # Add other sensitive roles here
#         )
#         ExcludeUsers = @('emergencyaccount@yourdomain.com')
#     }
#     # Other conditions remain similar to the 'All Users' policy
# }

Portal alternative (recommended):

1. In the Microsoft Entra admin center, navigate to Entra ID > Conditional Access > Policies.
2. Select New policy.
3. Name it, e.g., '02_MFA_for_Admin_Roles'.
4. Under Assignments > Users or workload identities:
   • Under Include > Directory roles, select specific administrative roles like Global Administrator, Conditional Access Administrator, Security Administrator, Exchange Administrator, etc.
   • Under Exclude: Select your emergency access/break-glass accounts.
5. Under Target resources > Cloud apps or actions > Include, select All cloud apps.
6. Under Access controls > Grant:
   • Select Grant access.
   • Select Require multifactor authentication.
   • Select Select.
7. Set Enable policy to Report-only and Create.

Expected result: A policy named '02_MFA_for_Admin_Roles' is in "Report-only" mode, requiring MFA for users in specified administrative roles when accessing any cloud application.

Step 7: Block Legacy Authentication Protocols

Legacy authentication protocols (e.g., POP3, IMAP, SMTP, older versions of MAPI) do not support modern security features like MFA and are highly susceptible to credential stuffing and brute-force attacks. Blocking these protocols significantly reduces your attack surface.

# As with previous policy creation steps, this involves New-MgIdentityConditionalAccessPolicy.
# The key condition here is 'Client apps', specifically targeting 'Other clients'.

# Conceptual structure for 'Client apps' condition:
# -Conditions @{
#     ClientAppTypes = @('other') # 'other' specifically targets legacy auth clients
# }
# -GrantControls @{
#     BlockAccess = $true
# }

Portal alternative (recommended):

1. In the Microsoft Entra admin center, navigate to Entra ID > Conditional Access > Policies.
2. Select New policy.
3. Name it, e.g., '03_Block_Legacy_Authentication'.
4. Under Assignments > Users or workload identities:
   • Under Include, select All users.
   • Under Exclude: Select your emergency access/break-glass accounts.
5. Under Target resources > Cloud apps or actions > Include, select All cloud apps.
6. Under Conditions > Client apps:
   • Set Configure to Yes.
   • Select Other clients. (This targets clients using legacy authentication protocols).
7. Under Access controls > Grant:
   • Select Block access.
   • Select Select.
8. Set Enable policy to Report-only and Create.

Expected result: A policy named '03_Block_Legacy_Authentication' is in "Report-only" mode, preventing all users from authenticating using legacy protocols across all cloud applications.

Step 8: Require MFA for Azure Management Access

Protecting access to the Azure management portal is critical to safeguard your cloud infrastructure. This policy mandates MFA for any attempt to access Azure management interfaces (e.g., Azure portal, Azure PowerShell, Azure CLI).

# For CLI, the key difference from the 'All Users' MFA policy is the 'Cloud apps' condition,
# targeting 'Microsoft Azure Management'.

# Conceptual structure for 'Cloud apps' condition:
# -Conditions @{
#     Applications = @{
#         IncludeApplications = @('797f4846-ba00-4fd7-ba43-dac1f8f63013') # App ID for 'Microsoft Azure Management'
#     }
# }
# -GrantControls @{
#     RequireMfa = $true
# }

Portal alternative (recommended):

1. In the Microsoft Entra admin center, navigate to Entra ID > Conditional Access > Policies.
2. Select New policy.
3. Name it, e.g., '04_MFA_for_Azure_Management'.
4. Under Assignments > Users or workload identities:
   • Under Include, select All users.
   • Under Exclude: Select your emergency access/break-glass accounts.
5. Under Target resources > Cloud apps or actions > Include:
   • Select Select apps.
   • Search for and select Microsoft Azure Management.
6. Under Access controls > Grant:
   • Select Grant access.
   • Select Require multifactor authentication.
   • Select Select.
7. Set Enable policy to Report-only and Create.

Expected result: A policy named '04_MFA_for_Azure_Management' is in "Report-only" mode, requiring MFA for all users attempting to access the Azure management portal or related services.

Step 9: Enforce Device Compliance or Hybrid Join

Requiring devices to be managed and compliant ensures that access to sensitive applications only occurs from devices that meet your organization's security standards (e.g., up-to-date OS, antivirus installed, disk encryption). This typically integrates with Microsoft Intune for device compliance or requires devices to be Microsoft Entra hybrid joined.

# For CLI, the policy would use New-MgIdentityConditionalAccessPolicy, with the 'Devices' condition.
# The 'Grant controls' would include 'RequireCompliantDevice' or 'RequireDomainJoinedDevice'.

# Conceptual structure for 'Device state' and 'Grant controls':
# -Conditions @{
#     Applications = @{
#         IncludeApplications = @('Specific_Sensitive_App_ID') # Or 'All cloud apps'
#     }
#     Devices = @{
#         # No specific properties here, it's about the grant control below
#     }
# }
# -GrantControls @{
#     Operator = 'OR' # Important: Allow either compliant OR hybrid joined
#     GrantAccess = $true
#     RequireCompliantDevice = $true
#     RequireDomainJoinedDevice = $true
# }

Portal alternative (recommended):

1. In the Microsoft Entra admin center, navigate to Entra ID > Conditional Access > Policies.
2. Select New policy.
3. Name it, e.g., '05_Require_Compliant_or_HybridJoined_Device'.
4. Under Assignments > Users or workload identities:
   • Under Include, select All users (or specific groups for sensitive apps).
   • Under Exclude: Select your emergency access/break-glass accounts.
5. Under Target resources > Cloud apps or actions > Include, select All cloud apps (or specific sensitive applications like SharePoint, Salesforce, etc.).
6. Under Access controls > Grant:
   • Select Grant access.
   • Select Require device to be marked as compliant AND/OR Require Microsoft Entra hybrid joined device. We recommend using Require device to be marked as compliant for cloud-native organizations or those using Intune, and adding Require Microsoft Entra hybrid joined device if you have a significant on-premises AD presence. Configure the 'For multiple controls' option to Require one of the selected controls (logical OR).
   • Select Select.
7. Set Enable policy to Report-only and Create.

Expected result: A policy named '05_Require_Compliant_or_HybridJoined_Device' is in "Report-only" mode, mandating that users access specified cloud apps from either a compliant device (managed by Intune) or a Microsoft Entra hybrid joined device.

Step 10: Test Policies with Report-Only Mode

Before enforcing any Conditional Access policy, always deploy it in "Report-only" mode. This allows you to evaluate the potential impact of a policy on users and applications without actually enforcing it, minimizing disruption to your organization.

# To set an existing policy to Report-only mode (if not already set during creation):
Connect-MgGraph -Scopes 'Policy.ReadWrite.ConditionalAccess'

# Replace 'Policy ID' with the actual ID of your policy
# Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, Id # Use this to find policy IDs
$policyId = 'YOUR_POLICY_ID'

Update-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $policyId -State 'enabledForReportingButBlocked'

# To use the 'What If' tool (no direct CLI equivalent; it's a portal feature)
# The 'What If' tool helps predict policy impact for specific users/conditions.

Update-MgIdentityConditionalAccessPolicy: Modifies an existing Conditional Access policy.

-ConditionalAccessPolicyId: Specifies the ID of the policy to update.

-State 'enabledForReportingButBlocked': Sets the policy to report-only mode.

Portal alternative (recommended for testing):

1. For policies created in Report-only mode, navigate to Entra ID > Conditional Access > Policies. Select the policy and review its status.
2. To use the 'What If' tool: On the Conditional Access Policies page, select What If.
3. Configure the test parameters (User, Cloud apps, IP address, Device state, etc.) to simulate a sign-in scenario.
4. Select What If to view the results, which indicate which policies would apply and if access would be granted or blocked.
5. Review the Sign-in logs (Entra ID > Monitoring & health > Sign-in logs) and filter by Conditional Access > Report-only status to see the impact of your policies over time.
6. Once thoroughly tested and confident in the policy's impact, edit the policy and change Enable policy from Report-only to On.

Expected result: Policies are deployed in Report-only mode. You have used the "What If" tool and reviewed sign-in logs to confirm the expected behavior and impact of your new policies without affecting user access.

Step 11: Monitor and Refine Policies

Conditional Access policies are not a "set it and forget it" solution. Continuous monitoring of sign-in logs and security reports is essential to identify potential issues, unexpected blocks, or evolving threats. Regularly review and refine your policies based on user feedback, organizational changes, and emerging security best practices.

# To review sign-in logs for Conditional Access details
Connect-MgGraph -Scopes 'AuditLog.Read.All','Policy.Read.All'

Get-MgAuditLogSignIn -Filter "createdDateTime ge $( (Get-Date).AddDays(-7).ToString('yyyy-MM-ddTHH:mm:ssZ') )" |
Select-Object UserPrincipalName, AppDisplayName, IpAddress, `
@{Name='ConditionalAccessPolicyResult'; Expression={$_.ConditionalAccessStatus.DisplayName}} |
Format-Table -AutoSize

# This command retrieves sign-in logs from the last 7 days and displays relevant Conditional Access information.

Get-MgAuditLogSignIn: Retrieves sign-in events from the audit logs.

-Filter "createdDateTime ge ...": Filters logs to a specific date range (last 7 days in this example).

Select-Object ...: Selects and formats specific properties including the Conditional Access policy result.

Portal alternative (recommended): In the Microsoft Entra admin center, navigate to Entra ID > Monitoring & health > Sign-in logs. Utilize filters for Conditional Access status (e.g., 'Success', 'Failure', 'Not applied', 'Report-only') to drill down into policy evaluations. Pay close attention to users who frequently encounter blocks or warnings that indicate a policy misconfiguration or a new threat. The Conditional Access Overview page also provides a summary of recent activity and policy coverage.

Expected result: An ongoing process for monitoring Conditional Access policy impact is established. Policies are periodically reviewed and updated to adapt to changes in your environment and threat landscape.