Why can't I use the WorkSpaces Personal client to authenticate to my WorkSpace?

Resolution

If you encounter the Directory Unavailable error, then see How do I resolve the "Directory Unavailable" error in WorkSpaces?

If you have issues with your SAML 2.0 authentication, then see How do I troubleshoot SAML 2.0 authentication issues in WorkSpaces?

If you can't authenticate into a WorkSpace, then you might receive the error, "Authentication Failed: Please check your username and password to make sure you typed them correctly." Configuration issues in AWS Directory Service for Microsoft Active Directory or Simple AD can cause the Authentication Failed error, even when you use the correct credentials. To resolve this issue, take the following actions.

Confirm that the directory registration code in the WorkSpaces Personal client matches the value that's associated with the WorkSpace

Complete the following steps:

1. Open the WorkSpaces client.
2. Choose Settings, and then choose Manage Login Information.
3. Note the registration code.
   Note: If you have multiple registration codes, then choose Change Registration Code to find the last registration code that you used.
4. Open the WorkSpaces console.
5. Select your WorkSpace, and then choose View Details.
6. Under Summary, verify that the value for Registration Code matches the code that you noted.

Verify your credentials

For Windows WorkSpaces, use Remote Desktop Protocol (RDP) to connect to your WorkSpace. For Linux WorkSpaces, use SSH to connect to your WorkSpace. Enter your credentials, and check the error code details.

If you receive the Make sure you're entering the correct username and password or Ensure the account isn't locked out errors, then the credentials are incorrect. Reset the password, or unlock the account in your Microsoft Active Directory. For information about how to unlock a Microsoft Active Directory account, see Unlock-ADAccount on the Microsoft website.

If you receive a The trust relationship between this workstation and the primary domain failed error, then troubleshoot domain join issues. If the trust with the Active Directory is broken, then you must restore and then rebuild the WorkSpace.

If you use a Windows Workspace and receive a Network Level Authentication (NLA) error, then see Why do I get an NLA error when I use RDP to connect to WorkSpaces?

Check your Active Directory user account configuration

Complete the following steps:

1. Check that Kerberos pre-authentication is turned on.
2. Ask your WorkSpaces administrator to clear User must change password on next logon under your user properties in Active Directory Users and Computers.
3. To confirm that your password isn't expired, use an admin machine that's joined to the domain to run the following command:

   net user username/domain

   Note: Replace username with your username.
4. To reset the password, open the WorkSpaces client and then choose Forgot Password?.
   Note: You can use Forgot Password? only if you use Simple AD or AWS Managed Microsoft AD.

Verify that the sAMAccountName attribute in the user account didn't change

If you change the username of an Active Directory user, then the usernames in WorkSpaces and Active Directory don't match and authentication fails. If you changed the sAMAccountName value, then return it to the original username.

If you must rename a user, then complete the following steps:

1. Back up files from the user volume to an external location, such as Amazon FSx.
2. Delete the WorkSpace.
   Important: You can't roll back WorkSpace deletion. When you delete a WorkSpace, the user's data is no longer available.
3. Modify the username attribute.
4. Create a new WorkSpace for the user.

If you deleted the Active Directory user and created a new user with same sAMAccountName, then you must create a new WorkSpace for that user.

Verify that the username contains only valid characters

Check that the username uses only valid characters.

If the WorkSpaces username contains characters that aren't valid, then complete the following steps:

1. Back up files from the user volume to an external location, such as Amazon FSx.
2. Delete the WorkSpace.
   Important: You can't roll back WorkSpace deletion. When you delete a WorkSpace, the user's data is no longer available.
3. Use the Active Directory Users and Computers tool to find the user.
4. Open the context (right-click) menu for the user, and then choose Properties.
5. From the Account tab, rename both User logon name and User logon name (pre-Windows 2000).
6. Create a new WorkSpace with the new username.

Verify that the password contains only valid characters

Passwords are case-sensitive and must be between 8 and 64 characters in length. Passwords must contain at least one character from each of the following categories:

• Lowercase characters (a-z)
• Uppercase characters (A-Z)
• Numbers (0-9)
• Non-alphanumeric characters (~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/)

Don't include nonprintable unicode characters, such as white spaces, carriage return tabs, line breaks, and null characters.

Verify that there isn't a time difference of more than 5 minutes across resources

Authentication is sensitive to time differences between the resources that you use with WorkSpaces. The domain controllers in the domain, RADIUS servers, WorkSpace instance, and the service must be in sync.

To make sure that all resources are in sync, take the following actions:

• If the Active Directory is customer managed, then sync each domain controller with an authoritative time source. For more information, see Recommendation - Configure the root PDC with an authoritative time source and avoid a widespread time skew on the Microsoft website.
• Make sure there's no time skew between domain controllers. For information about time skew, see Windows Time service tools and settings on the Microsoft website.
• Check that the replication between domain controllers is working as expected. For more information, see Troubleshooting Active Directory replication problems on the Microsoft website.
• If you use multi-factor authentication (MFA), then check that the clock on all RADIUS servers is synced with a reliable time source. You can use the NTP tool on the NTP Pool Project website.
• If the time on the WorkSpace is inaccurate, then reboot the WorkSpace to synchronize it with an atomic clock. After a few minutes, the WorkSpace also synchronizes with the domain controller.
• Check the time against a reliable time source.
  For a Linux WorkSpace, run the following command:

  ntpdate -q -u pool.ntp.org

  For a Windows WorkSpace, run the following command:

  w32tm.exe /stripchart /computer:pool.ntp.org

Related information

Administer users in WorkSpaces Personal

Troubleshooting AD Connector

Diagnose Active Directory replication failures