By using AWS re:Post, you agree to the Terms of Use

Unable to launch Appstream instances. login attempts fail

1

We have a number of fleets already set up and those are working fine but one of the newer fleets that I have created has an issue when new users try to launch and log into Appstream instances that belong to the said fleet. The password that is used is correct but they sometimes get an incorrect password error and then it pops up "An unknown error occurred (1909)". The strange part about it all is that I encountered a similar problem when I first launched and logged in to an instance on the fleet. It took about four or five attempts before it worked. Since that successful sign in, I only encounter the above error occasionally but it works most of the time. Unfortunately, the same doesn't seem to be happening for the newer users that have been assigned access to it.

So my questions are, why is this happening in the first place and why is it allowing few users that have signed in previously but none of the new users?

FYI, we use Okta as our identity provider.

Any advice you may be able to provide would be most appreciated.

Thanks and regards, Diem

  • Update: To try and reach the bottom of this issue, we tried using an older 2012 server image with the fleet and that seems to be working alright. It seems that there is a problem with the way the new images have been created that is causing this issue. Could it be that we are using a domain user as a template user for the image that might be causing this? I used my own domain account as the template user and I find that I can log in after maybe two or three attempts but most new users that attempt to log in fail to do so.

2 Answers
1

Hi Diem -

The error codes that you see on the password prompt from AppStream 2.0 are coming directly from Active Directory. According to Microsoft's documentation, error code 1909 refers to "The referenced account is currently locked out and may not be logged on to."

Since Okta and Active Directory can be their own independent information sources, it's possible for a user to login to Okta successfully but fail on the Active Directory login. Can you validate the users Active Directory object to confirm it isn't locked? Since you mentioned taking multiple attempts before it succeeds, one or more of your domain controllers might not be synched, which could be what's causing the issue sporadically instead of consistently. You may need to connect to the individual domain controller(s) to validate.

It's also recommended to set the sites for the AppStream 2.0 IP ranges to the domain controllers that are (ideally) in the same VPC/AZs as the AppStream 2.0 environment - barring this, to the domain controllers with the lowest latency.

Hope this helps.

Murali

EXPERT
answered 6 months ago
  • Thanks for your comment Murali.

    To answer your question, having checked our logs, we can confirm that DCs are properly synced and that the user's account wasn't locked out on any of the servers.

    Appreciate your recommended solution, but it doesn't explain why the other fleets are working normally apart from this one. Besides, the IP address range is already covered in sites and services and they do exist in the same AZ with the domain controller.

  • Strange that somehow Windows is returning the 1909 error code then. Can you try providing the user access to RDP into an AppStream 2.0 instance? You can try doing it to an domain-joined image builder from an EC2 instance. Curious to see if that allows login immediately, or if it's a similar experience for this specific user.

    Also, have you opened a support case? AWS Support would also be able to see the AppStream 2.0 logs for potentially more data.

  • Thanks for your input Murali. Apologies for the late response.

    Coincidentally when I try to start up the image builder that I normally use, I see a notification, namely "DOMAIN_JOIN_INTERNAL_SERVICE_ERROR": The account already exists

    I've created a new Image builder because of the error and we've managed to connect an ordinary user to the instance once we allowed RDP access. They connected using their AD account without any issue on the first go.

    I will try rebuilding the image and if that fails the next step will be to contact AWS Support.

    Really appreciate your feedback on this though.

    Many thanks. Diem

0

Diem,

Is the fleet domain joined? At what stage are you getting this error? Is it at the Okta login page or is it after that? If the user is in Active Directory, you may want to check whether account is locked out or not. I would check the user account status, password policy for Bad password attempts and Account Lockout Duration both at Okta and Active Directory(if you are using AD).

profile picture
answered 6 months ago
  • Thanks for your reply Arun.

    To answer your questions, yes, the fleet is domain joined. This happens past the Okta login page. The URL on the login page is an amazon one so I think it is an Amazon password challenge. This is what it looks like "https://appstream2.eu-west-2.aws.amazon.com/#/streaming?reference=fleet..."

    I've confirmed with a user's account that was used to sign on that no bad password attempts have been registered for it on AD and Okta shows SSO success on Amazon Appstream 2.0, so nothing to indicate that any user error is involved.

    Anything else you can think of regarding why this may be happening? It's weird because, after the first attempt, it doesn't bring up an error. It just presents the password prompt again. Then after a number or attempts, if at all, the 1909 error pops up.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions