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