duo_unix
duo_unix copied to clipboard
duosecurity
Feature request: default PAM / authselect profiles
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,
modify your system's PAM configuration to include a line like the following...
auth required pam_duo.so
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:
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth required pam_deny.so # Smartcard authentication is required {include if "with-smartcard-required"}
auth required pam_faillock.so preauth silent deny=4 unlock_time=120 {include if "with-faillock"}
auth sufficient pam_u2f.so cue {include if "with-pam-u2f"}
auth required pam_u2f.so cue nouserok {include if "with-pam-u2f-2fa"}
....
....
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass {exclude if "with-duo"}
auth requisite pam_sss.so forward_pass {include if "with-duo"}
auth sufficient pam_duo.so {include if "with-duo"}
auth required pam_faillock.so authfail deny=4 unlock_time=120 {include if "with-faillock"}
auth required pam_deny.so
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:
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
If you were to enable the profile with authselect select sssd with-duo, the resultant PAM file would look something like this:
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth requisite pam_sss.so forward_pass
auth sufficient pam_duo.so
auth required pam_deny.so
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.
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 https://github.com/duosecurity/duo_unix/issues/218#issuecomment-1398839693, 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 pam-auth-update via profiles that are created specifically to prevent future landmines when something else changes the stack the right way - via package provided profiles.
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:
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!
