Company Portal Login Failures — Day 2 of the Microsoft Intune Real-Time Troubleshooting Series

Day 2 of the Microsoft Intune Real-Time Troubleshooting Series

Welcome to Day 2 of the Microsoft Intune Real-Time Troubleshooting Series — 15 days, 15 real-world scenarios, 15 practical solutions.

Yesterday the devices would not enroll. Today the devices are enrolled — and the users cannot get into the Company Portal at all. That is a different failure, in a different layer: enrollment proved the device can talk to Intune; a login failure means the user’s identity cannot get through. The fix is almost never on the device alone. It lives in the sign-in logs, in the account, in the MFA and Conditional Access policies — and the error code tells you which one.

1. Real-World Scenario

It is Tuesday morning, and the regional sales team is back from a long weekend. On Friday evening, IT rolled out two changes: a Conditional Access policy that now requires multi-factor authentication for the Company Portal app, and a 90-day password expiry wave that landed on the same group.

By 9 a.m., the help desk has 30 tickets, and they do not all look the same:

• Half the team gets “Your account or password is incorrect” — even though they are typing the password they used on Friday.
• A dozen users get stuck in a loop: sign in, a screen that says “More information required,” then back to the sign-in page, again and again.
• Three users approve the MFA prompt on their phone and still get “Request denied.”
• Two laptops show “Company Portal Temporarily Unavailable” and never reach a sign-in screen.
• One user gets “Your IT admin hasn’t given you access to use this app.”
• One user, working from a hotel, gets a bare “Access blocked” message with an error code and no explanation.

The devices are enrolled. The apps are deployed. Nobody can sign in to get them. That is where this troubleshooting starts — and the first rule is: do not re-enroll anything yet. A login failure is an identity problem until proven otherwise.

2. Root Cause Analysis

Company Portal sign-in on Windows goes through the Web Account Manager broker, which hands the user’s credentials to Microsoft Entra ID and caches the resulting tokens — including the Primary Refresh Token (PRT) — on the device. A failure can sit in the credentials, the account, the policy, the token cache, the network, or the app itself. The error code tells you which.

1. The password is wrong — or it expired. The most common cause. After a password change or an expiry wave, cached credentials and muscle memory disagree. Entra logs AADSTS50126 (invalid username or password) or AADSTS50055 (password expired).

2. The account is disabled or locked. A leaver process that ran early, an account disabled during a cleanup, or Smart Lockout after too many failed attempts. Entra logs AADSTS50057 (user account disabled) or AADSTS50053 (account locked).

3. MFA is required but never registered — or never completed. Friday’s policy now demands MFA for Company Portal. Users who never registered a method get AADSTS50079 (MFA enrollment required) and the “More information required” loop. Users who have MFA but deny, ignore, or never receive the prompt get AADSTS50076 (MFA required, not completed) and “Request denied.”

4. Conditional Access blocks the sign-in outright. The policy also requires a compliant device, or a trusted location. A device that has not synced since Friday shows as non-compliant; a user on hotel Wi-Fi trips the location condition. Entra logs AADSTS53003 (access blocked by Conditional Access).

5. The user has no Intune license. During the same cleanup, one user’s Intune license was removed. Company Portal answers with “Your IT admin hasn’t given you access to use this app.” The sign-in itself succeeds — Entra authenticates the user fine — and then the app refuses them.

6. The token cache is broken. The PRT is missing or the broker’s cached tokens are corrupt. dsregcmd /status shows AzureAdPrt : NO, and the app fails with a Web Account Manager error such as 0xCAA2000B (cached sign-in / token failure) or 0x80090016 (a TPM keyset problem, often after a motherboard or TPM change).

