Duo Auth Proxy appears to be failing all logins after 10 seconds. Why?

[dee3]

My Duo Auth proxy appears to be failing all of my ssh logins after a 10 second interval. The timeout starts when the (console) user hits [ENTER] on their password, to the time they hit accept on the duo push. I’ve increased all timeouts I can find on my auth chain to 60 seconds but the 10 second fail still persists.

the [ad_client] stanza in my authproxy.cfg contains a timeout of 60 but the default is 10. I’m wondering if something is messed up here because this is the only 10 second timeout I can find anywhere.

Right when the ssh server logs pam_ldap: ldap_result Timed out in syslog, this message is logged in the auth proxy’s authproxy.log file:
Received extraneous LDAP PDU while resolving a BindRequest: LDAPMessage(id=5, value=LDAPBindRequest(version=3, dn=’’, auth=’**’, sasl=False), controls=None)

If I drop the user into bypass mode in the Duo admin panel, the problem isn’t there but not sure that means anything since there is no incorporated token or lock-screen delay after entering a password.

I can simulate a network “outage” to test the ssh server timeout by firewalling the connection to the auth proxy on the OUTPUT chain right before the password is entered. After 60 seconds of waiting around, syslog notes a failed auth attempt. This seems to suggest the 10 second issue is still upstream (auth proxy or LDAP servers).

Can someone offer some insight as to what might be going on here? Is the timeout in authproxy.cfg being ignored somehow and defaults being used?

[DuoKristina]

Can you share more about your PAM setup, like which distro and LDAP module?

[dee3]

Anything specific to PAM? The /etc/pam.d files are all stock except we enable pam_access.so in /etc/pam.d/sshd to allow use of ACLs in /etc/security/access.conf. I have included a network diagram and pertinent pam_ldap configs along with nslcd config. All hosts are running Ubuntu 16.04, except for AD obviously.

[1]
IP (LAN): 10.10.10.10
OpenSSH: 1:7.2p2-4ubuntu2.8
/etc/ldap.conf

uri                    ldap://10.10.10.199
base                   dc=myorg,dc=mydom,dc=edu
nss_base_group         ou=groups,dc=myorg,dc=mydom,dc=edu
ldap_version           3
pam_password           md5
ssl                    start_tls
TLS_CACERTDIR          /etc/ssl/certs
ldap_version           3
pam_password           crypt
pam_login_attribute    uid
tls_reqcert            never
bind_timelimit         60
timelimit              60
referrals              no
pam_groupdn            cn=xxx_ldap,ou=groups,dc=myorg,dc=mydom,dc=edu
nss_initgroups_ignoreusers avahi,avahi-autoipd,backup,bin,colord,cyrus,daemon,debian-spamd,dnsmasq,dovecot,dovenull,freerad,games,gdm,gnats,haldaemon,hplip,irc,kernoops,landscape,libuuid,list,lp,mail,man,memcache,messagebus,mysql,nagios,news,ntp,nx,openldap,polkituser,postfix,proxy,root,saned,sshd,statd,stunnel4,sympa,sync,sys,syslog,uml-net,unscd,usbmux,uucp,whoopsie,www-data,xrdp

/etc/nslcd.conf

uid nslcd
gid nslcd
uri ldap://10.10.10.199
base dc=myorg,dc=mydom,dc=edu
ssl start_tls
tls_reqcert allow
nss_initgroups_ignoreusers ALLLOCAL
idle_timelimit 60

---

[2]

IP (LAN): 10.10.10.199 (DMZ/NAT): 192.168.1.39
Duo Auth Proxy: 3.2.2
files /etc/ldap.conf and /etc/nslcd.conf are the same as [1] except for uri

uri                    ldap://192.168.1.21,ldap://192.168.1.22

running /opt/duoauthproxy/bin/authproxy_support shows
[info] No issues detected

---

[3][4]

IP (DMZ): 192.168.1.21
IP (DMZ): 192.168.1.22
slapd: 2.4.42+dfsg-2ubuntu3.7
files /etc/ldap.conf and /etc/nslcd.conf is the same as [2] since they can round-robin if one server is down

/etc/saslauthd.conf

ldap_servers: ldaps://ldap.xxxxxx.org
ldap_search_base: dc=otherdc,dc=xxxx,dc=xxxx,dc=edu
ldap_filter: (sAMAccountName=%u)
ldap_bind_dn: xxxxxxxxxxxxxxxxxxxxxxx
ldap_password: xxxxxxxxxxxxxxxxxxxxx

---

[5]

offsite box I do not manage. Only used for SASL passthrough (saslauthd) of user password.

[dee3]

@DuoKristina any further info I can supply that that may help diagnose the issue?

[DuoKristina]

I’m not aware of any 10 second timeout in our products that could cause this, so I suggest looking deeper at the config of your LDAP module. For example, the nslcd module has 10 second bind_timelimit and reconnect_retrytime defaults.

[dee3]

Thanks.

Hrm…I’ve increased every timeout I can find (including the ones you mention) in nslcd.conf and ldap.conf on both the auth proxy and the ssh server. Nothing seems to have changed. Of note, I’m not seeing any traffic (tcpdump) between the auth proxy and ldap server when the timeout happens. Only between the auth proxy and ssh server so I think the issue is somewhere between those two.

Could you elaborate a little on what this message in the auth proxy log means? It seems to happen right when (maybe right before) the ssh server logs the pam_ldap: ldap_result Timed out message.

2020-05-11T08:18:57-0500 [ldap_server_auto,1,10.10.10.10] Received extraneous LDAP PDU while resolving a BindRequest: LDAPMessage(id=5, value=LDAPBindRequest(version=3, dn='', auth='****', sasl=False), controls=None)

[dee3]

For anyone else running across this, I think I found the 10 second timeout issue. I ended up downloading the pam_ldap source for Ubuntu 16.04 and found a hard-coded 10 second timeout in there. Changing the code using the commit above seems to resolve the issue after building the source.