Your message dated Mon, 30 Apr 2018 15:36:17 +0200
with message-id
<CAFX5sbwOXQjc+JtC7RZJF_hm=f3_3n-7f_yxr19woldva+u...@mail.gmail.com>
and subject line CLosing
has caused the Debian Bug report #862580,
regarding pam: PAM 'user unknown' prevents domain login but allows local logins
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
862580: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862580
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
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)
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:
--- End Message ---
--- Begin Message ---
It looks like the crashed were caused by restarting winbind at each
logon. Closing ...
Maybe the wiki page should be completely removed?
Regards
--
Mathieu Parent
--- End Message ---
