Re: [lmi] redhat server, PAM, LDAP

[Vadim Zeitlin]

On Mon, 12 Oct 2020 23:37:45 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> On 2020-10-12 21:40, Vadim Zeitlin wrote:
GC> > On Mon, 12 Oct 2020 21:13:12 +0000 Greg Chicares 
<gchicares@sbcglobal.net> wrote:
GC> [...snip rationale for user 'nemo'...]
GC> > GC> $sudo schroot --chroot=lmi_bullseye_3 --user=nemo
GC> > GC> E: You are required to change your password immediately (password 
aged)
GC> > GC> E: PAM error: Authentication token is no longer valid; new one 
required
GC> > 
GC> >  Out of curiosity (because I don't see how would this really help you),
GC> > does "su nemo" still work or does it fail with the same error?
GC> 
GC> I can't run that exact command because I'm just a sudoer and I
GC> don't have the root password. But this should be similar
GC> [copied by retyping from a different machine]:
GC> 
GC> $sudo su nemo
GC> Attempting to create directory /home/nemo/perl5
GC> [nemo@REDACTED_HOST]/home/MY_OWN_ID_NOT_NEMO %
GC> 
GC> [nemo@REDACTED_HOST]/home/MY_OWN_ID_NOT_NEMO % whoami
GC> nemo
GC> 
GC> I then tried the "sudo schroot ... --user=nemo" command again,
GC> but it failed with the same "password aged" error message.

 So apparently schroot uses PAM in a different way. I could look into this
and see if it provides sufficient information to find some workaround, but
it doesn't seem necessary, considering the end of your reply, so I won't do
it unless you tell me to or I suffer from an especially acute curiosity
crisis.

 FWIW I think "sudo chroot" followed by "su nemo" inside the chroot should
work too.

GC> > GC> I guess running 'useradd' as a mere superuser creates an
GC> > GC> account that an updated PAM considers an abomination.
GC> > 
GC> >  The problem is that I see nothing wrong with PAM using some external
GC> > database (using LDAP or whatever) instead of the historical files in /etc.
GC> > I don't even see that much wrong with using both sources. But I don't see
GC> > at all how did can it be possible to add a user into the local files but
GC> > have its password expiration be managed by the remote database. This
GC> > completely contradicts my mental picture of how things are supposed to
GC> > work, inducing cognitive dissonance. As I said above, not amusing at all.
GC> 
GC> My guess is that PAM asks LDAP about 'nemo', who is unknown to LDAP,
GC> and LDAP throws a conniption, spitting out some last-resort error
GC> message that turns out to be completely misleading, instead of
GC> a hypothetical
GC>   "LDAP: user 'nemo' unknown--instructing PAM to block it"

 This doesn't explain why has it just started happening though. I think
PAM does store the account expiration date in LDAP, somehow. But I'm really
not sure.

GC> Experience strongly suggests that that's a dead end.

 This seems to crazy to me, but I definitely defer to your experience.

GC> I had a happy thought when writing a commit message for d7fbbbd8:
GC> 
GC> | It should still be possible to test interoperability among group members
GC> | by using a centos chroot on a personal machine as a simulacrum of the
GC> | corporate server.
GC> 
GC> That's certain to work, and to keep working indefinitely.
GC> And if it should ever break, I'll have the power to fix it.

 I'm starting to get lost in the maze of all these chroots, all alike, but
I guess this should indeed work...

 Good luck once again,
VZ

pgpScfBzCXizB.pgp
Description: PGP signature