Issue: SAML Version mismatch on Entra ID Federated Users
Is there an existing issue for this?
- [X] 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
- [X] I have redacted any sensitive information from the logs
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.