Bug 1202141

Related: https://bugzilla.opensuse.org/show_bug.cgi?id=1200766

(In reply to robert spitzenpfeil from comment #0)
> Since 'samba-client' doesn't crash anymore on TW, I've managed to join our
> AD, enabled winbind auth, pam_mount ... (all of this works on Leap 15.2 /
> 15.4 with samba packages coming from "home:markusd:samba-fresh"
> 4.16.4-lp154.1.1).
> 
> After the motions with YaST samba-client I could not log on text consoles
> anymore, ssh login did not work anymore ... sddm login still works.
> 
> I then copied the whole contents of /etc/pam.d/ from a known good Leap 15.2
> installation to my TW VM and everything works again.
> 
> When I have some more time, I'll diff the auto-created files that YaST spits
> out and maybe find something.
> 
> 
> Related: https://bugzilla.opensuse.org/show_bug.cgi?id=1199734

Could you please attach the generated files (/etc/pam.d/*) and Yast log (/var/log/YaST2/y2log)?

Created attachment 860613 [details]
y2log

Created attachment 860614 [details]
/etc/pam.d before running samba-client for AD join

Created attachment 860615 [details]
/etc/pam.d after running samba-client for AD join

Hi Robert,

the problem is your /etc/pam.d/sshd file. It does not include the common-* files, where pam_winbind is correctly enabled.

If you have edited it on purpose, please add pam_winbind to it. Otherwise, if it is a leftover after the usrmerge (https://en.opensuse.org/openSUSE:Usr_merge), check that /usr/etc/pam.d/sshd exists and delete it.

For reference, this is my /usr/etc/pam.d/sshd file:
> #%PAM-1.0
> auth        requisite   pam_nologin.so
> auth        include     common-auth
> account     requisite   pam_nologin.so
> account     include     common-account
> password    include     common-password
> session     required    pam_loginuid.so
> session     include     common-session
> session     optional    pam_keyinit.so   force revoke
> session     optional    pam_lastlog.so   showfailed
> session     optional    pam_motd.so

This VM is a fresh installation of TW, so I would expect stuff to be in a working state before running the AD stuff (it was).

There cannot be any leftover files due to user intervention.

Why the file is borked after running samba-client I don't know.

/etc/pam.d/sshd did not exist before running yast samba-client.

/usr/etc/pam.d/sshd exists and is identical to yours.

It seems the files /etc/pam.d/login|xdm|sshd get created in a bad way.

2022-08-04 18:13:15 <3> FQDN.de(1293) [bash] ShellCommand.cc(shellcommand):78 Cannot stat '/etc/pam.d/login': No such file or directory
2022-08-04 18:13:15 <2> FQDN.de(1293) [Ruby] modules/Samba.rb(block in Write):923 pam-config failed for service login
2022-08-04 18:13:15 <3> FQDN.de(1293) [bash] ShellCommand.cc(shellcommand):78 Cannot stat '/etc/pam.d/xdm': No such file or directory
2022-08-04 18:13:15 <2> FQDN.de(1293) [Ruby] modules/Samba.rb(block in Write):923 pam-config failed for service xdm
2022-08-04 18:13:15 <3> FQDN.de(1293) [bash] ShellCommand.cc(shellcommand):78 Cannot stat '/etc/pam.d/sshd': No such file or directory
2022-08-04 18:13:15 <2> FQDN.de(1293) [Ruby] modules/Samba.rb(block in Write):923 pam-config failed for service sshd
2022-08-04 18:13:15 <1> FQDN.de(1293) [Ruby] clients/samba-client.rb(main):172 Samba-client module finished

I copied /usr/etc/pam.d/sshd | login | xdm to /etc/pam.d/ and ran yast samba-client again.

This time the files in /etc/pam.d/ get ammended as needed. They are mostly identical to the ones created on 15.2 / 15.4 except some "systemd-user" stuff (one line).

However, auth via winbind still does not work.

Now testing with a fresh installation of Leap 15.4

The creation / modification of files in /etc/pam.d/ seems OK with Leap 15.4 (server template).

Leap 15.4 / 15.2 (and TW) work _after_ making a modification to the auto-generated /etc/samba/smb.conf file (as previously documented on here somewhere). I don't remember where I got these edits from anymore.

These edits are _the same_ for Leap 15.2 / 15.4 and TW


I have to replace the section:

[global]
	workgroup = ADS
	passdb backend = tdbsam
	printing = cups
	printcap name = cups
	printcap cache time = 750
	cups options = raw
	map to guest = Bad User
	logon path = \\%L\profiles\.msprofile
	logon home = \\%L\%U\.9xprofile
	logon drive = P:
	usershare allow guests = No

>	idmap config * : backend = tdb
>	idmap config * : range = 10000-20000
>	idmap config ads : backend = rid
>	idmap config ads : range = 20001-99999

	kerberos method = secrets and keytab
	realm = ADS.XXX.XXX
	security = ADS
	template homedir = /home/%D/%U
	template shell = /bin/bash
	winbind refresh tickets = yes


with

[global]
	workgroup = ADS
	passdb backend = tdbsam
	printing = cups
	printcap name = cups
	printcap cache time = 750
	cups options = raw
	map to guest = Bad User
	logon path = \\%L\profiles\.msprofile
	logon home = \\%L\%U\.9xprofile
	logon drive = P:
	usershare allow guests = No

>	idmap gid = 10000-20000
>	idmap uid = 10000-20000

	kerberos method = secrets and keytab
	realm = ADS.XXX.XXX
	security = ADS
	template homedir = /home/%D/%U
	template shell = /bin/bash
	winbind refresh tickets = yes



This may be related to our AD setup, but I can't make any comments on why.


getent passwd / group only shows local stuff. "id" shows correct group membership for AD users (after the mod).

I guess my comment 12 indicates that yast samba-client doesn't like /usr/etc/pam.d/ vs. /etc/pam.d/

Hi Robert,

thanks for your collaboration, I see the problem now. This problem only occurs when you configure mount directories. In this case the module executes:

> pam-config --service sshd -a --mount

But pam-config tool does not handle /usr/etc properly.

Blocked until bsc#1196613 is fixed.

Good to know that there is an explanation for this.

Supposedly the underlying bug in pam has been fixed now.

I did my usual tests with yast & pam_mount / pam_winbind and again ended up with a dysfunctional pam stack (console login was borked).

I tried with a fresh VM (openSUSE-Tumbleweed-NET-x86_64-Snapshot20221003-Media.iso)

I can run various tests to help fix this - if I'm told what is required.

(In reply to robert spitzenpfeil from comment #20)
> Supposedly the underlying bug in pam has been fixed now.
> 
> I did my usual tests with yast & pam_mount / pam_winbind and again ended up
> with a dysfunctional pam stack (console login was borked).
> 
> I tried with a fresh VM
> (openSUSE-Tumbleweed-NET-x86_64-Snapshot20221003-Media.iso)
> 
> I can run various tests to help fix this - if I'm told what is required.

The fix was included in Snapshot20221012: https://mirror.ihost.md/opensuse/tumbleweed/iso/Changes.20221012.txt

Please update to pam-config 1.7.

Much better now.

/etc/pam.d/sddm doesn't get the pam_mount.so entries, but they are copied form xdm easily enough.

/etc/pam.d/sshd gets the pam_mount.so entries as well, but mounting fails (cifs_mount failed w/return code = -13). I'll have to look into that some more.

For pam_winbind to correclty work with our domain setup, I still need a customized smb.conf

I forgot about this...

In my case sshd must be configures as such:

---
ChallengeResponseAuthentication no
UsePAM yes
---


Then pam_mount works with ssh logins.