The rollout of Microsoft-managed policies to block Device Code Flow in conditional access will impact remote management and login processes for Teams devices, common area phones, and Teams Rooms devices. As the default policy will be set to block device code flow, administrators need to adopt best practices to leverage conditional access effectively. This blog post outlines the key impacts of this change and provides practical recommendations for allowing device code flow to ensure seamless and secure remote management.
The policy changes are particularly important for Android-based shared Teams devices, such as Microsoft Teams Rooms on Android, IP Phones, and Panels. Without creating exclusion lists for these devices, administrators will lose the ability to remotely sign in and manage them after sign-out, as they will not be able to re-authenticate with DCF.
Take a moment to review the blog post covering this announcement and bookmark for future updates:
While we acknowledge the possibility of exclusions, additional conditional access rules can enable remote logins through device code flow. However, this approach must align with enhanced security protocols aimed at restricting device code flow. This includes measures like security group membership, trusted location verification or limiting device code access exclusively to administrators overseeing common areas, such as rooms and shared phone devices.
Options:
- Trusted Locations: Permit device code flow only when initiated from known IP ranges (e.g., office subnets or VPN IPs).
- Named Locations with MFA: Require MFA for named locations if allowing device code flow for users with devices outside of your main perimeter.
- User/Group Scope: Limit the exclusion policy to only specific device accounts used for Teams devices.
Additional monitoring and reporting of DCF use:
- Track usage of device code flow.
- Set up alerts for unexpected geolocations, time-of-day logins, or unusual IPs
The default policy:
Initially the Microsoft managed policy will be implemented in report-only mode.
At the time of this post, the policy was created manually, the Microsoft managed policy is not deployed to this tenant.
The policy may look something like this:
Note the policy is applied to all users and the grant control is set to block.
In report-only mode, we can review sign-in logs, and select conditional access report-only to confirm this policy would block the DCF authentication flow.
If this policy is moved from report-only to enabled:
When navigating to authentication broker remote login, the remote authentication attempt will fail (an account can still log in directly from the device - but this may be difficult for admin's remotely managing devices, or local resources who would need to navigate a smaller device screen, or non-touchscreen devices)
Remember the Microsoft managed policy default settings block DCF for all users with no excluded accounts or devices.
Modify the Policy:
Lets modify the policy to require Compliant Device and allow from trusted location(s).
Exclude the named location as trusted and exclude the named trusted location from the block DCF policy - if your organization has not leveraged named locations before the guidance can be found HERE
Navigate to the Device Code Flow policy - and exclude the named trusted location.
When configuring Conditional Access policies in Microsoft Entra ID (formerly Azure AD), the behavior of exclusions depends on how the conditions are set up. If you apply exclusions for both named trusted locations and devices marked as compliant, the exclusion will take place if either condition is met. This means that if a sign-in attempt comes from a named trusted location or from a device marked as compliant, the policy will exclude that attempt from the restrictions.
An alternate, more secure method is applying a grant control, requiring a compliant device.
Note - when selecting "Require device to be marked as compliant" the grant control changes from Block Access to 1 (or more) controls selected.
Requiring device compliance as a grant control is generally considered more secure because it enforces compliance checks at the point of access, ensuring that only devices meeting the organization's security standards can access resources. You may apply this grant control to all cloud applications within a specific policy, not nested within the DCF exclusion. This approach reduces the risk of unauthorized access and provides a higher level of security compared to excluding devices marked as compliant, which may leave gaps if not carefully managed.
Result:
It's important to note that while excluding trusted named locations is one way to permit Device Code Flow (DCF), alternative approaches may offer a stronger security posture. For example, instead of relying solely on location-based exclusions, consider limiting DCF access to only shared device accounts—such as Teams Rooms and common area phones by using a dedicated security group. This ensures DCF is tightly scoped to specific, low-privilege identities used solely for device provisioning and management.
Closing Thoughts:
As Microsoft continues to tighten the security posture of identity and access management through managed policies like the DCF block, it’s essential for organizations to strike the right balance between usability and protection. While trusted named locations offer a straightforward method for allowing device code flow, more robust alternatives—such as scoping access to dedicated security groups for Teams Room and shared device accounts—provide greater assurance against misuse. By leveraging Conditional Access, enforcing least privilege, and monitoring sign-in activity, organizations can maintain a strong security posture without disrupting the legitimate provisioning and management of Teams devices.
No comments:
Post a Comment