Sign-in issues for a web application following windows server migration

The symptoms indicate an authentication problem specific to this application after the move to Windows Server 2022, while the user account and general Microsoft 365 sign-in are healthy. After a server migration, the most common causes are:

1. Application or relying-party configuration no longer matches what Microsoft Entra ID (Azure AD) expects
   • If the app uses federation (AD FS or another STS), verify that the claims configuration and identifiers for the relying party trust are unchanged and still match the app registration.
   • If any claims rules or identifiers were edited during migration, they can cause sign-in failures similar to the federated error scenario where “claims that are set up in the relying party trust with Microsoft Entra ID return unexpected data.”
   • Compare the relying party trust / OpenID Connect or SAML configuration on the new server with the previous configuration (identifiers, endpoints, claims rules, signing certificates).
2. Cached or stale sign-in information on the federation/STS side
   • If the app uses AD FS and any user attributes (such as UPN or SAM account name) or claim rules changed during the migration, stale cached information on the federation server can cause sign-in failures.
   • Restart the AD FS service and ensure that any changes to UPNs or SAM account names are fully synchronized and reflected in the claims rules.
3. Browser and cookie issues after moving to a new host or changing keys
   • If the app or front-end changed encryption keys, auth mode, or host name as part of the migration, existing cookies or tokens in the browser may no longer be valid and can cause generic “We couldn’t sign you in” messages.
   • Clear cookies specifically for the application’s host and any associated authentication hosts (for example, the SSRS guidance notes that “the cookie or token the portal tries to decrypt was encrypted with a different key than the one the portal is using,” and deleting cookies for the host resolves it).
   • Test sign-in from a different browser and a different client machine that has never accessed the old server to rule out cookie/token residue.
4. General account and policy checks Even though Outlook and Teams work, verify the following for the affected users and app:
   • The user account is enabled for sign-ins and not locked out.
   • The password is valid and not expired.
   • Multi-Factor Authentication or Conditional Access policies are not blocking this specific application. For example, a Conditional Access policy that requires a specific sign-in method or device state can block one app while others still work.
   • Authentication contact info is up to date so MFA/Conditional Access can complete successfully.
5. Browser and application prerequisites
   • Confirm the browser used to access the app meets the supported requirements and that the application URL is treated correctly by the browser (for example, added to trusted sites if required by the app’s sign-in flow).
   • If the app uses non-browser components or rich clients as part of the sign-in, ensure all prerequisites on the new server are installed and that any sign-in assistants or libraries are up to date.

Recommended next steps

1. Test from a clean client:
   • Use a different machine and browser that has never accessed the old app.
   • Clear cookies for the app host and sign-in domains, then retry.
2. Validate Entra ID / federation configuration:
   • If using AD FS or another STS, compare relying party trust / app configuration between old and new environments (identifiers, endpoints, claims rules, signing certs).
   • Ensure no manual changes to claims or identifiers were introduced during migration.
3. Check policies and account state:
   • Confirm the user is not blocked by MFA or Conditional Access for this specific app.
   • Verify the account is enabled and not locked out.

If, after these checks, the issue persists, capture the exact error details from the sign-in page (correlation ID, timestamp, and error code if available) and review the sign-in logs in Microsoft Entra ID to see whether the failure occurs on the Entra side (policy/claims) or on the application side (token handling/cookie decryption).

References:

• Troubleshoot application sign-in
• Error 80048163 when a federated user tries to sign in to Microsoft 365, Azure, or Intune
• How to Troubleshoot Common Issues
• Issue with SSRS Reports Portal after migration from 2016 to 2022 - Microsoft Q&A