Re: [lmi] redhat server, PAM, LDAP

[Vadim Zeitlin]

On Mon, 12 Oct 2020 21:13:12 +0000 Greg Chicares <gchicares@sbcglobal.net> 
wrote:

GC> There's no real question or problem here, but for your amusement...

 This is not amusing at all because I have no idea about what's going on
here and I hate it.

GC> A while ago, I added a user 'nemo' to a corporate RHEL server.
GC> That new user appeared in /etc/passwd, although all official users
GC> aren't there (I think LDAP is used instead). All I wanted was an
GC> unprivileged throwaway account that I could use for chroot testing.
GC> In particular, if Kim created a chroot, then I didn't have the
GC> required permissions on all the files therein, and vice versa;
GC> but I figured that both of us would be able to do anything that
GC> 'nemo' could do.
GC> 
GC> That worked until today. Now:
GC> 
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?

GC> That seems impossible, because nemo's password never expires:
[...]
GC> I tried resetting it, in the hope that desperate measures would work...
[...]
GC> ...but no:
[...]
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.

 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?

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?

 Good luck,
VZ

pgpoQB8H3iCOP.pgp
Description: PGP signature