Issue: SAML Version mismatch on Entra ID Federated Users

[sgregorioTC]

Is there an existing issue for this?

• I have searched the existing issues and found none that matched mine

Describe the issue

Users that are sourced from a third-party IDP (in this case Okta) are not able to use AAD-Auth to login to the Ubunutu desktop environment. On the login page it says "Sorry. Password Authentication didn't work", in the Entra ID app there is no record of a login attempt, but in Okta it shows a successful login.

A cloud-only user is able to authenticate successfully using the same exact config file.

Steps to reproduce it

• Ubuntu 23.04
• Entra ID federated with Okta
• Okta sourcing profiles and syncing password to Entra ID
• Consistent error for any federated account failing to login

Ubuntu users: System information and logs

libpam_report.txt
libnss_report.txt

Non Ubuntu users: System information and logs

Log files ### Here is a failed auth for a federated user and a successful auth for a cloud-only account

Jan 24 13:12:23 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): aad auth debug enabled
Jan 24 13:12:23 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): PAM AAD DEBUG enabled
Jan 24 13:12:23 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): Loading configuration from /etc/aad.conf
Jan 24 13:12:23 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): Connecting to "https://login.microsoftonline.com/TENANT_ID", with clientID "CLIENT_ID" for user "[email protected]"
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): acquiring token failed: problem getting SAML token info: couldn't parse SAML assertion, version unknown: ""
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): Cache initialization
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): Opening cache in /var/lib/aad/cache
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): check file permissions on /var/lib/aad/cache/shadow.db
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): check file permissions on /var/lib/aad/cache/passwd.db
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): Shadow db mode: 2
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): Cleaning up db. Removing entries that last authenticated online more than 180 days ago
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): try to authenticate "[email protected]" from cache
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): getting user information from cache for "[email protected]"
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): authenticating user "[email protected]" from cache failed: error when getting user "[email protected]" from cache: no entries. Denying access.
Jan 24 13:12:25 LinuxTestMachine gdm-password][2664]: pam_aad(gdm-password:auth): Close database request

Application settings

Please redact/remove sensitive information:
Config file is default, only the tenant id and app id were placed in. homedir set to /home/%u

Relevant information

No response

Double check your logs

• I have redacted any sensitive information from the logs

[zacharyfleck]

Same issue here - Also federated with Okta. I'm trying to see if I can capture the SAML response to make sense of it, but no luck so far.

EDIT: I enabled public client flows for a second and got a mildly different error: acquiring token failed: problem getting SAML token info: unknown WS-Trust version. Doesn't really help solve anything but worth noting I suppose.