From Newsgroup: muc.lists.freebsd.ports

--Sig_/n4asmETSlKpbjZ7eBDi4Q5C
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

fighting a major problem here. Running recent CURRENT and 15-STABLE here. R= ecently we switched
from=20
net/nss-pam-ldapd
to
security/sssd2 (with net/samba423).

I've
used https://wiki.freebsd.org/KubilayKocak/SystemSecurityServicesDaemon as =
a basis for further steps.

User backend is=20
net/openldap26-server
using ppolicy Overlay. For the record: the LDAP DIT has been migrated from = 2.4 to 2.6 a couple
of years ago (successfuly).

Adjusting FreeBSD's PAM config for "other", "system", "sshd" worked well fo=
r sshd and
system/login so far (see below for more info). When login via sshd for LDAP=
backed users,
everything runs smooth (no dubios messages about expired passwords or simil= ar). Local (console)
login for those users also works as expected without further icident or rep= ort of expired
passwords.

When it comes to X11/xdm on local machines using GUI/X11/xdm, login fails f=
or LDAP backed
users.=20
FreeBSD's /var/log/auth.log reports:
Mar 22 14:17:41 <10.5> myhost xdm[7440]: LOGIN FAILURE ON :0, username

The LDAP objects (users) do not have shadowAccount objectclass, not attribu= tes (I deleted
those, with or without it doesn't change anything)

It drives me nuts, spent two days figuring out what's going to be missed by=
xdm, but I
couldn't find anything suitable. Maybe someone has already solved a similar=
problem ...


/etc/nsswitch.conf has been adapted approprietely, i.e.
[...]
passwd: files sss ldap

(I'm using a hybrid solution for now to serve xdm with the old nslcd)




In the config shown below with module account the term "optional|sufficient=
" means: I use
either or - only one - not both.


[... /etc/pam.d/xdm ...]
#
#
# PAM configuration for the "xdm" service
#

# auth
#auth sufficient pam_krb5.so no_warn try_first_p= ass
#auth sufficient pam_ssh.so no_warn try_first_p= ass
#auth sufficient pam_ssh.so no_warn try_first_p= ass
#auth sufficient /usr/local/lib/pam_ldap.so
auth sufficient /usr/local/lib/pam_sss.so forward_pass auth required pam_unix.so no_warn try_first_p= ass

# account
account required pam_nologin.so
#account required pam_krb5.so
#account optional /usr/local/lib/pam_ldap.so
account optional|sufficient /usr/local/lib/pam_sss.so \
ignore_authinfo_unavail ignore_unknown_user=20
account required pam_unix.so

# session
#session required pam_ssh.so want_agent
session required pam_lastlog.so no_fail
session required pam_xdg.so

# password
password required pam_deny.so




--=20

A FreeBSD user

--Sig_/n4asmETSlKpbjZ7eBDi4Q5C
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCacAIUAAKCRCxzvs8Oqok r2KBAP4l23kDiUaAJb5IS+XzXNje7Y/Na0XA5lqa+lcGKzf+MAEAh6jqwMLD7gC5 b8AYXx52B5i/qHG4xiucQFdab61q3gY=
=WAuw
-----END PGP SIGNATURE-----

--Sig_/n4asmETSlKpbjZ7eBDi4Q5C--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Sun, Mar 22, 2026 at 6:18rC>PM A FreeBSD User <freebsd@walstatt-de.de> wrote:

Hello,

fighting a major problem here.

Start with installing security/pamtester and running
pamtester xdm <username> authenticate
Does it also fail? Do you see something suspicious in SSSD logs?
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--Sig_/Q4TA9PQe7pAEU_8o35b8_eZ
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am Tage des Herren Sun, 22 Mar 2026 18:29:34 +0300
Gleb Popov <arrowd@freebsd.org> schrieb:

On Sun, Mar 22, 2026 at 6:18=E2=80=AFPM A FreeBSD User <freebsd@walstatt-=

de.de> wrote:

Hello,

fighting a major problem here. =20

=20
Start with installing security/pamtester and running
=20
pamtester xdm <username> authenticate
=20
Does it also fail? Do you see something suspicious in SSSD logs?
=20

Thanks for responding.

Some results (with pam_ldap.so):

ohartmann@host [ohartmann]: pamtester xdm ohartmann authenticate
Password:
pamtester: successfully authenticated

ohartmann@host [ohartmann]: pamtester xdm ohartmann acct_mgmt
pamtester: account management done.

ohartmann@host [ohartmann]: pamtester xdm ohartmann open_session
Can't mkdir /var/run/xdgpamtester: Session failure

When changing in /etc/pam.d/xdm
session required pam_xdg.so runtime_dir_prefix=3D/var/r= un/xdg/

I get=20
ohartmann@host [ohartmann]: pamtester xdm ohartmann open_session
Can't mkdir /var/run/xdg/pamtester: Session failure

There seems to be a bug in pam_xdg.so handling the last slash.

Using pam_sss.so as described initially in /etc/pam.d/xdm:

ohartmann@host [ohartmann]: pamtester xdm ohartmann authenticate
Password:
pamtester: successfully authenticated

ohartmann@host [ohartmann]: pamtester xdm ohartmann acct_mgmt
pamtester: account management done.

ohartmann@host [ohartmann]: pamtester xdm ohartmann open_session
Can't mkdir /var/run/xdg/pamtester: Session failure



I do not see anything useful being logged.
Setting "debug_level =3D 7" within /usr/local/etc/sssd/sssd.conf doesn't se=
e to have any effect
in the amount of log chatter being issue. Running sssd -i -d 7 fills up the=
screen very
quickly, but I never see anything suspicious.

I do have a local hosted fallback user, in my case "hartmann". I can login = with pam_sss.so
enabled without problem here.


Regards,
oh
--=20

A FreeBSD user

--Sig_/Q4TA9PQe7pAEU_8o35b8_eZ
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCacBpdQAKCRCxzvs8Oqok rya1AP9juG17B65CWxXaDTd60Ihl1g6vrNMdiiyLOaFSuvt/AgEAugwvezLq9+nm 8x8wEM2Hljz/x0FzlXLzWwplOgoVgQ8=
=qQwx
-----END PGP SIGNATURE-----

--Sig_/Q4TA9PQe7pAEU_8o35b8_eZ--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Mon, Mar 23, 2026 at 1:13rC>AM A FreeBSD User <freebsd@walstatt-de.de> wrote:

Using pam_sss.so as described initially in /etc/pam.d/xdm:

ohartmann@host [ohartmann]: pamtester xdm ohartmann authenticate
Password:
pamtester: successfully authenticated

ohartmann@host [ohartmann]: pamtester xdm ohartmann acct_mgmt
pamtester: account management done.

ohartmann@host [ohartmann]: pamtester xdm ohartmann open_session
Can't mkdir /var/run/xdg/pamtester: Session failure

Re-run these checks as root, because this is how xdm runs PAM, if I
understand it correctly.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--Sig_/sZ6pbk/0ATVUQsOLAn.eoMB
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am Tage des Herren Mon, 23 Mar 2026 18:19:28 +0300
Gleb Popov <arrowd@freebsd.org> schrieb:

On Mon, Mar 23, 2026 at 1:13=E2=80=AFAM A FreeBSD User <freebsd@walstatt-=

de.de> wrote:

Using pam_sss.so as described initially in /etc/pam.d/xdm:

ohartmann@host [ohartmann]: pamtester xdm ohartmann authenticate
Password:
pamtester: successfully authenticated

ohartmann@host [ohartmann]: pamtester xdm ohartmann acct_mgmt
pamtester: account management done.

ohartmann@host [ohartmann]: pamtester xdm ohartmann open_session
Can't mkdir /var/run/xdg/pamtester: Session failure =20

=20
Re-run these checks as root, because this is how xdm runs PAM, if I understand it correctly.
=20

I did.
With nslcd disabled and sssd as LDAP connector enabled

root@host:~ # pamtester xdm ohartmann authenticate acct_mgmt open_session c= lose_session
Password:
pamtester: successfully authenticated
pamtester: account management done.
pamtester: sucessfully opened a session
pamtester: session has successfully been closed.

In /usr/local/etc/sssd/sssd.conf I also tried to enable "debug_level =3D 6"=
- I never see in ANY
log file residing in /var/log more than (grep -r sssd /var/log):
[...]
/var/log/sssd/sssd.log:Mar 25 09:59:22 <3.6> host sssd[6040]: Starting up /var/log/sssd/sssd.log:Mar 25 09:59:22 <3.6> host sssd_be[6041]: Starting up /var/log/sssd/sssd.log:Mar 25 09:59:23 <3.6> host sssd_nss[6042]: Starting =
up
/var/log/sssd/sssd.log:Mar 25 09:59:23 <3.6> host sssd_pam[6043]: Starting =
up

and as stated above, /var/log/auth
Mar 25 11:47:49 <10.5> host xdm[6906]: LOGIN FAILURE ON :0, ohartmann

Grepping for "xdm" doesn't show anything usuful, either.

Earlier, with LDAP object shadowAccount as part of any user object provided=
by OpenLDAP with
shadowXX attributes (even correctly set!) nslcd(!) reported via /var/log/au= th.log and xdm:
[...]
/var/log/auth.log:Mar 22 14:20:24 <10.5> host xdm[7504]: Password expired = 19075 days ago,
account locked 19061 days ago; user=3Dohartmann; err=3DPassword has expired

while running sssd didn't. Login was always possible, by the way (console l= ogin/ssh).=20

That is only a small subset of useful or less useful (or stupid) permutati= ons of
config combinations. I'm out of ideas and tend to consider the combination = security/sssd2 and
x11/xdm as non-working.

Kind regards

Oliver


--=20

A FreeBSD user

--Sig_/sZ6pbk/0ATVUQsOLAn.eoMB
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCacPSAgAKCRCxzvs8Oqok r2Q7AP9yxVLV7ElW1R9BwZiKaUKlQsvMW8edQloF0PAlmSSKKQD9FcbtmygCrdQX Xcv6gUfCgY6z3YAe83pZ6pNCFma3VwQ=
=eCQV
-----END PGP SIGNATURE-----

--Sig_/sZ6pbk/0ATVUQsOLAn.eoMB--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Wed, Mar 25, 2026 at 3:16rC>PM A FreeBSD User <freebsd@walstatt-de.de> wrote:

In /usr/local/etc/sssd/sssd.conf I also tried to enable "debug_level = 6" - I never see in ANY
log file residing in /var/log more than (grep -r sssd /var/log):

Yes, I also don't remember how to properly enable logging to file in
SSSD. Instead, when I need to debug it, I do
service sssd stop
sssd -dddd -i
This runs sssd in the foreground with all logs visible on the console.
Maybe you should try this as a last attempt?
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--Sig_/u+27sEVMPCWbqbogt1k/Aog
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am Tage des Herren Wed, 25 Mar 2026 16:35:10 +0300
Gleb Popov <arrowd@freebsd.org> schrieb:

On Wed, Mar 25, 2026 at 3:16=E2=80=AFPM A FreeBSD User <freebsd@walstatt-=

de.de> wrote:

In /usr/local/etc/sssd/sssd.conf I also tried to enable "debug_level =

=3D 6" - I never see in

ANY log file residing in /var/log more than (grep -r sssd /var/log): =20

=20
Yes, I also don't remember how to properly enable logging to file in
SSSD. Instead, when I need to debug it, I do

I tried almost every section applying debug_leve =3D XX, either an integer =
in decimal notation
or its hex analogon.
Loggin even doesn't work when setting "-d 6" in /etc/rc.conf (sssd_flags=3D= "${sssd_flags} -d 8").

Maybe this is a real bug?

=20
service sssd stop
sssd -dddd -i
=20
This runs sssd in the foreground with all logs visible on the console.
Maybe you should try this as a last attempt?
=20

I used=20
sssd_flags=3D"${sssd_flags} -d 8 -i

in /etc/rc.conf (sssd_flags=3D"...").

Since I try to copy-paste from consoles of my box, it is a pain. I do not s=
ee anything
suspicious, which doesn't mean that there isn't anything from the point of = view of a
seasoned/skilled developer. But I fight copying from console to console and=
somehow I copy
always the first(!) occurence of anything on one console - the same stuff i=
s copied over and
over not matter how much log pushes through the console, when switching ALT= -F5, for instance,
I copy always the stuff marked (mouse dragging) the very first time (for th=
e record: vt driver
...).

Nearby: when checking as root=20

pamtester xdm ohartmann authenticate acct_mgmt open_session close_session

I see up to acct_mgmt in the log - but nothing for open_session close_sessi= on.

Another point is that I do not use proper search filters defined in sssd.co=
nf for ou=3Dusers,
ou=3Dgroups and let the algorithm of sssd traverse down to the right object=
, starting from
search base on. This works with login, ssh. I don't see anything different,=
but it might be a
chance to get something ...

Kind regrards and thanks for the help,

Oliver=20


--=20

A FreeBSD user

--Sig_/u+27sEVMPCWbqbogt1k/Aog
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCacV0sAAKCRCxzvs8Oqok r8lwAQCC3QjgvmAe7TM6ZIWlBIQaiNJM/1NdXKNAbSta9LEwhAEAm7ZNGjimpnSA eJ3vzP5iTv6Epkk2/5mJvgSo1ps9bAI=
=4iru
-----END PGP SIGNATURE-----

--Sig_/u+27sEVMPCWbqbogt1k/Aog--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Thu, Mar 26, 2026 at 9:02rC>PM A FreeBSD User <freebsd@walstatt-de.de> wrote:

Nearby: when checking as root

pamtester xdm ohartmann authenticate acct_mgmt open_session close_session

I see up to acct_mgmt in the log - but nothing for open_session close_session.

I just remembered about this: https://github.com/SSSD/sssd/pull/7761/changes Try adding the allow_chauthtok_by_root option into PAM configuration.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

--Sig_/x33F7zhz0wuWzutvARtW_jq
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Am Tage des Herren Sat, 28 Mar 2026 20:27:07 +0300
Gleb Popov <arrowd@freebsd.org> schrieb:

On Thu, Mar 26, 2026 at 9:02=E2=80=AFPM A FreeBSD User <freebsd@walstatt-=

de.de> wrote:

Nearby: when checking as root

pamtester xdm ohartmann authenticate acct_mgmt open_session close_sessi=

on

I see up to acct_mgmt in the log - but nothing for open_session close_s=

ession. =20

=20
I just remembered about this: https://github.com/SSSD/sssd/pull/7761/chan=

ges

Try adding the allow_chauthtok_by_root option into PAM configuration.
=20

Thank you for the hint.
I had the chance to put the referenced token into /etc/pam.d/xdm. Since lib= _sss.so seems to be
very tolerant with respect to were I put the token, I tried every section a=
nd exclusively auth
and accounting or at all positions. NO effect.

I'm not very firm in terms of how the PAM stack works, I assume "xdm" is us= ing the file
/etc/pam.d/xdm exclusively - not using another trailing module or not being=
a consecutive
module while another module (like login?) takes password and login credenti= als.

Without a proper logging I'm flying blind here and it seems that sssd2 isn'=
t coping with xdm
or its way to provide credential.

I have to underline that any other pam method (or whatever login, sshd etc.=
is called) is
working flawless.

Kind regards,
oh=20

--=20

A FreeBSD user

--Sig_/x33F7zhz0wuWzutvARtW_jq
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRQheDybVktG5eW/1Kxzvs8OqokrwUCac/2RAAKCRCxzvs8Oqok ryJwAP4iutYulISkwzux3543w2Zw9JAnLdlKURhHOqQ24q+awwD9FZuiDYY5tKyJ 71ME8tTuTQ3IiiH5m4hqPhemji16Sgk=
=wDgK
-----END PGP SIGNATURE-----

--Sig_/x33F7zhz0wuWzutvARtW_jq--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

I managed to reproduce the issue on 15.0-RELEASE and SSSD with the
Active Directory backend.
Unfortunately, debugging XDM is painful as it forks a lot, so I
haven't been able to identify the root cause yet.
I will hopefully take another stab on it next week.


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.ports

On Thu, Apr 23, 2026 at 11:18rC>PM Gleb Popov <arrowd@freebsd.org> wrote:

I managed to reproduce the issue on 15.0-RELEASE and SSSD with the
Active Directory backend.
Unfortunately, debugging XDM is painful as it forks a lot, so I
haven't been able to identify the root cause yet.
I will hopefully take another stab on it next week.

As a data point, I managed to login as a domain user via x11/sddm.
I had to use security/pam_mkhomedir and the login didn't work for the
first time, but then it worked.
It seems that xdm is calling pam in some strange way that makes it
believe that authentication is failing.
I don't want to spend time debugging this ancient software, especially
when there is a working contemporary alternative.
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21f-Linux NewsLink 1.2