Listen to this Post
Introduction:
The paradigm of cybersecurity is shifting from static, perimeter-based defenses to dynamic, identity-centric security models. Conditional Access (CA) in Microsoft Entra ID sits at the heart of this evolution, acting as the automated gatekeeper for your digital estate. By leveraging custom security attributes, organizations can now create incredibly granular, dynamic policies that adapt security postures in real-time, moving us closer to a truly passwordless and resilient security framework.
Learning Objectives:
- Understand the architecture and components of a dynamic Conditional Access policy based on custom security attributes.
- Learn how to implement and manage custom security attributes for user and resource classification.
- Master the PowerShell and Graph API commands required to automate attribute assignment and policy testing.
You Should Know:
- Architecting the Policy Foundation with Custom Security Attributes
Before writing a single policy, you must define the taxonomy of your security attributes. These attributes are metadata tags applied to users, groups, or applications, enabling dynamic policy evaluation.
Verified Commands & Configuration:
Connect to Microsoft Graph API with required permissions Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess", "User.ReadWrite.All", "Directory.ReadWrite.All" Create a new custom security attribute set New-MgDirectoryCustomSecurityAttributeSet -Id "NetworkSecurity" -Description "Attributes for network access policies" Define a new attribute within the set New-MgDirectoryCustomSecurityAttributeDefinition -AttributeSetId "NetworkSecurity" -Id "AccessTier" -Description "User access tier level" -IsCollection <code>$false -Type "String" -IsSearchable</code>$true
Step-by-step guide:
This PowerShell script establishes the foundation for dynamic CA. First, authenticate to the Microsoft Graph with administrative privileges. The `New-MgDirectoryCustomSecurityAttributeSet` command creates a container, “NetworkSecurity,” for our attributes. Subsequently, `New-MgDirectoryCustomSecurityAttributeDefinition` creates a specific attribute named “AccessTier” of type String. This attribute can now be assigned values like “Tier0” for highly privileged users or “Contractor” for external personnel, which CA policies can reference.
2. Automating User Attribute Assignment via PowerShell
Manually tagging users is impractical at scale. Automation is key, using on-premises AD group membership or HR system data as a source.
Verified Commands & Configuration:
Get a user and assign a custom security attribute $User = Get-MgUser -UserId "[email protected]" $Params = @{ "CustomSecurityAttributes" = @{ "NetworkSecurity" = @{ "@odata.type" = "microsoft.graph.customSecurityAttributeValue" "AccessTier" = "Tier1" } } } Update-MgUser -UserId $User.Id -BodyParameter $Params Bulk assignment from a CSV file Import-Csv "C:\users.csv" | ForEach-Object { $Params.CustomSecurityAttributes.NetworkSecurity.AccessTier = $<em>.AccessTier Update-MgUser -UserId $</em>.UserPrincipalName -BodyParameter $Params }
Step-by-step guide:
This sequence automates the population of your custom attributes. The first block assigns the “AccessTier” value of “Tier1” to a single user by updating their profile via the `Update-MgUser` cmdlet. The second, more powerful block, reads from a CSV file containing UserPrincipalName and the desired AccessTier, iterating through each record to apply the attributes in bulk. This ensures your user classification is consistent and maintainable.
3. Crafting the Dynamic Conditional Access Policy
With attributes assigned, you can build the CA policy that uses them as conditions. This moves beyond simple group-based rules.
Verified Commands & Configuration:
{
"displayName": "CA-POL-01: Require MFA and Compliant Device for Tier0 Access",
"state": "enabled",
"conditions": {
"users": {
"includeUsers": "All",
"includeGroups": [],
"includeRoles": [],
"excludeUsers": "[email protected]",
"excludeGroups": [],
"excludeRoles": []
},
"applications": {
"includeApplications": "All",
"excludeApplications": []
},
"userRiskLevels": ["high", "medium"],
"clientAppTypes": ["all"],
"locations": {
"includeLocations": "All",
"excludeLocations": "TrustedSites"
}
},
"grantControls": {
"operator": "AND",
"builtInControls": ["mfa", "compliantDevice"]
}
}
Note: While policies are often created in the portal, they can be managed via the `Microsoft.Graph.Identity.ConditionalAccess` module.
Step-by-step guide:
This JSON represents a robust CA policy. The critical link is not visible in the standard GUI: you would add a filter for devices or, more powerfully, use a custom attribute in the `conditions.users` segment via the Graph API. The policy states: For all users (a dynamic group based on an attribute filter would be used here), accessing all applications, from any location except trusted IPs, and with medium or high user risk, the user MUST grant access via MFA AND use a compliant device. The “breakglass” account is excluded for emergency access.
4. Enforcing Session Controls for High-Risk Attributes
Grant controls are not just about blocking or requiring MFA. Session controls can limit what a user can do within an application after signing in.
Verified Commands & Configuration:
Using Graph API to create a policy with Application Enforced Restrictions (Conceptual) This is typically configured in the portal but demonstrates the principle. The condition would target users with a custom attribute like "AccessTier eq 'Contractor'"
Step-by-step guide:
For users tagged with a custom attribute like "Contractor", you can implement a CA policy that uses “Application Enforced Restrictions” as a session control. This tells the cloud application (like SharePoint or Teams) to enforce its own most restrictive permission set for that user, limiting their ability to download, print, or access sensitive data. This creates a layered defense, where the initial authentication is fortified by continuous access evaluation within the session itself.
5. Simulating Attacks and Validating Policy Efficacy
A policy is only as good as its effectiveness. Using tools to simulate sign-ins that should be blocked is crucial.
Verified Commands & Configuration:
Using curl to simulate a risky sign-in from a Tor exit node (example)
curl -X POST "https://graph.microsoft.com/v1.0/identityProtection/riskDetections" \
-H "Authorization: Bearer <TOKEN>" \
-H "Content-Type: application/json" \
-d '{
"riskEventType": "unfamiliarFeatures",
"riskLevel": "medium",
"riskState": "atRisk",
"userPrincipalName": "[email protected]",
"location": {
"city": "Unknown",
"country": "TOR"
}
}'
Step-by-step guide:
This `curl` command (conceptual, as risk detection is typically automated by Microsoft) illustrates how you might test your policies. By simulating a risk event, such as a sign-in from an unfamiliar location or a Tor network, you can trigger your CA policies that require MFA or block access for medium/high risk. In practice, you would use the `Invoke-MgGraphRequest` command in PowerShell or the CA policy “What If” tool in the Entra admin center to test various sign-in scenarios against your configured policies.
6. Auditing and Alerting on Policy Changes
The configuration of CA policies is highly privileged. Any change must be logged and monitored.
Verified Commands & Configuration:
Search the Unified Audit Log for Conditional Access policy changes Search-UnifiedAuditLog -RecordType "AzureActiveDirectory" -Operations "Update policy" -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) KQL query for Azure Sentinel/Sentinel to alert on CA policy changes SecurityEvent | where Activity contains "Update policy" | where TargetResourceType contains "ConditionalAccess" | project TimeGenerated, Actor, TargetResource, Activity
Step-by-step guide:
Maintaining the integrity of your CA system is critical. The first command uses Exchange Online PowerShell to search the Unified Audit Log for any “Update policy” operations within the last day. For a more robust, automated solution, you can stream these logs to Azure Sentinel. The provided Kusto Query Language (KQL) query will surface any events related to Conditional Access policy modifications, allowing you to create alerts for unauthorized or unexpected changes to your security posture.
What Undercode Say:
- Granularity is Power: The move from static groups to dynamic, attribute-based policies represents the single most significant evolution in IAM, enabling true zero-trust segmentation.
- Automation is Non-Negotiable: The administrative overhead of managing custom attributes is a major hurdle; without full automation via HR systems or synchronized directories, the model will fail.
The implementation of dynamic Conditional Access via custom attributes is not just a feature toggle; it’s a fundamental architectural shift. It demands a deep integration between Identity and Access Management (IAM), HR, and IT operations. The potential to create context-aware policies that consider a user’s role, device health, network location, and real-time risk simultaneously is the cornerstone of modern defense. However, the complexity introduces a new attack surface: misconfigured attributes can easily lead to over-provisioning or, worse, locking out entire departments. Success hinges on a meticulously planned attribute taxonomy and a flawless, automated assignment process.
Prediction:
The sophistication of AI-driven identity attacks will force a rapid adoption of dynamic, attribute-based Conditional Access policies. Within two years, static, group-based policies will be considered a legacy and high-risk configuration. Furthermore, we will see the emergence of “Policy as Code” for CA, where policies are version-controlled, tested in staging environments, and deployed via CI/CD pipelines, making security enforcement as agile as the development processes it aims to protect.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Jan Bakker – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
