Troubleshoot Active Directory user accounts that are piloted as Office 365 SSO-enabled user IDs

When you pilot Active Directory user accounts as Office 365 single sign-on (SSO)-enabled user IDs by using the steps in the "How to pilot single sign-on in a production user forest" article on the Office 365 Community website, a newly SSO-enabled user can't access Office 365 resources. The user experiences one of the following symptoms:

• After the user enters their user ID on the login.microsoftonline.com webpage, the user ID can't be identified as a federated user by home realm discovery, and a Sign in at <DomainName> link isn't displayed on the page as expected. The following screen shots show an example of expected behavior and of problem behavior.
  Collapse this tableExpand this table

  Expected behavior	Problem behavior
  Collapse this imageExpand this image	Collapse this imageExpand this image

  Note Sometimes, a delay may occur that doesn't represent a problem. Make sure that the Sign in at <DomainName> link isn't displayed and that the user is experiencing this issue. To do this, after the user enters their user ID, the user should press the Tab key and then wait five seconds.
• Authentication to Active Directory Federation Services (AD FS) 2.0 fails, and the user receives the following forms-based authentication error message:
  The user name or password is incorrect
  Collapse this imageExpand this image

  
• The user receives the following error message on the login.microsoftonline.com webpage
  Your organization could not sign you in to this service
  Collapse this imageExpand this image

  
  
  
  Note When you follow the steps in the following Microsoft Knowledge Base article to identify the Windows Azure AD authentication system error code, you find that the error code that was generated during the user's sign-in attempt is "8004786C":
  2615736

  (http://support.microsoft.com/kb/2615736/ )

  Error message from login.microsoftonline.com when a user tries to sign in to Office 365

These symptoms may occur because of a badly piloted SSO-enabled user ID. The general requirements for piloting an SSO-enabled user ID are as follows:

• The on-premises Active Directory user account should use the federated domain name as the user principal name (UPN) suffix.
• The user ID and the primary email address for the associated Microsoft Exchange Online mailbox do not share the same domain suffix.
• The Windows Azure Active Directory Sync Tool must sync the on-premises Active Directory user account to a cloud-based user ID.
• The UPN of the on-premises Active Directory user account and the Office 365 user ID must match.

Before you assume that a badly piloted SSO-enabled user ID is the cause of this issue, make sure that the following conditions are true:

• The user isn't experiencing a common sign-in issue. For more info about how to troubleshoot common sign-in issues, see the following Microsoft Knowledge Base article:
  2412085

  (2412085)

   You can't sign in to Office 365
   
• The federated domain is prepared correctly to support SSO as follows:
  • The federated domain is publicly resolvable by DNS. (This doesn't include the default "onmicrosoft.com" domain.)
  • The federated domain was prepared for SSO according to the following Microsoft websites.
    • Single sign-on: Roadmap
      (http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh125004.aspx)
    • Set up a trust by adding or converting a domain for single sign-on
      (http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx#BKMK_CreateOrConvertADomain)
    Note Domain federation conversion can take some time to propagate throughout the Office 365 environment. You should wait two hours after you federate a domain before you assume that the domain configuration is faulty.

To resolve this issue, make sure that the user account is piloted correctly as an Office 365 SSO-enabled user ID. To do this, follow these steps:

Step 1: 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 Windows 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.

Step 2: 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 is described in step 1. 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.

Step 3: Set up Active Directory synchronization for the user account UPN

To make SSO work correctly, you must set up Active Directory synchronization client. For more info about how to set up Active Directory synchronization, go to the following Microsoft website:For more info about how to force and verify synchronization, go to the following Microsoft websites:

• Force directory synchronization
  (http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652557.aspx#BKMK_SynchronizeDirectories)
• Verify directory synchronization
  (http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652541.aspx)

Step 4: Troubleshoot UPN update problems for a specific user account

If the synchronization can be verified but the UPN of a piloted user ID is still not updated, the sync problem may occur for the specific user.

For more info about how to troubleshoot potential problems with syncing a specific Active Directory object, see the following Microsoft Knowledge Base article:

Video: Office 365: Managing User Accounts for Identity Federation

uuid=b977ebd0-706c-4c4e-9cfd-419c0634575d VideoUrl=http://aka.ms/mid5od