Lets keep the language natural. So far what I understand is, The identity lives in AD and synced with OKTA. The users authenticates with the identity with okta. And Okta issues a SAML assertion back to user, user passes the SAML to aws idp config, and idp verifies the SAML trust establishment and then IdP gives you the assume role session, you get to access appstream fleet. Now my question is what is the need for password now, for AD joined instances?
Correction (important):
Okta does not issue anything to the user.
Okta issues a SAML assertion directly to AWS. The user never “carries” it.
-
Okta ≠ AD authentication replacement
- Okta authenticates the user to AWS/AppStream.
- It does not authenticate the user to AD.
- No Kerberos, no NTLM, no LDAP bind happens via Okta.
-
AppStream sessions are AD-backed
- The fleet is domain joined.
- The session runs under an AD user context.
- AD requires a password-derived secret to issue Kerberos TGTs.
-
How login actually works
- Okta → AWS → AppStream decides who is allowed in.
- AppStream then maps that identity to an existing AD user.
- AppStream logs in the user using AD credentials behind the scenes.
graph TD Flows Step 2 Okta -- "2. SAML Assertion (Federation)" --> AS_Portal Step 4 - CBA Flow WinInstance -- "4a. Request temp Certificate<br>(Machine context)" --> PCA_Conn PCA_Conn -- "4b. Forward Cert Request" --> PrivateCA PrivateCA -- "Issue Certificate" --> PCA_Conn PCA_Conn -- "Return Certificate" --> WinInstance WinInstance -- "4c. Present Certificate for Windows Logon<br>(Kerberos/SmartCard login)" --> AD Legend subgraph Legend direction LR L1(Step-by-Step Flow) --> L2(...) L3["AWS Service"]:::aws L4["Active Directory"]:::onprem L5["AppStream Instance"]:::instance end