7. The network or proxy blocks the sign-in endpoints. A new proxy rule, a VPN, or a captive portal intercepting traffic to login.microsoftonline.com or portal.manage.microsoft.com kills the sign-in before Entra ever sees it. The broker reports 0xCAA70004 (network, proxy, or TLS problem) or 0xCAA70007 (endpoint cannot be resolved or reached). A wrong system clock belongs in the same bucket: tokens are time-sensitive, and a clock off by more than a few minutes fails authentication silently.

8. The app itself is outdated or corrupted. “Company Portal Temporarily Unavailable” is Microsoft’s own diagnosis for this one: the installed app is out of date or damaged. The same message can also mean the user hit the device enrollment limit (DeviceCapReached, default 15 devices per user) — so check the app version and the device count.

9. The wrong account, or the wrong tenant. A user signing in with a personal Microsoft account, or a guest account from another tenant, gets AADSTS50020 (account from the wrong tenant) or AADSTS700016 (application not found in the tenant).

3. Step-by-Step Troubleshooting

Work in this order: read the error, check the logs from the admin side, then touch the device.

1. Read the exact error — and capture the code. Note the full message and any code on screen: AADSTS50126, AADSTS50076, AADSTS53003, 0xCAA70004, or the plain-language message. The codes are precise; the plain-language messages are mapped to causes in Section 2. If the app shows no code, the Entra sign-in log still has it.

2. Check the Entra sign-in logs before touching the device. In the Microsoft Entra admin center, go to Monitoring & reports > Sign-in logs, filter by the affected user’s UPN, and open the failed entry. It shows the exact AADSTS error code, which Conditional Access policies applied and which one blocked the sign-in, plus the IP, location, and device. This single check separates a user problem (50126, 50055), an account problem (50057, 50053), an MFA problem (50076, 50079), and a policy problem (53003).

3. Run dsregcmd /status on the device. Check AzureAdJoined and AzureAdPrt. AzureAdPrt : NO means no valid Primary Refresh Token — the broker cannot sign the user in silently, and every sign-in prompts or fails. That points at cause 6, not the password.

4. Verify the account state — and the license. In the Microsoft 365 admin center, check the user: is the account enabled, is the password expired, is sign-in blocked, and does the user still have an Intune license assigned? Confirm the UPN matches what the user is typing — a UPN changed after a name change, or a typo’d domain, fails as 50126 forever. Smart Lockout clears on its own, or an admin password reset clears it immediately. “Your IT admin hasn’t given you access to use this app” with a clean sign-in log is a license problem, full stop.

5. Check MFA registration and Conditional Access. In Entra ID, open the user’s authentication methods: is at least one MFA method registered, and can the user still reach it? A user whose only method is a decommissioned phone needs a new method or a Temporary Access Pass. Then read the Conditional Access tab on the sign-in log entry: which policy blocked it, and what did it require — MFA, a compliant device, a trusted location? If the policy is the problem, fix the policy, not the device.

6. Test the web portal. Have the user sign in at portal.manage.microsoft.com from a browser. If it works, Entra, the account, MFA, and the policy are all fine — the problem is the Windows app or the device’s token cache. If it fails with the same code, the problem is upstream and no app repair will help.

7. Check the network path and the clock. Confirm connectivity to login.microsoftonline.com and portal.manage.microsoft.com on port 443, and check the proxy — a VPN or a new proxy rule is the usual suspect for 0xCAA70004 / 0xCAA70007. Confirm the system clock is correct; a skewed clock breaks token validation. Try a phone hotspot to rule the office network out in one move.

8. Repair the app, then the token cache. In Settings > Apps > Installed apps > Company Portal, try Repair first, then Reset. If the app is outdated, update it from the Microsoft Store; if corrupt, uninstall and reinstall it. If the PRT is missing (AzureAdPrt : NO), disconnect the work or school account in Settings > Accounts > Access work or school, reboot, and re-add it — that forces a fresh PRT. Only re-enroll if the enrollment itself is gone.

4. PowerShell Commands

Real commands an admin runs on the device or against the tenant. Run device-side ones in an elevated prompt where noted.

# Entra join state and PRT health
dsregcmd /status

# Can the device reach the Entra sign-in endpoint? (run as the user, not just as admin)
Test-NetConnection login.microsoftonline.com -Port 443

# Can the device reach the Company Portal web endpoint?
Test-NetConnection portal.manage.microsoft.com -Port 443

# System clock — a skewed clock breaks token validation
w32tm /query /status

# Installed Company Portal version (outdated builds cause "Temporarily Unavailable")
Get-AppxPackage -Name Microsoft.CompanyPortal | Select-Object Name, Version, InstallLocation

# Recent token-broker events from the Entra operational log
Get-WinEvent -LogName 'Microsoft-Windows-AAD/Operational' -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# Full MDM diagnostic bundle (report lands in C:\Users\Public\Documents\MDMDiagnostics)
mdmdiagnosticstool.exe -area "DeviceEnrollment" -zip "C:\Temp\MDMDiag.zip"

# Admin side: is the account enabled, and when did the password last change?
Connect-MgGraph -Scopes 'User.Read.All'
Get-MgUser -UserId 'ana.perez@contoso.com' | Select-Object UserPrincipalName, AccountEnabled, LastPasswordChangeDateTime

# Admin side: the user's registered MFA methods (an empty result explains AADSTS50079)
Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All'
Get-MgUserAuthenticationMethod -UserId 'ana.perez@contoso.com' | Select-Object '@odata.type', CreatedDateTime

# Admin side: recent failed sign-ins with their AADSTS error codes
Connect-MgGraph -Scopes 'AuditLog.Read.All'
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'ana.perez@contoso.com'" -Top 10 |
    Select-Object CreatedDateTime, Status, @{N='ErrorCode';E={$_.Status.ErrorCode}}, ConditionalAccessStatus

5. Important Log Locations

Location	What it tells you
Entra admin center > Monitoring & reports > Sign-in logs	The source of truth: the exact AADSTS error code, the Conditional Access policies that applied and which one blocked the sign-in, the IP, location, and device. Filter by the user’s UPN; failures only.
Event Viewer > Applications and Services Logs > Microsoft > Windows > AAD > Operational	The Web Account Manager / token broker log on the device. PRT acquisition and token failures land here — the device-side half of a sign-in failure.
Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin	The MDM enrollment log. Event ID 75 = auto-enrollment succeeded; Event ID 76 = failed, with the error code. Relevant when the login failure turns out to be a broken enrollment underneath.
Event Viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin	The Entra join log. Event ID 204 = join started; 304 = join succeeded. If the join is broken, the PRT can never be issued and sign-in fails.
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs	Intune Management Extension logs (IntuneManagementExtension.log, AppWorkload.log, AgentExecutor.log, ClientHealth.log). Each rolls over at 3 MB. Useful when the app or device stops checking in after sign-in.
C:\Users\Public\Documents\MDMDiagnostics	Output of mdmdiagnosticstool.exe and the Settings > Access work or school > Create report bundle, including MDMDiagHtmlReport.html — enrollment state, certificates, and policy status in one readable file.
Intune admin center > Devices > the device > Device diagnostics	Collected remotely with Collect diagnostics — event logs, registry keys, and IME logs uploaded from the device, downloadable as a zip. The device must be online.
Company Portal app > Settings > Send logs	The app’s own diagnostic logs, sent to Microsoft support with the case. Use when the failure is inside the app itself and the other logs show nothing.

6. Practical Resolution

The sign-in logs tell the story. The “wrong password” group shows AADSTS50055: their passwords expired in the Friday wave, and the old password cached on the laptop kept failing. The “More information required” loop shows AADSTS50079: those users never registered an MFA method, and Friday’s policy now requires one. The hotel user shows AADSTS53003: the policy demands a compliant device, and that laptop has not synced since Friday, so Intune still reports it non-compliant. And the two “Temporarily Unavailable” laptops run an old Company Portal build — one of them belonging to a user at the 15-device cap.

