-
Notifications
You must be signed in to change notification settings - Fork 138
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: default PAM / authselect profiles #218
Comments
If there is interest in this feature I would be happy to write the code and issue a pull request. |
This is an older feature request, but I agree this is needed. We deploy IPA on an HPC cluster and activating ipa disables Duo upon enrollment. AUTH profiles do a great job of decreasing the risk of really messing up your PAM configuration. I know certain admin (me) who's initial setup disabled password authentication in favor of just using duo. Oppps... |
Thanks for the offers and interest, but we are unlikely to proceed with this feature request. On paper this seems like a great idea. However, multiple years of handling questions from customers about their PAM stacks has taught us that Duo trying to be helpful with PAM configuration actually just makes things worse. It seems like every customer wants something different from their PAM stack; while the authselect templates address that, it requires those admins to have to understand both the authselect mechanisms and the resultant PAM stack in order to configure their system appropriately. So instead, many admins, in a rush, just copy anything Duo provides and this leads to a worse outcome for both them and us. That being said, if there's a way to introduce authselect profiles in a way that makes it easier for admins to get the correct PAM configuration, while having to understand PAM and authselect less, that would be ideal! |
Aaron,
There are two issues here.
The first is that duo's documentation is flat out incorrect here as
authselect is a default part of the RHEL 8 stack, and thus modifying pam
files directly *will* result in breakage at some future point. The manner
and timing of that breakage are both hard to predict, making this pretty
much the most obnoxious sort of stealth misconfiguration.
The second issue is precisely that everyone's stack is different, and a
blanket suggestion "insert this line into your pam" is not going to
generally work. However, authselect ships 3 standard profiles and those are
good starting points for one or two custom profiles.
If Duo were to suggest and maintain two basic profiles-- local auth, and
SSSD-- and were to clearly explain what they do and that they don't cover
every use case (e.g. smartcards), you would cover 95% of use cases while
also enabling people to try the profile out without potentially breaking
their auth stack and locking themselves out.
Given Red Hat's strong commitment to auth select, this seems somewhat
mandated by the choice of supported platform anyways.
…On Fri, Jan 20, 2023 at 2:31 PM Aaron ***@***.***> wrote:
Thanks for the offers and interest, but we are unlikely to proceed with
this feature request.
On paper this seems like a great idea. However, multiple years of handling
questions from customers about their PAM stacks has taught us that Duo
trying to be helpful with PAM configuration actually just makes things
worse. It seems like every customer wants something different from their
PAM stack; while the authselect templates address that, it requires those
admins to have to understand *both* the authselect mechanisms and the
resultant PAM stack in order to configure their system appropriately. So
instead, many admins, in a rush, just copy anything Duo provides and this
leads to a worse outcome for both them and us.
That being said, if there's a way to introduce authselect profiles in a
way that makes it *easier* for admins to get the correct PAM
configuration, while having to understand PAM and authselect *less*, that
would be ideal!
—
Reply to this email directly, view it on GitHub
<#218 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGLX3NVR6H2BBZHIFIMAJLWTLRXNANCNFSM5PERWGSQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Basically what @breakwaterlabs said in their prior comment, but from the Ubuntu perspective. Ubuntu uses You can read more about this at https://wiki.ubuntu.com/PAMConfigFrameworkSpec Authselect and pam-auth-update were created specifically to do what @AaronAtDuo mentioned in his last comment:
|
Out of the box, the CentOS / RedHat (and I assume Debian, etc) packages do not configure PAM for 2fa. Instead, the documentation instructs the user to,
This is not only vague and unhelpful for many administrators (who may not frequently visit PAM and its eccentricities), it is incorrect on systems like RHEL / CentOS / Rocky 8 where authselect controls the /etc/pam.d directory and all of its files. In particular, someone modifying e.g.
/etc/pam.d/system-auth
to require 2fa may find that their change gets overwritten on a system update or on enabling smartcard login when authselect helpfully reapplies the current profile.A better option-- at least on RPM systems-- would be to ship an authselect profile at
/usr/share/authselect/duo
or/etc/authselect/custom/duo-local
. Authselect allows creating option-driven PAM templates; as an example, take the following snippet from a modified, duo-compatible sssd authselect profile:One can enable this profile with several options, which control the inclusion or exclusion of the corresponding lines. For instance if one were to enable the profile with,
authselect select sssd
, you would get the basic SSSD PAM profile without any of the 'include-if' lines:If you were to enable the profile with
authselect select sssd with-duo
, the resultant PAM file would look something like this:Red Hat has committed to using authselect at least with 8 and on, and creating a custom authselect profile to cover the basic use cases (SSSD, winbind, local) is a minor task that would drastically simplify the process of enabling duo while avoiding pitfalls of conflicting PAM file modification.
The text was updated successfully, but these errors were encountered: