Hello! I’m not sure if this will help because I’m not sure if your Duo Unix and Winbind problem is that same as mine. I couldn’t find any other articles talking about it.
The problem I’m having is that Winbind’s PAM configuration generally sees the user of pam_unix.so try_frist_pass and Winbind is below that with user_first_pass. This means that when you login PAM first tries to login to a local Unix account and if that fails Winbind will try the password the user provided without prompting for the password again.
The “problem” is that if I follow the Duo Unix guide to the letter it sees me marking pam_unix.so from sufficient to required and then adding sufficient for duo_unix.so under pam_unix.so. In a perfect world this basically says for dou_unix.so to exit successfully that duo_unix.so must have not failed. Since I’m using Winbind any of my AD users will fail because they don’t have local Unix accounts but instead domain accounts.
The crux of my problem is that it would simply be easy to comment out pam_unix.so and put pam_winbind.so at that line and mark it as required. The issue there is that means local accounts will no longer be able to login.
My solution was to keep pam_unix.so sufficient, mark pam_winbind.so requisite and mark pam_duo.so as sufficient. Note my auth block from /etc/pam.d/system-auth is for a Centos 7 machine so anyone following my advise may need to make changes for their system.
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_winbind.so cached_login use_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient /lib64/security/pam_duo.so
auth required pam_deny.so
In this way if a local user were to successfully login to the system then pam_unix.so would exit the stack successfully and not continue. This comes with the caveat that local users cannot have MFA. For us this is an acceptable compromise we already heavily restricted root and never login as local users unless it was one off anyway.
As sufficient only exits on success and logs an optional failure remote users continue down the stack to pam_winbind.so which is requisite in my case because I decided I didn’t want any brute force attack pinging my users with push notifications at all hours. For some administrators required would be a perfectly good solution here, especially for non external facing equipment. The pros for requisite is that it will exit on failure so the stack never makes it to duo_unix.so and sends the user a push notification for approval. The cons for requisite is that the password can be tried with output that would indicate a success or failure. The reverse are true for required.
Finally duo_unix.so is marked sufficient and pam_winbind.so needed to have succeeded for duo_unix.so to work.
I hope this helps you, or someone else like me, trying to solve this situation.
For anyone who’d like to go down the PAM rabbit hole a bit deeper there are granular controls over just binding, include, required, requisite, sufficient and optional e.g. success=ok|done and/or default=bad|die|ignore. It’s all just a logic game.
required
[success=ok new_authtok_reqd=ok ignore=ignore default=bad]
requisite
[success=ok new_authtok_reqd=ok ignore=ignore default=die]
sufficient
[success=done new_authtok_reqd=done default=ignore]
optional
[success=ok new_authtok_reqd=ok default=ignore]
