Control: reassign -1 winbind On Sun, May 14, 2017 at 10:05:03PM +0200, Christian Meyer wrote: > Package: libpam0g > Version: 1.1.8-3.5 > Severity: important > File: pam > > Dear Maintainer, > > I'm trying to login via ssh as a Windows AD user and auth fails. > When doing a ssh-login as a local user it works fine. > After login out the local user and trying as domain user again, it works > fine, like expected. > The bug mostly (only?) occurs after being idle (with no users logged in) for > 'some time', e.g. every mornig (24/7 machine) or after being shut down for > the weekend. > I think this is a regression from jessie that should not go in final stretch. > > When I compare a successfull run with a failed attempt I find the output of > 'service sshd status': > > Mai 14 17:04:27 fail-host pam-script[2375]: can not stat > /usr/share/libpam-script/pam_script_auth > Mai 14 17:04:27 fail-host sshd[2375]: pam_unix(sshd:auth): check pass; user > unknown > Mai 14 17:04:27 fail-host sshd[2375]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.0.1 > Mai 14 17:04:27 fail-host sshd[2375]: pam_winbind(sshd:auth): getting > password (0x00000388) > Mai 14 17:04:27 fail-host sshd[2375]: pam_winbind(sshd:auth): pam_get_item > returned a password > Mai 14 17:04:29 fail-host sshd[2375]: Failed password for invalid user > domainuser from 172.16.0.1 port 41037 ssh2 > Mai 14 17:04:46 fail-host sshd[2375]: Connection closed by 172.16.0.1 port > 41037 [preauth] > > Mai 14 17:05:14 success-host pam-script[30067]: can not stat > /usr/share/libpam-script/pam_script_auth > Mai 14 17:05:14 success-host sshd[30067]: pam_unix(sshd:auth): authentication > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.16.0.1 > user=domainuser > Mai 14 17:05:14 success-host sshd[30067]: pam_winbind(sshd:auth): getting > password (0x00000388) > Mai 14 17:05:14 success-host sshd[30067]: pam_winbind(sshd:auth): > pam_get_item returned a password > Mai 14 17:05:15 success-host sshd[30067]: pam_winbind(sshd:auth): user > 'domainuser' granted access > > Of course pam_unix fails for domain users, but I see it complains about 'user > unknown': > When ever there is no parameter 'user=XYZ' on the pam_unix line then auth > fails for domain users (with pam_winbind), too. > What causes that 'user=' mostly appears and works but sometimes is missing? > Local users do not fail.
This points to an issue with NSS on your system: 'user unknown' means that the username can't be resolved in the NSS database. Since this indicates that both NSS (username lookup) and PAM (authentication) are failing for your domain users in this situation, this points to an issue with winbind; reassigning this bug report. > I've seen a similar bug with missing 'user=...' using gdm3 on jessie, too, > but that happened on about 1-2 of 40 computers a day > and vanished after some time with cron driven winbind restarts. > The actual problem is reproducible on a machine without GUI every day. > > I know winbind crashes often (and that for it sucks heavily), so I first > thought this could be a winbind issue. But when pam_winbind does not know > the 'user=' parameter its clear it can not succeed (Of course it really > must not crash (as it does) in this case) I think your first instinct was correct here :) > Since I'm not very good with PAM usage/debugging, please let me know what > information I can provide to solve this bug. > > Thanks for your attention, > Christian Meyer > > > # cat /etc/pam.d/common-auth > # > # /etc/pam.d/common-auth - authentication settings common to all services > # > # This file is included from other service-specific PAM config files, > # and should contain a list of the authentication modules that define > # the central authentication scheme for use on the system > # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the > # traditional Unix authentication mechanisms. > # > # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. > # To take advantage of this, it is recommended that you configure any > # local modules either before or after the default block, and use > # pam-auth-update to manage selection of other modules. See > # pam-auth-update(8) for details. > # here are the per-package modules (the "Primary" block) > auth sufficient pam_script.so > auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass > auth [success=1 default=ignore] pam_winbind.so krb5_auth > krb5_ccache_type=FILE cached_login try_first_pass > # here's the fallback if no module succeeds > auth requisite pam_deny.so > # prime the stack with a positive return value if there isn't one already; > # this avoids us returning an error just because nothing sets a success code > # since the modules above will each just jump around > auth required pam_permit.so > # and here are more per-package modules (the "Additional" block) > # end of pam-auth-update config > > > > -- System Information: > Debian Release: 9.0 > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 > (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages libpam0g:amd64 depends on: > ii debconf [debconf-2.0] 1.5.60 > ii libaudit1 1:2.6.7-2 > ii libc6 2.24-10 > > libpam0g:amd64 recommends no packages. > > Versions of packages libpam0g:amd64 suggests: > pn libpam-doc <none> > > -- debconf information: > libraries/restart-without-asking: false > libpam0g/restart-failed: > libpam0g/xdm-needs-restart: > libpam0g/restart-services: > -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
