fix(ipa): restore IPA password login via LightDM and su #91

2026-07-28T07:31:43Z

beatzaplenty commented

2026-07-28 07:31:43 +00:00

Two independent fixes:

hashedPassword = "!" on the IPA user stub
Without any shadow entry, pam_unix returns PAM_AUTHINFO_UNAVAIL
before prompting, so PAM_AUTHTOK is never set. The "!" marker
(account locked, not a real hash) ensures a shadow entry exists so
pam_unix prompts and sets PAM_AUTHTOK — which the subsequent
pam_sss module can then use.
pam_sss try_first_pass instead of use_first_pass (login + su)
use_first_pass silently fails when PAM_AUTHTOK is unset.
try_first_pass prompts independently in that case, making IPA
password auth work even if pam_unix returns early for any reason.

Root cause found during incident: wayne (uid 50002) was outside IPA's
auto-SID range (163800000+), so sidgen never assigned him an
ipaNTSecurityIdentifier. Without it, ipadb's handle_authdata step fails
with "Generic error" after SPAKE pre-auth succeeds. Fixed by manually
adding objectClass: ipaNTUserAttrs + ipaNTSecurityIdentifier RID 550002
to wayne's LDAP entry on domain-controller. Any future IPA user with a
manually-assigned uid outside the auto-range needs the same treatment.

Co-Authored-By: Claude Sonnet 4.6 noreply@anthropic.com

Two independent fixes: 1. hashedPassword = "!" on the IPA user stub Without any shadow entry, pam_unix returns PAM_AUTHINFO_UNAVAIL before prompting, so PAM_AUTHTOK is never set. The "!" marker (account locked, not a real hash) ensures a shadow entry exists so pam_unix prompts and sets PAM_AUTHTOK — which the subsequent pam_sss module can then use. 2. pam_sss try_first_pass instead of use_first_pass (login + su) use_first_pass silently fails when PAM_AUTHTOK is unset. try_first_pass prompts independently in that case, making IPA password auth work even if pam_unix returns early for any reason. Root cause found during incident: wayne (uid 50002) was outside IPA's auto-SID range (163800000+), so sidgen never assigned him an ipaNTSecurityIdentifier. Without it, ipadb's handle_authdata step fails with "Generic error" after SPAKE pre-auth succeeds. Fixed by manually adding objectClass: ipaNTUserAttrs + ipaNTSecurityIdentifier RID 550002 to wayne's LDAP entry on domain-controller. Any future IPA user with a manually-assigned uid outside the auto-range needs the same treatment. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

beatzaplenty added 1 commit 2026-07-28 07:31:43 +00:00

fix(ipa): restore IPA password login via LightDM and su

Check NixOS configurations / eval-hosts (pull_request) Successful in 10m33s

Details

fc8f7baf3e

Two independent fixes:

1. hashedPassword = "!" on the IPA user stub
   Without any shadow entry, pam_unix returns PAM_AUTHINFO_UNAVAIL
   before prompting, so PAM_AUTHTOK is never set. The "!" marker
   (account locked, not a real hash) ensures a shadow entry exists so
   pam_unix prompts and sets PAM_AUTHTOK — which the subsequent
   pam_sss module can then use.

2. pam_sss try_first_pass instead of use_first_pass (login + su)
   use_first_pass silently fails when PAM_AUTHTOK is unset.
   try_first_pass prompts independently in that case, making IPA
   password auth work even if pam_unix returns early for any reason.

Root cause found during incident: wayne (uid 50002) was outside IPA's
auto-SID range (163800000+), so sidgen never assigned him an
ipaNTSecurityIdentifier. Without it, ipadb's handle_authdata step fails
with "Generic error" after SPAKE pre-auth succeeds. Fixed by manually
adding objectClass: ipaNTUserAttrs + ipaNTSecurityIdentifier RID 550002
to wayne's LDAP entry on domain-controller. Any future IPA user with a
manually-assigned uid outside the auto-range needs the same treatment.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

beatzaplenty merged commit 601db79689 into main

2026-07-28 07:31:47 +00:00

This repo is archived. You cannot comment on pull requests.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: beatzaplenty/nixos#91