CA policy for corporate devices
I would like to create a conditional access policy to block all non corporate devices from accessing Office 365 resources. I created a policy: Applies to -> User Group Applies to -> all resources Applies to -> Win 10 Filter for devices exception-> Ownership: company & trust type: Entra Hybrid joined. Action: block The above works fine for office desktop login, i.e. blocks non corporate devices and allows corporate devices. However, a side effect is that sign ins from browser on a corporate device is still blocked.User with hundreds of Interactive Sign-In log entries that are "Interrupted"
I have one user in our organization that has hundreds of Interactive Sign-in logs in EntraID that are marked as "Interrupted". I don't even know where to start with the user. Does anyone have a recommendation for isolating the cause of these logs? Recent entries are 95% related to Office Online Core SSO application.
Entra-ID Privileged Identity Management for Groups
We have used PIM for groups to assign certain Azure Security groups to eligible users. For example a group which provides the contributor role to a certain subscription. This group is added in PIM for groups, and eligible users have been assigned to the group, in which they can provide themselves with the privileges if required to do so for maximum 8 hours. However, when we assign a user to a PIM protected group, then there is no way to tell from the user's properties, that the user has been assigned (eligible) to a PIM protected group. Therefore wouldn't it be better to create PIM groups and add the assigned user as a member of a PIM group, and assign the PIM group as eligible to the PIM protected group? Then you would able to see from the Groups list if the user is illegible for any PIM groups.
Can't access Intune Company Portal from Android device after enabling Phishing resistant MFA
HI, Since I enabled Phishing resistant MFA in my tenant, I have been unable to access the company portal on my android phone. Login starts the auth process, but the app keeps telling me that it doesn't support pass keys. If this is the case, is the way that I can exclude the app from my CA policy to allow me to install apps that I have made available to the device? Kind Rgds Lee
Microsoft Authenticator Passkeys for Entra ID on unmanaged devices
Hello, has anyone successfully registered passkeys on an unmanaged phone in an organisation with device compliance policies? Use case is to provide a phishing-resistant MFA option via Authenticator app for logging into apps on their desktop. Users already have authenticator app on their phone and do number matching MFA. https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-register-passkey-authenticator?tabs=iOS When I select "Create a passkey" - I need to log into my account. However I'm blocked from successful authentication because I have conditional access policies to require compliant devices. As my mobile phone is not enrolled into Intune, I never get to the step where the passkey is created and registered. Based on the constraints - it seems like passkeys cannot be used for unmanaged/BYOD devices for organisations that have device compliance policies. It can only be used for users who have enrolled their mobile phone. Looking to see if anyone has tips or different experience using passkeys on unmanaged mobile phones to log into Entra?SCIM - Provision null values
Hoping to get some more official feedback regarding Entra's in-ability to provision null values, mainly outbound provisioning. The SCIM standard caters for this use case, so what is Microsoft's reluctance on this functionality? If it's the concern of breaking functionality, surely it can be an 'opt-in' setting like the bulk delete setting? I know some good conversation has taken place here: https://learn.microsoft.com/en-us/answers/questions/223936/sending-an-empty-value-with-user-provisioning-(sci
Advice needed: Multitenant organization issues
Hey peeps, a client of mine is asking for an optimal solution to their sub-optimal organization structure. I want to see if there's something more I can do here or if we are stuck with our environment the way it is. It's such a strange ask that it will take a few paragraphs to describe, so bear with me. Client has a central corporate entity, but the "branch" entities operate separately and have a fair amount of self-governance. This central corporate entity has a Microsoft365 tenant and that's what everyone's email matches, including branch members. Let's call it corp.onmicrosoft.com with a verified domain of corp.com. So, everyone at corporate and the branches have addresses/UPNs of @corp.com. Before my time, one of the self-governing branches chose to setup a Sharepoint site specific to their branch. They put all the files on a separate 365 tenant of corp-ny.onmicrosoft.com with verified domain corp-ny.com. There are a couple of identities on that 365 tenant, but since everyone uses their corp.com email, they access the Sharepoint data from their primary corporate identities as GUESTS of the branch's tenant. So the branch tenant has 3 members and 100+ guests. We perform IT for just the BRANCH, not the corporate structure. Since corporate IT is not interested in changing infrastructure at this time, we would like to convert all the guest identities on the branch tenant to members and we can then leverage technologies like Intune & CA and move them off of their on-premise AD server that is not doing AD Connect. I have a quick script that will do all of that - convert, license, set some properties for all 100 members. Seems okay! After the change, members will have their corporate identity for email, and the branch identity for Sharepoint and Windows login. We've identified a problem, however, with notifications. When you comment on a file in Sharepoint, a notification is generated for anyone that participates in that file. The notification is sent from the commenter's identity. Currently, that means notifications come from @corp.com . However, after the change those notifications will come from corp-ny.com. This domain does NOT have an MX record associated with it 😞 and we think this will lead to a LOT of confusion if people try to reply directly to the emails. It might also have the potential(?) to fail email spoofing checks or be flagged as suspicious by email servers. Additionally, the notifications would be sent to their branch identities, which I assume would not deliver. Even if it did deliver and we added an MX record, it would be in an inbox that's not checked by the team. My question is: Can I mask the notification email to be from "email address removed for privacy reasons" for all of the notifications? Or, Can I "spoof" the emails so that they appear to be sent from the corporate identity? Secondly, What's the best way to deal with notifications headed to the wrong inbox? Can a transport rule redirect these emails to their corporate emails?
MFA denied; duplicate authentication attempt
We see a lot of entries in the Entra ID Sign in logs with "MFA denied; duplicate authentication attempt". Most of the time a lot of them are registered in a short amount of time Users are not (yet) complaining. May be users don't even see something wrong. Anyone who knows what this means? (MFA denied; duplicate authentication attempt) kind regards JurgenAdditional Microsoft 365 users not showing as registered users on an Entra ID joined device.
Most of our clients are on M365 these days, and they consist of the following variations in how they integrate: On-prem AD with no Entra ID sync to M365. On-prem AD with Entra ID sync to M365 but no hybrid connection for devices. On-prem AD with Entra ID sync and hybrid connection for devices with Intune. No on-prem AD with all devices connected directly to Entra ID and Intune. For clients using integration methods 1 and 2, we always see multiple device registrations in Entra ID, and for clients using integration method 3, we see a primary user that was used to hybrid join the device, along with additional users showing up as registered in Entra ID. However, we have just recently discovered that clients that use method 4, i.e. they are 100% Entra ID with no on-prem AD, the only user that shows in Entra ID is the user that joined the device. Any other use that logs in and creates a profile on one of these machines is not recorded as a registered user in Entra ID for that device. So, for clients that use integration methods 1-3, if we want to remotely block access on a particular device for a specific user, we just need to delete their Entra ID registration for that device. However, for clients using method 4, we have no visibility for the additional user, nor can we remotely block a user in this scenario. Is this behaviour a current bug in the Entra ID join/register process? Or is this the expected behaviour? If the latter, then this seems to be a flaw in the join/register process.
