conditional access
731 TopicsiOS managed contacts - how to deal with that?
Hi everyone, the last years i've already tried to solve the problem with the managed contacts. Because this was not possible earlier i forgot about that. Now i want to readress this issue. A very important article i've found is this one: Techcommunity Success: New contact sync scenario available with Outlook for iOS on enrolled devices With this thread i would like to discuss some unanswered questions of myself. I would really appreaciate any answer of you guys. 🙂 Goals: Business contacts should be able to be read through contacts app (because of caller-id) 3rd Party Messengers should not see these business contacts Thesises: It is not possible to achive this with Outlook for iOS and it's contact sync feature, right? (Because of these contacts are going to be synced through icloud, therefore these contacts are marked as "unmanaged contacts.) It is possible to achive these goals by using: an device configuration profile which configures an active sync account which only synchronizes the contacts of the users mailbox. These contacts are considdered as "managed contacts" an app configuration profile which disables the "sync contacts" feature for "outlook for ios" An App protection policy which disables "Viewing corporate documents in unmanaged apps Because of the fact this is only working for enrolled and managed devices, we need to tell the users: Caller identification is only possible if you enroll your device in Intune. (in relation to the previous points) So far, so good, but the bad news is: Because of the incopatibility with conditional access policies, we're hence not able to restrict the user from using other apps to connect their EXO account. Right? I would be very thankful if anyone can discuss this with me. (I think the best way to adress the different topics is to quote my post and answer inline.) Greetings, Patrick8KViews0likes7CommentsStrengthen your security posture with Microsoft Entra Conditional Access
Learn how Microsoft Entra Conditional Access, our Microsoft Zero Trust policy engine, protects access for your workforce and for agents by enforcing real‑time adaptive access policies that continuously assess risk signals and use AI‑driven automation to dynamically allow, challenge, or block access for every identity. Join Microsoft experts as they walk through real‑world scenarios and share practical guidance to help your identity team address policy sprawl, enforce consistent Conditional Access policies, and strengthen security posture across your environment. How do I participate? Registration is not required. Add this event to your calendar, then sign in to the Tech Community and select Attend to receive reminders. Post your questions in advance, or any time during the live broadcast.359Views0likes2CommentsApp Enforced Restrictions not working on Chrome
Hi All I hope you are well. Anyway, a strange one here. We have implemented App Enforced Restrictions on unmanaged / BYOD macOS devices. This seems to have taken effect on Edge and Safari browsers but not Chrome. Is there anything we can do to resolve this or force BYOD macOS to use Edge? Info appreciated. SK104Views0likes3CommentsPolicy applied allthough it shouldn't
Hi, all of a sudden Intune chaanges its behavior. I have a policy in place that sets persistent browser session. On the device filter tab I excluded devices with this syntax: device.trustType -eq "ServerAD" -or device.deviceOwnership -eq "Company" Starting last week I have to re-authenticate on a remote Desktop running Windows Server 2025 every 8 hours. Thats what the policy requires. In Entra I see in the logs for my user that this conditional access policy applied. I then extended the filter to this device.trustType -eq "ServerAD" -or device.deviceOwnership -eq "Company" -or device.operatingSystem -contains "Server" But it did not make a difference. Any idea what is going? This is not specific to my tenant. On a different tenant it behaves the same way.150Views0likes6CommentsBYOD devices can't launch Windows 365 PC because of device compliance check during CA policy check.
We have a device compliance policy for all cloud apps. We would like to allow personal (BYOD) devices to be able to connect to Windows 365 Cloud PC. In the sign in logs we see the failures for application "Windows 365 Client" app id 4fb5cc57-dbbc-4cdc-9595-748adff5f414. We can't exclude that application in the conditional access policy as it's not available. We already added exclusions for Azure Virtual Desktop, Windows 365 and Windows Cloud Login. How can we allow BYOD devices to connect to cloud PCs?118Views0likes1CommentProtect org data on BYOD Windows / macOS devices
Hi All I hope you are well. Anyway, I have a need to protect org data on: Window personal / BYOD devices MacOS personal / BYOD devices What's the best way to achieve this? My thinking is: 1 X Conditional Access policy that blocks 1 X Conditional Access policy that allows via Edge, no persistent session, no downloads etc Device filter on both policies that target unmanaged devices Any other suggestions? SK106Views0likes3CommentsMFA Options for Employees without Phones
Hello everbody, we're currently trying to implement MFA in our company, but approximately 1/10 of our employees have a workphone and are not allowed to use their personal phone. Since we also recently introduced Intune, the idea was to just use Windows Hello for Business, but when trying to provision it, we realized that you need to have MFA active for an account to be able to even activate it? Which kinda defeats the purpose. So my question is, is there some way to circumvent the MFA requirement for WHfB? Or what other options do we realistically have? Thanks in Advance!280Views1like3CommentsGlobal Secure Access - Conditional Access Require GSA - Android Blocked
Hello all, I am currently working on deploying Global Secure Access client with Microsoft Forward Traffic profile and a conditional access policy to block access to M365 services unless connected through the GSA client. I have this working as I want it for Windows and mobile devices in a tenant we use for development. However, when I set this up at our live tenant, I cannot get the Android device to work. My setup is a Personally Owned Work Profile with the Defender app deployed and configured to enable GSA. I can connect to Global Secure Access and it does show some traffic tunneling to Microsoft. However, when I go to login to another app like Outlook, it blocks the sign-in. This is not the case for an iPhone I have personally enrolled and my Entra Joined laptop. Upon investigation of any differences between our development tenant (working fully) and our tenant (Android not working) I found that in the GSA section under Services, there is an extra service called “Microsoft Entra Channel Access”. This service does not show up when I am logged in our developer tenant. Even on the same phone by removing work profiles and signing in to both tenants, our live tenant shows the new channel, and the developer tenant does not have it. I did some log review with the advanced diagnostics feature and the app and noted a few things I am lead to believe that the issue is with this new Entra Channel that has been deployed to our live tenant and not to our dev tenant yet. When I go to sign-in to the Outlook application in the work profile for the developer tenant, I can see the authentication traffic being tunneled through the Microsoft 365 profile. (login.live.com, login.microsoftonline.com, and aadcdn.msftauth.net). However, in our production tenant when doing the same test I do not see those destinations being tunneled at all. I do see the traffic being collected in the “Hostname” section, but is not being tunneled. Another interesting point with this is that on an iPhone I am testing; I do see the authentication destinations being tunneled through the Entra Channel. Here are the screenshots of my findings. https://imgur.com/a/82r3HQC I have an open Microsoft support case and hoping to get the attention of a Microsoft employee or MVP who may be able to get this in front of the Entra product team to see if this is a bug.241Views1like1CommentAdvice required for temp / agency staff
Hi All I hope you are well. Anyway, I'm hoping someone can point me in the right direction. We have Android devices in Entra Shared Device Mode (Multi App) which any of our employees with a valid UPN can logon to. All good there. What we need is a solution for temporary or agency staff. This would be staff that could be called on at very short notice and may not stay around for long. For security and audit reasons, we'd rather not create "userless" accounts. Is there anything in Entra / Entra Shared Device Mode that can achieve this? Info greatly appreciated. SK56Views0likes1Comment'Microsoft App Access Panel' and Conditional Access with SSPR combined registration bug
Currently, enabling self-service password reset (SSPR) registration enforcement causes the app 'Microsoft App Access Panel' to be added to the login flow of users who have SSPR enabled. This app is not able to be excluded from Conditional Access (CA) polices and is caught by 'All cloud apps', which breaks secure zero-trust scenarios and CA policy configurations. Best way to demonstrate this is through examples... ----Example 1---- Environment: CA Policy 1 - 'All cloud apps' requiring hybrid/compliant device, but excluding [App] (for all non-guest accounts) CA Policy 2 - [App] requiring MFA only (for contractor accounts, etc) CA Policy 3 - [App] requiring hybrid/compliant device (for internal accounts, etc) SSPR registration enforcement (Password reset > Registration) - set to 'Yes' MFA registration enforcement (Security > Authentication Methods > Registration campaign) - set to 'Enabled' Scenario: A new user requires access to web [App] on an unenrolled device and is assigned an account that falls under CA Policy 1 and 2, however [App] is excluded from 1 and shouldn't apply to this login. When accessing [App] for the first time, users must register SSPR/MFA. They see the below message, click 'Next' and are directed to https://accounts.activedirectory.windowsazure.com/passwordreset/register.aspx: Then they see this screen, which will block the login and try to get the user to download the Company Portal app: While behind the scenes, the login to [App] is being blocked by 'Microsoft App Access Panel' because it is seemingly added to the login flow and caught in CA Policy 1 in Req 2/3: CA Policy 1 shows as not applied on Req 1, CA Policy 2 shows as successful for Req 1/2/3 and CA Policy 3 shows as not applied for Req 1/2/3. Creating a CA policy for the 'Register security information' user action has no effect on this scenario and also shows as not applied on all the related sign-in logs. ----Example 2---- Environment: Same as above, but SSPR registration enforcement - set to 'No' Scenario: Same as above, but when accessing the [App] for the first time, they see the below message instead, click 'Next' and are directed to https://accounts.activedirectory.windowsazure.com/proofup.aspx: Then they are directed to the combined SSPR/MFA registration experience successfully: The 'Microsoft App Access Panel' doesn't show in the sign-in logs and the sign-in is successful after registration. From the two examples, it seems to be a bug with the SSPR registration enforcement and the combined registration experience. ----Workarounds---- 1 - Prevent using 'All cloud apps' with device based CA policies (difficult, requires redesigning/thinking/testing policies, could introduce new gaps, etc) 2 - Turn off SSPR registration enforcement and turn on MFA registration enforcement like in example 2 (easy, but only enforces MS MFA App registration, doesn't seem to re-trigger registration if the MS MFA App is removed, no other methods are supported for registration, and doesn't remind users to update) 3 - Disable SSPR entirely for affected users (medium depending on available security groups, and doesn't allow for affected users to use SSPR) ----Related links---- https://feedback.azure.com/d365community/idea/d5253b08-d076-ed11-a81b-000d3adb7ffd https://feedback.azure.com/d365community/idea/1365df89-c625-ec11-b6e6-000d3a4f0789 Conditional Access Policies, Guest Access and the "Microsoft Invitation Acceptance Portal" - Microsoft Community Hub MS, please either: 1 - Allow 'Microsoft App Access Panel' to be added to CA policies so it can be excluded 2 - Prevent 'Microsoft App Access Panel' from showing up in the CA login flow when SSPR registration enforcement is enabled21KViews2likes15Comments