[39091] in Kerberos
Re: Always prompting for OTP
daemon@ATHENA.MIT.EDU (BuzzSaw Code)
Tue May 10 14:44:18 2022
MIME-Version: 1.0
In-Reply-To: <8735hhs1om.fsf@hope.eyrie.org>
From: BuzzSaw Code <buzzsaw.code@gmail.com>
Date: Tue, 10 May 2022 14:40:41 -0400
Message-ID: <CAJhaRZ+i0O37fdzNzhg8PXzPtjeEgdmwv_hAT4m2hFv9VVqeoQ@mail.gmail.com>
To: Russ Allbery <eagle@eyrie.org>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Tue, May 10, 2022 at 2:05 PM Russ Allbery <eagle@eyrie.org> wrote:
> BuzzSaw Code <buzzsaw.code@gmail.com> writes:
>
> > A bad side effect of this behavior is that the calling PAM module never
> > gets that OTP value so it isn't available for other modules in the
> > stack, so they too prompt for credentials because they think the
> > password has not been entered yet.
>
> What behavior do you expect here? For the full OTP+password string to be
> carried over to other modules in the stack, or only the password?
>
>
We want the full OTP+password string just passed without modification. It
would also be nice if when we use
try_first_pass/use_first_pass/force_first_pass options with pam_krb5 that
it actually did that in the OTP case without the extra prompt. no_prompt
doesn't help as the password doesn't stay on the stack.
In this use case we're dealing with systems that use OpenPAM vs Linux-PAM
so we don't have any of the more advanced syntax to skip modules. We
can't use 'sufficient' to immediately jump out of the stack as we want some
of the later modules to run.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
