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