Troubleshoot user name issues that occur for federated users when they sign in to Office 365, Azure, or Intune

To resolve this issue, make sure that the user account is piloted correctly as an SSO-enabled user ID. To do this, use one or more of the following methods:

Method 1: See Knowledge Base article 2615736 if users are receiving the "Sorry, but we're having trouble signing you in" error

If the user receives a "Sorry, but we're having trouble signing you in" error message, use the following Microsoft Knowledge Base article to troubleshoot the issue:

Method 2: Update the UPN of the on-premises user account to use the federated domain as its suffix

Warning Changing the UPN of an Active Directory user account can have a significant effect on the on-premises Active Directory functionality for the user. We recommend that you use caution and deliberation about UPN changes.

The effect potentially includes the following:

• Remote access to on-premises resources by roaming users who log on to the operating system by using cached credentials
• Remote access authentication technologies by using user certificates
• Encryption technologies that are based on user certificates such as Secure MIME (SMIME), information rights management (IRM) technologies, and the Encrypting File System (EFS) feature of NTFS
• Smart-card functionality

We strongly recommend that you pilot a single user account to have a better understanding on how updating the UPN affects user access. The info is useful to plan ahead or lessen certificate reissuance, data recovery, and any other remediation that's required to maintain accessibility to data by using these technologies.

You must update the user account UPN to reflect the federated domain suffix both in the on-premises Active Directory environment and in Azure AD. To do this, follow these steps:

1. Make sure that the federated domain is added as a UPN suffix:
   1. On the on-premises Active Directory domain controller, click Start, point to All Programs, click Administrative Tools, and then click Active Directory Domains and Trusts.
   2. Right-click the root node of Active Directory Domains and Trusts, select Properties, and then make sure that the domain name that's used for SSO is present.
   Note A non-routable domain suffix, such as domain.internal, or the domain.microsoftonline.com domain can't take advantage of SSO functionality or federated services. A non-routable domain suffix must not be used in this step.
2. Manually update the UPN suffix of the problem user account:
   1. On the on-premises Active Directory domain controller, click Start, point to All Programs, click Administrative Tools, and then click Active Directory Users and Computers.
   2. Locate the problem user account, right-click the account, and then click Properties.
   3. On the Account tab, use the drop-down list in the upper-left corner to change the UPN suffix to the custom domain, and then click OK.

Method 3: Make sure that the user ID and the primary Simple Mail Transfer Protocol (SMTP) address of the Exchange Online mailbox have the same domain

Use on-premises Exchange management tools to set the on-premises user's primary SMTP address to the same domain of the UPN attribute that's described in Method 2. For more information, go to the following Microsoft TechNet websites:If Exchange isn't installed in the on-premises environment, you can manage the SMTP address value by using Active Directory Users and Computers. To do this, follow these steps:

1. In Active Directory Users and Computers, right-click the user object, and then click Properties.
2. On the General tab, update the E-Mail field, and then click OK.