Microsoft Account connected apps management
Why is there no visible “Connected apps” management page in Microsoft Account? I noticed that third-party applications connected to a personal Microsoft account can be managed at: https://account.live.com/consent/Manage However, I cannot find any obvious navigation path to this page from the main Microsoft Account portal: https://account.microsoft.com/ The main account portal provides sections such as Security, Privacy, Devices, Subscriptions, and Your info, but there does not appear to be a visible “Connected apps”, “Apps and services”, or “App permissions” entry. I only discovered the consent management page after receiving a Microsoft security notification that a new application had been granted access to my Microsoft account. The “Manage your apps” button in that email links to the older account.live.com consent page. This creates two usability and security concerns: Users may not know where to review or revoke third-party OAuth permissions unless they still have the original security notification email. Microsoft Account management currently uses both microsoft.com and live.com domains, which can be confusing for users trying to verify whether an account-management page is an official Microsoft page. Would it be possible to add a visible “Connected apps”, “Apps and services”, or “App permissions” entry under Security or Privacy in account.microsoft.com? This would not require redesigning the existing consent system. Even a simple link from account.microsoft.com to the existing account.live.com/consent/Manage page would make third-party permission management much easier to discover. Is there currently an official navigation path to this page that I may have missed?
M365 only admin locked out MFA error 53003
I am learning this the hard way....so here it goes. Currently I am locked out of as the only admin on the tenant with error 53003. I was updating some Microsoft MFA default policy settings in Entra and mistakenly deleted the admin user from the exclusions list, and got locked out. Thankfully I have another tenant, not as big the one locked out. Initiated several support tickets for which everyone calls, and despite of subline mentioning the issue says that they have to assign this ticket to Entra. Then the ticket gets updated and noone has been assigned every since. I have initiated severity A support tickets from Azure portal but no one has called in last 24 hours to help. We area business with Business Premium licenses with over 20 users, and now completely locked out. I have looked almost everywhere online. There is no phone number that takes you to a support agent - PLEASE HELP........
[URGENT] Sole Global Admin MFA Lockout - No escalation after 7 days (Ticket #2609050040000232)
Hello, I'm dealing with a critical "Sole Global Administrator MFA Lockout" scenario for one week now, and standard ticket support is taking 24h per reply with no effective escalation so far. Ps: I had to use my personnel account to login because my business account is unavailable!! PROBLEM SUMMARY: After switching phones, the only registered MFA method (Microsoft Authenticator) became orphaned. There's no MFA backup method and no working second admin account on the tenant. As a result, I'm locked out of: - Microsoft 365 Admin Center login - Microsoft Entra Admin Center login - Corporate email and Teams access WHAT I'VE ALREADY TRIED (unsuccessfully): - Deleting the broken MFA method (error: "delete operation failed") - Enabling and generating a Temporary Access Pass (blocked - admins cannot generate a TAP for themselves, and the second admin account is also affected by the same broken MFA issue) - Checking for account lockout status (not the case) - Error received during sign-in attempts: Error Code 500121 OPEN TICKET: Ticket #2609050040000232, open for 5 days now, only generic responses received so far. REQUEST: Could someone from the Microsoft team (moderator, MVP, or any direct contact) help escalate this to the Tenant Recovery / Data Protection team? I'm available to prove tenant ownership (domain control, subscription details, billing information). Any guidance on how to expedite this specific type of case would be greatly appreciated. Thank you.
Microsoft values a hacker's disposable email more than your email linked to Microsoft for 8 years
My Pc was compromised and my session tokens were stolen . I had security info connected with my email and phone number . I also had passkey setup on both my pc (after reset) and my phone . It took one click for the hacker to remove the security features . They setup their own security info and added a disposable email instead of mine . I was somehow able to log in to the account using my pc passkey , as it was already signed in . First I requested to change the hacker's email to my one , which was useless cause the wait time period was 30 days . But in doing so I locked myself out of recovering the account with the mail that notified me that my security info was changed . I went to account recovery which only allowed me to change the password not the email so its still connected to the hacker's email . My frustration is the hacker can 1 click change my forever linked email since accounts creation . But when i try to do so they prevents me to do that stating that "there was recent security information change and the account will not allow for additional change for 30 years" . I opened up "account recovery form" and filled it out , point to be noted there were no fields where I could enter my details of my problem they just ask some basic information . After sometime they send a mail stating provided information is not enough . How am i suppose to provide more information if there are no fields for additional information . I contacted Microsoft agent , they guided me to reply to the account recovery form mail which did not worked as I was not allowed to reply on such email . I contacted Microsoft agent again , this time they told me I will be getting an email with account recovery form and I should mention every details . Well it was the same recovery form I used earlier with limited fields . I still field out the form and after sometime I was mailed by mailto:email address removed for privacy reasons to provide additional details for my identify , I was again requested to submit an account recovery form on https://account.live.com/acsr?cs=1 which was the same link with limited fields to provide information . I proceeded but in the end I was told that I have reached the daily limit for submitting form for this account . Just to be sure I mailed mailto:email address removed for privacy reasons the requested details .
Guest accounts and MFA via Conditional Access in MS Entra
Hi experts, trying to get some help on my scenario and issue that external users started to experience since I've enabled MFA for external identities & guest users via Conditional Access. We have lots of external partners that we share some documentation with from our SharePoint. Some time ago, I have enabled "MS Entra B2B Integration for SharePoint and OneDrive" so that any external user that access shared files/folders in our SharePoint gets a GUEST account created in our tenant. This was also preparation for enabling MFA for External users via Conditional Access. I believe these are called "B2B Collaboration guests" Now, few days ago, I have enabled MFA via Conditional Access for all external users and guests, enabled for all cloud apps and require MFA to grant access. Until now, I got feedback from two external partners that their existing access doesnt work anymore - and they need to go through MFA (which is expected). The problem is that when they go through MFA set up, it ends up in a "loop" - meaning, they go through all steps but when completing the last step they are returned back to the very 1st step again. So they: scan QR code successfully authenticate get the page that it was successful get back to the 1st step asking to install or use MS Auth app The user tried different browsers also with Incognito tabs... When I am checking sing-in logs: guest account is created fine the status is: "Interrupted" additional details: The user was presented options to provide contact options so that they can do MFA. conditional access forcing MFA is marked as FAILED as MFA was not completed Both external partners that reported this are using MS Entra and I see their IDENTITY as ExternalAzureAD. Have not heard back from anyone else using other than ExternalAzureAD so not sure if there is something extra that needs to be configured. Anyone experienced this issue? Any idea what can be wrong? I do not have any cross-tenant collaboration etc configured...Trapped in an Authenticator Loop
Dear Community, please help! I am trapped in an Authenticator Loop. I've got a microsoft workplace account, but if I want to log in, I have to type in a code from the microsoft authenticator app. I downloaded the app, but in order to use it, I have to log into my account and in order to do so, I also have to type in a code from the authenticator app, which I don't get, because to get the code I would have to log into the authenticator app, what I would need a code for... No matter which link I click, I can't open anything before I enter the code, which I can't get. I am using teams on mac, either on a firefox browser or on the desktop app and the authenticator on an Iphone. Please don't just tell me "don't use teams on a mac", this wasn't my choice. Unfortunately, my emplyer's IT support also is chronically unavailable. So is here anyone who could help me? I've already gone through the usual deleting the app, using another browser etc. options. Best LukasHow much of your Microsoft 365 environment can you actually see at once?
Not how many users you have. Not how many sites, teams, apps or flows you have. How much of it can you actually see connected together? I've been working across Microsoft 365 environments for a while, and I kept running into the same thing. There is no shortage of information. If anything, there is probably too much of it. Users, groups, permissions, SharePoint, Teams, Power Apps, Power Automate, Power BI, Dataverse, OneDrive, Exchange, Intune, licensing, configuration... It's all there. But when you're actually trying to understand how everything fits together, it can be a different story. You open one blade. Find something. Open another. Cross-check it. Go back. Open something else. Before long, you're jumping between different parts of the tenant trying to build the bigger picture in your head. And if you're working with larger environments, that gets difficult pretty quickly. The information isn't necessarily missing. The relationships between the information are what can be difficult to see. That got me thinking about a slightly different question: Instead of "where do I find this information?" "Show me what's connected to this." That's where VisibleState started. Start anywhere. Follow the connections. Imagine starting with a single user. Instead of seeing that user simply as a record with a list of properties, imagine being able to explore the relationships around them: User → Groups → SharePoint → Teams → Power Apps → Power Automate → Power BI → Dataverse → OneDrive → Exchange → Intune Then the questions become different: What does this user have access to? Is that access direct or coming through a group? What resources are connected to them? What depends on something they're associated with? Which licenses are involved? Are there relationships that look unusual? If something changes, what else might be affected? Those questions aren't necessarily about finding another piece of information. They're about putting information that already exists into context. A report can tell you that something exists. A connected view helps you understand what it is connected to. Illustrative example below — not a real customer environment. I'm not suggesting Microsoft 365 doesn't already give us this information Quite the opposite. Microsoft 365 already gives administrators an incredible amount of information and tooling. The thing I've been thinking about is what happens when you want to look across those boundaries. Sometimes I don't want another export. I don't want another list. I don't necessarily want another dashboard. I want to start with something I'm looking at and ask: "What's connected to this?" And then keep following the trail. That's the idea I'm exploring with VisibleState. The interesting part is what happens when you change the viewpoint The same relationships can be useful for completely different reasons. For example: Administrators may want to understand access, permissions and dependencies. Security and governance teams may want to find unusual relationships or exceptions. Compliance teams may need to understand who can access something and why. People managing multiple environments may want a consistent way to understand what's there without rebuilding the picture manually every time. Leadership may not need to see the graph at all. They may simply want to know what's important, what's exposed and what could be affected. It's still the same underlying environment. You're just looking at it from a different angle. And that's where I think things get interesting. Where I'm at with it VisibleState started as something I was building to make my own work easier. I was spending a lot of time investigating environments, tracing access and putting information together for reports. The individual tasks weren't necessarily difficult. It was the jumping between different places and reconstructing the bigger picture that took the time. So I started building something that would let me approach the environment through the relationships instead. It's grown quite a bit from where it started, and I'm continuing to build it. I'm not posting this as a product launch, and I'm not looking for people to sign up. I'm genuinely interested in whether the problem I'm seeing is familiar to other people working with Microsoft 365. So I'm curious... If you could start with any object in your Microsoft 365 environment and immediately see what it's connected to, where would you start? Would it be: Users and access Groups and permissions SharePoint and Teams Power Apps, Power Automate, Power BI and Dataverse Licensing and resources Governance and unusual relationships Something completely different Maybe you've already got a good way of doing this. Maybe you still find yourself jumping between different services and piecing things together manually. Or maybe I'm looking at the problem from the wrong direction. What's the one relationship in your Microsoft 365 environment that you wish you could see instantly?Lessons Learned #552:10 Lines in an SSMS MSAL Trace That Tell You Almost Everything You Need to Know
In one of our support cases, a customer reported higher-than-expected connection times when connecting from SQL Server Management Studio (SSMS) to Azure SQL Database using Microsoft Entra authentication. The behavior was also not completely consistent. Sometimes the connection required interaction with the account selection experience. Other times, subsequent connections were noticeably faster. At first, there were several possible areas to investigate: Was Azure SQL taking too long to authenticate the user? Was there a networking, proxy, or firewall issue? Was access to login.microsoftonline.com being delayed or denied? Was Microsoft Entra authentication itself taking the time? Was Conditional Access or MFA involved? Was SSMS using the expected Microsoft Entra account? Was the delay happening before or after the access token was obtained? The important question became: Where exactly was the connection time being spent? Instead of treating the SSMS connection as a single operation, I enabled verbose MSAL tracing in SSMS and started following the authentication process. SSMS exposes the MSAL Output Window Trace Level under Tools → Options → Azure Services. The same options page exposes the Microsoft Entra authority, Azure SQL Database service principal name, and Web Account Manager settings. The resulting trace was large—hundreds of lines. But while analyzing it, I realized something useful: I didn't need to understand every line in the MSAL trace. A small number of search strings were enough to reconstruct almost the entire authentication story. These are the 10 things I learned to look for. 1. CorrelationId — First, make sure I am following the same authentication request One of the first things I learned was not to read the trace only by timestamp. MSAL performs several related operations: GetAccounts. AcquireTokenSilent. ReadAccountById AcquireTokenInteractive Broker operations Token cache operations Some can happen almost at the same time, and they don't necessarily share the same correlation ID. For example, in one reproduction, the silent authentication attempt had one correlation ID, while the subsequent interactive request used another one. So my first search became: CorrelationId I learned not to calculate latency by simply subtracting two nearby timestamps. First I identify: Operation + CorrelationId + Start / End and only then interpret the timing. This becomes particularly valuable if the logs later need to be correlated with identity-service investigations. MSAL exposes the correlation ID specifically to piece together an authentication flow. 2. ApiId — Was SSMS trying silent or interactive authentication? My second search became: ApiId In the first connection attempt I found: ApiId - AcquireTokenSilent That immediately told me that SSMS was not initially trying to display an authentication UI. It first attempted to obtain the token silently. But later in the same reproduction I found: ApiId - AcquireTokenInteractive Now the flow was becoming clearer: SSMS ->AcquireTokenSilent -> Silent authentication cannot continue -> AcquireTokenInteractive This was my first important lesson from the case: An SSMS Microsoft Entra connection isn't necessarily interactive from the beginning. MSAL can first try silent authentication and only switch to an interactive mechanism if necessary. Microsoft documents MsalUiRequiredException precisely for situations in which a non-interactive acquisition cannot continue without user interaction—for example because sign-in, MFA, consent, or another requirement must be satisfied. 3. Authority — Where was the authentication request actually going? The next thing I wanted to know was whether the delay could be associated with reaching Microsoft Entra. I searched for: Authority - The trace showed: Authority - https://login.microsoftonline.com/<tenant-id>/ This single line gives us two very important pieces of information: https://login.microsoftonline.com/ -> Microsoft Entra tenant -> Identity authority That means that before blaming Azure SQL, I can establish which identity endpoint SSMS/MSAL is using. This is also where a frequently reported problem such as: "It looks like access to login.microsoftonline.com is denied." can be investigated much more precisely. If I see something such as: MsalServiceException StatusCode: 403 AADSTS.... then I need to inspect the Microsoft Entra response and its error code. If I see a DNS, TLS, proxy, connection timeout, or similar exception, the network path to the identity endpoint becomes much more relevant. Those are very different problems. MSAL distinguishes client/library errors (MsalClientException), token-provider/service responses (MsalServiceException), and scenarios requiring interaction (MsalUiRequiredException). Network failures that MSAL doesn't handle are propagated to the application. One thing I would not conclude from a 403 alone is: "The firewall is blocking login.microsoftonline.com." The ErrorCode, AADSTS code, StatusCode, and ResponseBody together are much more useful than the HTTP status alone. 4. Scopes — Which resource was SSMS requesting the token for? Another line that became essential was: Scopes - Our trace showed: Scopes - https://database.windows.net//.default This helped me separate two parts of the connection that are easy to mix together: Microsoft Entra Authority login.microsoftonline.com -> issues / obtains identity token Token requested for database.windows.net -> Azure SQL The Authority tells me where authentication is being performed. The scope tells me for which resource the token is being requested. SSMS documents https://database.windows.net/ as the Azure SQL Database service principal name used when obtaining a Microsoft Entra token. That gave me another troubleshooting rule: Don't treat a Microsoft Entra token acquisition problem and an Azure SQL authorization problem as the same thing. 5. LoginHint — What identity did SSMS suggest? The next search gave us one of the most interesting findings of the investigation: LoginHint In one reproduction we had: LoginHint provided: True and later: LoginHint - user@contoso.com In another reproduction, a different login hint was supplied, and MSAL eventually returned: MsalUiRequiredException ErrorCode: no_account_for_login_hint with the explanation that no account in the token cache matched that login hint. At first sight, it is tempting to interpret: no_account_for_login_hint as: Incorrect username But the other traces showed me that this interpretation is too simplistic. LoginHint is better understood as: "Try to locate or preselect this identity" It doesn't necessarily mean: "This is already the resolved MSAL account" . That distinction turned out to be very important. 6. Account provided and GetAllAccounts — LoginHint and Account are not the same thing This became perhaps my favorite finding from the investigation. I started searching for: GetAllAccounts and: Account provided In one trace we had: GetAllAccounts ... found 1 accounts but: LoginHint provided: True Account provided: false MSAL nevertheless ended with: no_account_for_login_hint This originally looked contradictory. There was an account in the cache, but MSAL said there was no account for the login hint. It isn't contradictory. What I learned was: An account exists ≠ An account matching this LoginHint exists Then I captured another scenario: LoginHint provided: False Account provided: Account username: user@contoso.com Now SSMS/MSAL wasn't trying to resolve a textual login hint. It already had a concrete account. I started thinking of the two cases like this: LoginHint -> "Try this identity" Account provided -> "Use this resolved identity" This distinction can be especially useful when investigating aliases, UPNs, multiple Windows accounts, cached identities, or cross-tenant accounts. The same error can also have another explanation Another reproduction made the lesson even clearer. This time the trace started with: GetAllAccounts ... found 0 accounts Found 0 RTs and 0 accounts SSMS attempted: LoginHint provided: True Account provided: false and again received: ErrorCode: no_account_for_login_hint But this time the UPN itself was valid. The cache simply contained no suitable account. So another important lesson was: Never diagnose no_account_for_login_hint from the error text alone. Check GetAllAccounts, LoginHint, and Account provided together. 7. ErrorCode, AADSTS, StatusCode — The error tells me where to investigate next At this point I realized that one of the fastest troubleshooting searches was simply: ErrorCode together with: AADSTS StatusCode ResponseBody MsalUiRequiredException MsalServiceException MsalClientException For example: MsalUiRequiredException ErrorCode: no_account_for_login_hint immediately tells me that I am still dealing with token acquisition/account resolution. I haven't reached the point where Azure SQL database permissions would explain this particular failure. This became my mental decision table: Evidence in the trace Where I would investigate first no_account_for_login_hint LoginHint / cached account / account resolution MsalUiRequiredException Why silent authentication requires interaction authentication_canceled Interactive UI / broker / user cancellation AADSTSxxxxx Microsoft Entra authentication or policy MsalServiceException Token provider/service response MsalClientException Client/library/device side DNS/TLS/proxy exception Connectivity to identity service Access token obtained successfully Move the investigation beyond token acquisition 8. Broker, WAM, authorization_type — Who was really authenticating me? This was another part that changed how I read SSMS authentication traces. I searched for: Broker WAM RuntimeBroker auth_flow authorization_type and found: Broker is configured followed by: Using Windows account picker and: Calling SignInInteractivelyAsync The telemetry then reported: auth_flow: Broker authorization_type: Interactive So the authentication path was more accurately represented as: SSMS -> MSAL -> Windows Web Account Manager -> Account / authentication broker -> Microsoft Entra WAM is a Windows component that MSAL can use as an authentication broker. It can integrate with accounts already known to Windows and provide SSO and account-selection capabilities. But another trace showed: authorization_type: WindowsIntegratedAuth during a silent acquisition. That taught me something else: The same SSMS connection target does not necessarily follow the same identity path every time. Account state, cache state, WAM, tenant, identity configuration, MFA, Conditional Access, and whether interaction is required can all affect the path. 9. AccessToken returned — This is the line that changes the investigation Eventually, I found the line that I consider one of the most useful in the entire trace: AccessToken returned: True In our successful authentication we also had: AccessToken Type: Bearer and later: === Token Acquisition finished successfully source: Broker This became a very useful troubleshooting boundary for me: Identity troubleshooting: Account LoginHint MSAL WAM MFA / CA Authority Token acquisition -> AccessToken returned: True -> Azure SQL Token validation Principal resolution Database authentication Authorization Permissions If the token has been successfully obtained, asking: "Why can't MSAL authenticate?" is probably no longer the most useful question. Now I want to know: "What happens when this token is presented to Azure SQL?" That doesn't prove that the complete SQL connection will succeed, but it gives us a very useful point at which to change troubleshooting direction. 10. DurationTotalInMs — Finally, I could see where the connection time was going This was the original reason for the support investigation. The customer reported high connection times. So eventually the most important searches became: DurationTotalInMs DurationInHttpInMs DurationInCacheInMs request_duration time_in_queue_ms Microsoft defines DurationTotalInMs as the total time spent by MSAL acquiring a token, including network and cache operations. DurationInHttpInMs represents time spent in HTTP calls made by MSAL to the identity provider, and DurationInCacheInMs measures cache activity. And now we finally had evidence from our reproduction. The first token acquisition reported: DurationTotalInMs: 2185 DurationInCacheInMs: 0 DurationInHttpInMs: 0 But the broker telemetry contained another very interesting metric: time_in_queue_ms: 2152 and request_duration: 2183 That changed the quality of the diagnosis completely. Instead of saying: "SSMS authentication seems to take around two seconds." I could say: The captured token acquisition took approximately 2.18 seconds, and approximately 2.15 seconds were represented as broker queue time in the MSAL/WAM telemetry. That is actionable evidence. Putting the 10 searches together By the end of the investigation, this became the sequence I would use when somebody sends me an SSMS MSAL trace: Search for What I want to know CorrelationId Am I following the same authentication operation? ApiId Silent or interactive token acquisition? Authority Which Microsoft Entra endpoint and tenant? Scopes Which resource is the token intended for? LoginHint Which identity did SSMS suggest? Account provided / GetAllAccounts Is an identity already resolved or cached? ErrorCode / AADSTS Why did the authentication step fail? Broker / WAM / authorization_type Which authentication mechanism actually handled the request? AccessToken returned / source: Was a usable token obtained, and from where? DurationTotalInMs and related metrics Where was the authentication time spent? With those ten searches, a trace containing hundreds of lines becomes much easier to read. Appendix – Sanitized MSAL Trace Sample The following extract is a sanitized and condensed version of the MSAL trace used in this investigation. User names, tenant IDs, correlation IDs, account identifiers, and other PII have been replaced with placeholders. The goal is to provide a practical sample where you can apply the 10 searches described in this article. First connection ==== GetAccounts started ==== GetAllAccounts ... found 0 accounts Found 0 RTs and 0 accounts in MSAL cache === AcquireTokenSilent Parameters === LoginHint provided: True Account provided: false Authority - https://login.microsoftonline.com/<tenant-id>/ Scopes - https://database.windows.net//.default ApiId - AcquireTokenSilent CorrelationId - <correlation-id-1> === Token Acquisition (SilentRequest) started === MsalUiRequiredException ErrorCode: no_account_for_login_hint No account was found in the token cache having this login hint. MSAL then moved to interactive authentication: === InteractiveParameters Data === LoginHint provided: True Prompt: select_account Authority - https://login.microsoftonline.com/<tenant-id>/ Scopes - https://database.windows.net//.default ApiId - AcquireTokenInteractive LoginHint - user@contoso.com CorrelationId - <correlation-id-2> Broker is configured Using Windows account picker Calling SignInInteractivelyAsync The broker successfully obtained the token: auth_flow: Broker authorization_type: Interactive time_in_queue_ms: 2152 request_duration: 2183 WAM response status success Successfully retrieved token AccessToken returned: True AccessToken Type: Bearer === Token Acquisition finished successfully === source: Broker DurationTotalInMs: 2185 DurationInCacheInMs: 0 DurationInHttpInMs: 0 Second connection A few seconds later, the account was already available: GetAllAccounts ... found 1 accounts Returning 1 accounts === AcquireTokenSilent Parameters === LoginHint provided: False Account provided: Account username: user@contoso.com Authority - https://login.microsoftonline.com/<tenant-id>/ Scopes - https://database.windows.net//.default ApiId - AcquireTokenSilent CorrelationId - <correlation-id-3> This time the broker completed the request silently: Acquiring token silently authorization_type: WindowsIntegratedAuth auth_flow: AT request_duration: 2 WAM response status success Successfully retrieved token AccessToken returned: True === Token Acquisition finished successfully === source: Broker DurationTotalInMs: 13 DurationInCacheInMs: 0 DurationInHttpInMs: 0 What changed? First connection No account → LoginHint → AcquireTokenSilent → no_account_for_login_hint → Interactive / WAM → Token → 2185 ms Second connection Resolved Account → AcquireTokenSilent → WAM → Token → 13 ms These extracts contain the main strings I now look for when reviewing an SSMS MSAL trace: CorrelationId ApiId Authority Scopes LoginHint Account provided / GetAllAccounts ErrorCode / AADSTS Broker / WAM AccessToken returned DurationTotalInMs
