Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PAM service configuration blocks login for AD users #128116

Closed
wucke13 opened this issue Jun 25, 2021 · 5 comments
Closed

PAM service configuration blocks login for AD users #128116

wucke13 opened this issue Jun 25, 2021 · 5 comments
Labels
0.kind: bug Something is broken 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS

Comments

@wucke13
Copy link
Contributor

wucke13 commented Jun 25, 2021

Describe the bug
When using krb5 together with samba & winbind for login in an AD, login works everywhere except login. So su or sshd for example work just fine. However, when login is used (either through the binary in the shell or through a tty or display manager), I get:

Password:
You have been logged on using cached credentials.

Login incorrect

Up on further inspection, I noticed a difference in the respective pam service files. Most of these files have

auth sufficient pam_unix.so   likeauth try_first_pass

with one notable difference: /etc/pam.d/login has

auth required pam_unix.so nullok  likeauth

If I change the required in /etc/pam.d/login by sufficient, I can login to AD accounts without problem even using login or tty.

To Reproduce
Steps to reproduce the behavior:
(It's not realistically possible to reproduce the full setup)

  1. Setup an AD with krb5, samba (+winbind) and a custom pam winbind service
security.pam.services = {
  login.makeHomeDir = true;
  sshd.makeHomeDir = true;
  su.makeHomeDir = true;
  winbind.text = ''
    auth sufficient ${pkgs.samba4Full}/lib/security/pam_winbind.so
    account sufficient ${pkgs.samba4Full}/lib/security/pam_winbind.so
    password sufficient ${pkgs.samba4Full}/lib/security/pam_winbind.so
    session sufficient ${pkgs.samba4Full}/lib/security/pam_winbind.so
  '';
};

Expected behavior
Login works for AD users with su, sshd and login all the same.

Additional Notes

I'm by no means an expert in the domain of domains. What I however wonder is, how others solved this issue when integrating NixOS machines in an AD.

Metadata

  • system: "x86_64-linux"
  • host os: Linux 5.12.11, NixOS, 21.05.20210620.6613a30 (Okapi)
  • multi-user?: yes
  • sandbox: yes
  • version: nix-env (Nix) 2.4pre20210601_5985b8b
  • channels(root): "nixos-21.05.1076.bad3ccd099e"
  • nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos

Maintainer information:

# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:
@wucke13 wucke13 added the 0.kind: bug Something is broken label Jun 25, 2021
@veprbl veprbl added the 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS label Jun 26, 2021
@wucke13
Copy link
Contributor Author

wucke13 commented Jul 22, 2021

Update: This seems to be related to the section following this line in the pam module.

Namely, if any of config.security.pam.enableEcryptfs, cfg.pamMount, cfg.enableKwallet, cfg.enableGnomeKeyring, cfg.googleAuthenticator.enable, cfg.gnupg.enable or cfg.duoSecurity.enable is true, pam_unix.so is required, breaking any remote auth (like LDAP/AD/...). Why is this the case? Do these things (like kwallet or gnome-keyring) only work when called after pam_unix.so?

@stale
Copy link

stale bot commented May 1, 2022

I marked this as stale due to inactivity. → More info

@stale stale bot added the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label May 1, 2022
@wucke13
Copy link
Contributor Author

wucke13 commented May 2, 2022

This is not stale.

@stale stale bot removed the 2.status: stale https://github.com/NixOS/nixpkgs/blob/master/.github/STALE-BOT.md label May 2, 2022
@wucke13
Copy link
Contributor Author

wucke13 commented May 18, 2022

At least for sssd, it looks like gnome keyring would be propagated correctly (sssd 2.2.2 release notes). So probably the comment

Modules in this block require having the password set in PAM_AUTHTOK.
pam_unix is marked as 'sufficient' on NixOS which means nothing will run
after it succeeds. Certain modules need to run after pam_unix
prompts the user for password so we run it once with 'required' at an
earlier point and it will run again with 'sufficient' further down.
We use try_first_pass the second time to avoid prompting password twice

from

# Modules in this block require having the password set in PAM_AUTHTOK.
is likely not true anymore for sssd

wucke13 pushed a commit to wucke13/nixpkgs that referenced this issue May 18, 2022
Previously, `pam_unix.so` was `required` to set PAM_AUTHTOK so that
dependent pam modules (such as gnome keyering) could use the password
(for example to unlock a keyring) upon login of the user. This however
broke any additional auth providers (such as AD or LDAP): for any
non-local user `pam_unix.so` will not yield success, thus eventually the
auth would fail (even the following auth providers were actually
executed, they could not overrule the already failed auth).

This change replaces `required` by `optional`. Therefore, the
`pam_unix.so` is executed and can set the PAM_AUTHTOK for the following
optional modules, _even_ if the user is not a local user. Therefore, the
gnome keyring for example is unlocked both for local and additional
users upon login, and login is working for non-local users via
LDAP/AD.
@fpletz
Copy link
Member

fpletz commented Aug 22, 2022

Fixed by #173495.

@fpletz fpletz closed this as completed Aug 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0.kind: bug Something is broken 6.topic: nixos Issues or PRs affecting NixOS modules, or package usability issues specific to NixOS
Projects
None yet
Development

No branches or pull requests

3 participants