Microsoft Entra ID Authentication Request Types
Hello! I'm currently investigating Microsoft Entra ID sign-in logs and would like to understand the following authentication request types: CredentialAuthenticationController:UnifiedPlatformCredentialChallenge RiskPhoneVerify:AcmaRiskPhoneVerify I have searched the available Microsoft documentation but haven't found references that explicitly explain these identifiers. I'd like to ask for some help to clarify the following: What do these request types represent? What authentication processes or security mechanisms trigger them? Are these expected during normal user authentication, MFA, or risk-based verification? Do these events indicate an authentication challenge, an actual credential submission, or a verification attempt? Is there any official Microsoft documentation or reference explaining these identifiers? My objective is to properly interpret these events during security monitoring and avoid incorrectly classifying legitimate authentication activity as suspicious. Any technical references or clarification would be greatly appreciated. Thank you!
Single group for TEAM AND Lighthouse (Security Group + 'Unified' group)
Trying to simplify our groups, since we are a 20+ year old firm, the variety of groups we have has bloated over the years. I'm trying to clean these up, but I've met a hitch. Our Service Desk dept has their own Internal team. Aka a 365 Group. Aka a 'unified' group. We use Lighthouse, which only takes Security Groups - it can't take the above 365 Group. First instinct is to create a Security group that can be used for both. But I can't seem to find a way to do this. The 365 Group is unable to nest a Security group. The Security group is unable to nest a 365 Group. So there's no single source of truth. I thought I could use Dynamic Grouping as a workaround - using the MemberOf property. But according to this, this Preview Feature is being abandoned and disabled. Anyone have workarounds/advice? Here's the output I get, when trying to do this via EOM PS C:\Users\lmtpo\Downloads> New-MgGroupMember -GroupID (team) -DirectoryObjectId (sec) New-MgGroupMember : Non-Unified Security Groups cannot be added to Unified Groups. paramName: Members, paramValue... PS C:\Users\lmtpo\Downloads> New-MgGroupMember -GroupID (sec) -DirectoryObjectId (team) New-MgGroupMember : A Unified Group cannot be added as a member of a Distribution List or Security Group or Elevated Group. paramName: Members, paramValue: , objectType: Microsoft.Online.DirectoryServices.Group
Security Info blocked by conditional access
Hello, We have a conditional access policy in place where a specific group can only access Microsoft 365 (deny all apps, except Office 365). The moment a user clicks on Security Info in My Account, the user is blocked by this policy. I cant find a way to exclude the app "My Signins" (AppId 19db86c3-b2b9-44cc-b339-36da233a3be2). Since MFA is forced for this group, they can't change their authenticator app registration. Is there a solution for this? Initial MFA setup works by the way. UPDATE jan 23, 2025: I contacted Microsoft support and this was their answer (in short): " MySignin is a very sensitive resource that is not available in the picker and cannot be excluded in the conditional access policy. Also, the application is calling Microsoft Graph. I understand that this is not the information you are looking to hear at this time, I would have loved to help but the application cannot be excluded from the policy. "
Locked account due to many attempts from malicious IP
Hello experts, today, a user contacted me that she cannot access M365 and asked to unlock her account. 1st thing I've checked were her log-ins in MS Entra and there I've found many and many attempts to log in from different countries - like India, Russia, Demark etc... that happened with just few seconds delay.... As a result, the user's account got blocked. Had to deal 1st time with this kind of issue.... See pictures below. Now, it looks like there was another user under the same attack few days ago (who is on vacation so doesnt know he is blocked for now :)).... Anyway, wondering - how I can prevent these types of attack? We have MFA (app auth) configured so even if the password got broken, MFA should prevent the attacker to sign in. I was going to create a conditional access but there are countries like Italy, Denmark (and other EU ones) etc that I don't want to block. We have M365 E3 with M365 E5 Security subscriptions assigned to all users. Would be grateful for any advise.
Need Microsoft support to resolve a historical tenant association with a domain I recently acquired
Hello, I recently became the legitimate and independent registrant of a domain that had previously been owned or used by an unrelated organization. I have no affiliation whatsoever with the previous domain holder or that organization. I have now received a Microsoft Power Platform notification at an email address under my domain concerning a Default environment belonging to the previous organization. The notification includes a Tenant ID and Environment ID, and the environment name corresponds to that organization. I do not own, administer, or have access to this tenant or Power Platform environment, and I am not seeking access to or control over it. My main concern is that there may still be a historical association between my domain or its email addresses and the previous organization's Microsoft tenant or related services. I would like Microsoft to investigate this and, where necessary, properly separate my domain and its email addresses from any unrelated historical Microsoft accounts, tenants, directories, or services. Most importantly, I want to ensure that this historical association will not adversely affect my ability in the future to use my domain and its business email addresses to create, verify, and use my own Microsoft 365, Microsoft Entra, Power Platform, or other Microsoft business services. At present, I do not have a Microsoft business account, Microsoft 365 tenant, or Power Platform tenant of my own. As a result, I appear to be unable to use some of the normal business support channels that require an existing tenant or administrator account. Could someone please advise me on the appropriate way to get this matter reviewed by Microsoft Support? If a Microsoft employee or official support representative can assist or direct me to the appropriate private support channel, I would greatly appreciate it. For privacy and security reasons, I have intentionally not posted the actual domain name, email address, Tenant ID, or Environment ID publicly. I am happy to provide all of the relevant details privately to an authorized Microsoft support representative if required. Thank you for any guidance.Disabled account OU
Hello We have a scenario for which I need help User account was disabled and was in Disabled account OU when she joined back it was enabled and moved to proper user account OU.This is synched from onpremise in O365 The earlier mailbox is converted from user mailbox to a cloud mailbox.This is a incloud object How do we proceed here We want the shared mailbox to be linked to the user account which was disabled earlier. Regards,
Best practices: Open OneDrive/SharePoint sharing but restrict Teams guest access by domain
Hi all, Since SharePoint Online and OneDrive moved fully to Microsoft Entra B2B for external sharing, we've run into a policy conflict and would like to hear how others are handling it. Our requirements Enable OneDrive and SharePoint file sharing with external users, regardless of their email domain. Restrict Microsoft Teams guest access to a predefined list of approved partner domains. Continue allowing Teams external access (federated chat and meetings) for all domains. The problem: Teams guests, SharePoint guests, and OneDrive guests are now governed by the same Microsoft Entra B2B invitation framework and the single Collaboration restrictions allow/deny list under: External Identities → External collaboration settings As a result, restricting guest invitations by domain also restricts OneDrive and SharePoint sharing for domains not on the allowlist. According to Microsoft's response in the following Q&A, this behavior is currently by design: https://learn.microsoft.com/en-us/answers/questions/5954975/onedrive-external-sharing-no-longer-working-with-a Questions to the community Has anyone implemented a solution where OneDrive/SharePoint sharing remains open to all domains while Teams guest access is restricted to approved domains only? Are there recommended approaches using Entitlement Management, Access Packages, Connected Organizations, or other Entra capabilities? Is there any roadmap item for workload-specific collaboration restrictions (e.g., separate policies for Teams guest invitations and SharePoint/OneDrive sharing)? Any real-world experience or best practices would be greatly appreciated. Thanks, BejhanPHS staged rollout works for existing users but not new synced users
We are troubleshooting an Entra ID PHS staged rollout issue with a federated domain using a third-party WS-Fed IdP. The intended behavior is that normal federated users redirect to the IdP, while users in the PHS staged rollout group receive the Microsoft/Entra password prompt instead. Existing users in the staged rollout group continue to work correctly. They enter their UPN and receive the Microsoft password prompt. One known-good test user is not provisioned in the third-party IdP and still signs in successfully through the Entra password prompt, so the working path does not require the user to exist in the IdP. The issue is only with newly created AD-synced users. Newly synced users in the same staged rollout group are still being routed to the federated IdP at HRD instead of receiving the Entra password prompt. We’ve verified the staged rollout policy and group membership from Graph, confirmed the affected users are properly AD-synced with clean immutableID/sourceAnchor, and confirmed PHS is working. Federation metadata and HRD policies also look clean. Seamless SSO/AZUREADSSOACC was checked and remediated, but the behavior did not change. For failed attempts, there is no Entra sign-in log entry, including tenant-wide interactive and non-interactive logs. However, the federated IdP logs show a WS-Fed inbound request from login.microsoftonline.com for the affected user. That makes it look like Entra HRD is routing the user to federation before sign-in logging or token issuance. The issue started around an Entra Connect AD connector/DC-path change. We have since reverted the connector to the previous known-good configuration. After reverting, we created a clean-room test user with the correct UPN set before first sync, confirmed sync/PHS/sourceAnchor, added the user directly to the staged rollout group, and waited 60+ minutes. The clean-room user still redirected to the federated IdP instead of getting the Entra password prompt. So the current behavior is that established staged-rollout users still get the Entra password prompt, but newly created synced staged-rollout users are sent to the federated IdP by HRD. Has anyone seen staged rollout get into this state, where existing users work but new synced users remain on the federated HRD path despite valid rollout policy, group membership, synced password hash, and clean immutableID/sourceAnchor? Is there any known backend cache/state reset or escalation path for HRD/staged rollout routing?