The fix, in order:

1. The expired-password group resets their passwords — self-service at the password reset page, or an admin reset for anyone locked out.
2. The MFA group registers a method at their security info page (Microsoft Authenticator, plus a phone number as a backup), then signs in and completes the MFA prompt. For the user whose only method was a decommissioned phone, IT issues a Temporary Access Pass so they can sign in once and register a new method.
3. The hotel user’s laptop syncs from Company Portal > Settings > Sync; once Intune reports it compliant, the policy lets the sign-in through. Nobody changes the policy — it is doing its job.
4. The license cleanup is reversed for the one user who lost Intune.
5. The two broken apps are repaired from Settings > Apps, and one is reinstalled from the Microsoft Store. The user at the device cap has stale device records removed in the Intune admin center.
6. One laptop still shows AzureAdPrt : NO. Its work account is disconnected and re-added, which issues a fresh PRT, and Company Portal signs in cleanly.

By 11 a.m., 29 of 30 tickets are closed. The thirtieth — the one whose 0x80090016 pointed at a TPM keyset problem after a motherboard replacement — goes to the hardware team with the diagnostic bundle attached. No device was re-enrolled. The sign-in logs named every cause before anyone touched a laptop.

7. Interview Questions

Q1: A user cannot sign in to the Company Portal app. What is the first thing you check, and why?

The Entra sign-in logs, filtered by the user’s UPN. The failed entry carries the exact AADSTS error code, which Conditional Access policies applied, and the device and location — it separates a password, account, MFA, and policy problem before you touch the device.

Q2: What is the difference between AADSTS50126, AADSTS50076, and AADSTS53003?

50126 means the credentials are wrong — invalid username or password. 50076 means the credentials are right but MFA is required and was not completed. 53003 means authentication succeeded but Conditional Access blocked the sign-in — the user failed a policy condition such as requiring a compliant device or a trusted location. Three different layers, three different fixes.

Q3: The sign-in log shows AADSTS50079 and the user is stuck in a “More information required” loop. What is happening?

The user has valid credentials and MFA is required, but they have never registered an authentication method — so Entra keeps interrupting the sign-in to demand registration, and there is nothing registered to complete it with. Register a method at the security info page, or issue a Temporary Access Pass so they can sign in once and register.

Q4: dsregcmd /status shows AzureAdPrt : NO. What does that mean for Company Portal sign-in?

The device holds no valid Primary Refresh Token, so the broker cannot silently authenticate the user and every sign-in prompts or fails — even with the right password. It points at the token cache or the Entra join, not the password. Check the AAD Operational log, then disconnect and re-add the work or school account to force a fresh PRT.

Q5: A user gets “Your IT admin hasn’t given you access to use this app” — but they signed in successfully. What is wrong?

The authentication succeeded and the app refused them: the user has no Intune license assigned. Check the license in the Microsoft 365 admin center and assign Intune Plan 1 or a bundle that includes it, such as Microsoft 365 E3/E5. The sign-in log will show a successful sign-in — that is the clue.

Q6: Company Portal says “Temporarily Unavailable.” What are the two very different causes, and how do you tell them apart?

Either the installed app is outdated or corrupted, or the user hit the device enrollment limit (DeviceCapReached, default 15 devices per user). Check the app version with Get-AppxPackage -Name Microsoft.CompanyPortal and the user’s device count in the Intune admin center. An old build gets repaired or reinstalled; a user at the cap gets stale device records removed.

---

Day 2 done. Tomorrow, Day 3: Device Compliance Issues — when the device signs in fine, but Intune says it is not compliant and Conditional Access shuts the door.

Follow the series here on ongoingideas.com — one scenario a day, for 15 days.

Missed the start of the series? Begin with Day 1: Windows Device Not Enrolling into Intune.