Auth failure with other control values than "sufficient"

[bjo81]

We are using OpenVPN4UCS to authenticate against privacyIDEA. If we change "sufficient" to "requisite" or analogous [success=1 default=die], openVPNs authentication fails.

But according to the debug output and privacyIDEAs log, the auth request was successful:

Oct 16 13:49:19 vpn openvpn: Authenticating bfr against https://master.foo.bar/privacyidea
Oct 16 13:49:20 vpn openvpn: requests < 1.0
Oct 16 13:49:20 vpn openvpn: privacyidea_pam: result: {u'status': True, u'value': True}
Oct 16 13:49:20 vpn openvpn: privacyidea_pam: offline save authitem: None
Oct 16 13:49:20 vpn openvpn: pam_unix(openvpn:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost=  user=bfr`

[cornelinux]

Can you please provide your PAM config?
I guess this is a debian (UCS) system?

[bjo81]

Yes, an UCS 4.2.

The content of /etc/pam.d/openvpn:

# Warning: This file is auto-generated and might be overwritten by
#          univention-config-registry.
#          Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
#          univention-config-registry überschrieben werden.
#          Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
# 
#     /etc/univention/templates/files/etc/pam.d/openvpn
# 


auth sufficient pam_python.so /usr/share/privacyidea/privacyidea_pam.py url=https://master.bla.foo/privacyidea prompt=OTP:  realm= cacerts=/etc/univention/ssl/ucsCA/CAcert.pem debug



@include ldaponly-auth

@include common-account
@include common-session
@include common-password

[cornelinux]

And if you change sufficient to requisite it fails?

I checked with requisite and required and also this notation:

auth    [success=1 default=ignore]      pam_python.so /lib/security/privacyidea_pam.py
     url=https://localhost/pi prompt=privacyIDEA_Authentication nosslverify
# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so

Everything worked fine.
If you take a look at your PAM log, it is pam_unix which fails.
I very much assume that your substacks somewhere us a try_first_pass or use_first_pass which causes pam_unix to fail.

However, it does not seem to be pam_python.

[bjo81]

I've tried now the following config:

auth sufficient pam_python.so /usr/share/privacyidea/privacyidea_pam.py url=https://master.foo.bar/privacyidea prompt=OTP:  realm= cacerts=/etc/univention/ssl/ucsCA/CAcert.pem debug

# here's the fallback if no module succeeds
auth    requisite                       pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
auth    required                        pam_permit.so

and got

Oct 17 13:31:50 vpn openvpn: Authenticating bfr against https://master.foo.bar/privacyidea
Oct 17 13:31:52 vpn openvpn: requests < 1.0
Oct 17 13:31:52 vpn openvpn: privacyidea_pam: result: {u'status': True, u'value': True}
Oct 17 13:31:52 vpn openvpn: privacyidea_pam: offline save authitem: None
Oct 17 13:31:52 vpn openvpn: pam_access(openvpn:account): access denied for user `bfr' from `console'

So I assume there are no other substacks which could cause this issue.

[cornelinux]

But the last line states openvpn:account so it seems to be denied by the accounting module.

[bjo81]

Sorry for the noise, the issue was caused by using privacyIDEA and ldap_auth. Users logged in with username and password, which increased the failcounter of the corresponding users in PI, so the keys got blocked.