Re: [lmi] redhat server, PAM, LDAP

[Greg Chicares]

On 2020-10-12 21:40, Vadim Zeitlin wrote:
> On Mon, 12 Oct 2020 21:13:12 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...snip rationale for user 'nemo'...]
> GC> $sudo schroot --chroot=lmi_bullseye_3 --user=nemo
> GC> E: You are required to change your password immediately (password aged)
> GC> E: PAM error: Authentication token is no longer valid; new one required
> 
>  Out of curiosity (because I don't see how would this really help you),
> does "su nemo" still work or does it fail with the same error?

I can't run that exact command because I'm just a sudoer and I
don't have the root password. But this should be similar
[copied by retyping from a different machine]:

$sudo su nemo
Attempting to create directory /home/nemo/perl5
[nemo@REDACTED_HOST]/home/MY_OWN_ID_NOT_NEMO %

[nemo@REDACTED_HOST]/home/MY_OWN_ID_NOT_NEMO % whoami
nemo

I then tried the "sudo schroot ... --user=nemo" command again,
but it failed with the same "password aged" error message.

> GC> I guess running 'useradd' as a mere superuser creates an
> GC> account that an updated PAM considers an abomination.
> 
>  The problem is that I see nothing wrong with PAM using some external
> database (using LDAP or whatever) instead of the historical files in /etc.
> I don't even see that much wrong with using both sources. But I don't see
> at all how did can it be possible to add a user into the local files but
> have its password expiration be managed by the remote database. This
> completely contradicts my mental picture of how things are supposed to
> work, inducing cognitive dissonance. As I said above, not amusing at all.

My guess is that PAM asks LDAP about 'nemo', who is unknown to LDAP,
and LDAP throws a conniption, spitting out some last-resort error
message that turns out to be completely misleading, instead of
a hypothetical
  "LDAP: user 'nemo' unknown--instructing PAM to block it"

>  I hate to say it, but perhaps it could be possible to find someone in the
> IT department who would be able to explain how is this supposed to work?

Experience strongly suggests that that's a dead end.

> GC> Too bad--now we'll have to test this the hard way again.
> 
>  Could you create a new user "nemo1"? Or "nemi20201012" to be systematic
> about it? Maybe even using the same (local) UID?
I had a happy thought when writing a commit message for d7fbbbd8:

| It should still be possible to test interoperability among group members
| by using a centos chroot on a personal machine as a simulacrum of the
| corporate server.

That's certain to work, and to keep working indefinitely.
And if it should ever break, I'll have the power to fix it.