Public bug reported: # Bugreport: sssd UPN-login (afwijkend suffix) faalt structureel door race condition tussen Initgroups-refresh en krb5-auth
## Samenvatting Op een domain-joined Ubuntu 26.04 client (SSSD AD-provider) kan een gebruiker niet inloggen via GDM met de UPN-vorm van zijn account (`[email protected]`), terwijl inloggen met de korte AD-naam (`[email protected]`) wel altijd werkt. Het UPN-suffix (`utwente.nl`) wijkt af van de daadwerkelijke Kerberos-realm (`AD.UTWENTE.NL`). Kerberos-authenticatie zelf werkt aantoonbaar correct (handmatige `kinit -E` en een geïsoleerde `krb5_child`-test slagen beide). Het probleem zit in de SSSD-backend: bij (vrijwel) elke UPN-login triggert sssd een verse, live Initgroups-lookup bij AD die race't met de gelijktijdige PAM-authenticatie-aanvraag binnen dezelfde request. Dit resulteert consistent in: ``` [set_initgroups_expire_attribute] Failed to set initgroups expire attribute [krb5_setup] No mapping for: <SAMACCOUNTNAME>@ad.utwente.nl [krb5_auth_send] No attributes for user [<SAMACCOUNTNAME>@ad.utwente.nl] found. [krb5_auth_queue_done] krb5_auth_recv failed with: 2 ``` ## Omgeving - OS: Ubuntu 26.04.1 LTS (codename "resolute") - sssd-versie: 2.12.0 - Domain-join methode: realmd/adcli (standaard Ubuntu domain-join flow) - AD-domein/realm: `ad.utwente.nl` / `AD.UTWENTE.NL` - UPN-suffix (afwijkend van realm): `utwente.nl` - id_provider/auth_provider: `ad` ## Relevante sssd.conf ([domain/ad.utwente.nl]) ```ini [sssd] services = nss, pam domains = ad.utwente.nl [domain/ad.utwente.nl] id_provider = ad auth_provider = ad access_provider = ad chpass_provider = ad ad_domain = ad.utwente.nl krb5_realm = AD.UTWENTE.NL use_fully_qualified_names = False ldap_id_mapping = True ldap_user_principal = userPrincipalName krb5_use_enterprise_principal = True krb5_use_subdomain_realm = True debug_level = 9 ``` ## Stappen om te reproduceren 1. Join een Ubuntu 26.04-client aan een AD-domein waarbij het UPN-suffix van gebruikersaccounts (bv. `utwente.nl`) afwijkt van de daadwerkelijke Kerberos-realm (bv. `AD.UTWENTE.NL`). 2. Configureer sssd zoals hierboven (`krb5_use_enterprise_principal = True`, `krb5_use_subdomain_realm = True`, `ldap_user_principal = userPrincipalName`). 3. Zorg dat de identity-lookup werkt: `getent passwd <upn>` en `id <upn>` resolven correct (bevestigd, zie hieronder). 4. Log in via GDM met de UPN-vorm (`[email protected]`). 5. Authenticatie faalt, ook al is het wachtwoord correct. ## Wat werkt (uitgesloten als oorzaak) - **NSS/identity-resolutie**: `getent passwd`, `id`, en InfoPipe-lookup werken voor zowel de korte naam als de UPN-vorm. ``` sssctl user-checks resultaat: Test nieuwenhuispm UPN-vorm NSS user lookup ✅ ✅ InfoPipe lookup ✅ ✅ pam_authenticate ✅ ❌ pam_acct_mgmt ✅ ❌ ``` - **Kerberos-authenticatie zelf** (los getest, buiten sssd om): ``` $ kinit -E [email protected] Password for [email protected]@AD.UTWENTE.NL: [correct wachtwoord] $ klist [geldig ticket verkregen] ``` - **Een geïsoleerde, succesvolle `krb5_child`-run** (los van de uiteindelijk falende GDM-flow) toont een volledig geslaagde TGT-uitgifte en validatie: ``` [main] krb5_child completed successfully ``` Dus de Kerberos-implementatie an sich, het keytab, en de KDC-communicatie zijn aantoonbaar in orde. - **Cache is warm**: een systemd-oneshot-service die vóór elke boot `getent passwd <upn>` uitvoert, bevestigd succesvol gelopen (cache-entry aanwezig, recent geüpdatet) — maar de login faalt alsnog. - **`case_sensitive = False`** toegevoegd — geen effect; de naam-string in de falende lookup matcht exact (zelfde hoofdlettergebruik) met de zojuist succesvol gecachete entry. - **`ldap_user_principal = nonExistingAttribute`** (workaround uit GitHub issue SSSD/sssd#7092) geprobeerd — verergert het probleem: sssd construeert dan zelf een dubbel-foute principal (`p.m.nieuwenhuis\@[email protected]`). Teruggedraaid. ## Kernbewijs: de race condition Log-fragment uit `/var/log/sssd/sssd_ad.utwente.nl.log`, van een enkele, representatieve mislukte inlogpoging (tijden lopen binnen dezelfde seconde): ``` * [RID#18][sysdb_set_entry_attr] Entry [[email protected],...] has set [ts_cache] attrs. * [RID#18][dp_req_reply_std] DP Request [Initgroups #18]: Returning [Success]: 0,0,Success * [dp_pam_handler_send] Got request: command: SSS_PAM_AUTHENTICATE, user: [email protected], service: gdm-password * [RID#19][krb5_auth_queue_send] Wait queue of user [[email protected]] is empty, running request immediately. * [RID#19][krb5_setup] No mapping for: [email protected] * [RID#19][krb5_auth_send] No attributes for user [[email protected]] found. * [RID#19][krb5_auth_queue_done] krb5_auth_recv failed with: 2 ``` Eerder, tijdens debuggen, ook waargenomen: ``` [set_initgroups_expire_attribute] Failed to set initgroups expire attribute ``` Dit patroon (verse Initgroups-refresh direct gevolgd door een PAM Authenticate-request voor dezelfde gebruiker, die vervolgens de attributen niet kan vinden) trad **consistent op bij elke UPN- inlogpoging**, ook met een reeds warme cache en na een volledige reboot — dus geen eenmalig "cold cache"-effect, maar een structureel patroon specifiek bij UPN-logins met afwijkend suffix. ## Vermoedelijke oorzaak Vermoedelijk triggert de UPN-vorm van de gebruikersnaam (in tegenstelling tot de korte AD-naam) bij elke login een nieuwe live Initgroups-round-trip naar AD in plaats van de bestaande cache te hergebruiken. Dit is mogelijk gerelateerd aan de eerder gefixte races rond `initgrExpireTimestamp` (zie SSSD#2634, SSSD#3744, SSSD#4012), maar dan opnieuw opduikend specifiek in het pad voor enterprise-principal/UPN-canonicalisatie in combinatie met `krb5_use_subdomain_realm`. ## Reeds uitgesloten workarounds - `ldap_user_principal = nonExistingAttribute` (SSSD#7092-workaround) → verergert het probleem. - `case_sensitive = False` → geen effect. - `sss_override user-add <kortenaam> -n <upn>` → geweigerd door de tool zelf ("Changing domain is not allowed!"), omdat het domeingedeelte van UPN en korte naam verschilt. - Cache vooraf "warm maken" via een systemd-oneshot-service → geen effect; de race treedt telkens opnieuw op, ook met warme cache. ## Impact Gebruikers kunnen niet inloggen op hun Ubuntu-laptop met hun standaard, organisatiebrede UPN/e-mailadres-vorm, en moeten in plaats daarvan de interne AD-korte-naamvorm (`[email protected]`) gebruiken — verwarrend voor eindgebruikers en inconsistent met Windows-, e-mail- en overige logins binnen de organisatie, die allemaal wel de UPN-vorm accepteren. ## Gevraagde vervolgstap Graag inschatting of dit een bekende/reeds gerapporteerde sssd-bug is, en zo niet: bevestiging of dit apart bij upstream SSSD (Pagure/GitHub) gemeld moet worden, naast de Ubuntu-specifieke melding. ProblemType: Bug DistroRelease: Ubuntu 26.04 Package: sssd 2.12.0-1ubuntu5.3 ProcVersionSignature: Ubuntu 7.0.0-30.30-generic 7.0.12 Uname: Linux 7.0.0-30-generic x86_64 ApportVersion: 2.34.1-0ubuntu0.1 Architecture: amd64 CasperMD5CheckResult: unknown CurrentDesktop: ubuntu:GNOME Date: Fri Sep 11 15:19:00 2026 InstallationDate: Installed on 2026-09-01 (10 days ago) InstallationMedia: Ubuntu 26.04 "Resolute Raccoon" - Release amd64 (20260423.1) SourcePackage: sssd UpgradeStatus: No upgrade log present (probably fresh install) ** Affects: sssd (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug resolute wayland-session -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2167100 Title: ssd upn login To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/2167100/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
