Duo LDAP proxy fails while LDAP direct to Windows AD works fine

[Andrew Duey]

Short version:

Any assistance would be greatly appreciated.  I'm trying to use tac_plus (actually TACGUI using tac_plus) to authenticate our switches against Windows Active Directory.

When using a LDAP proxy to add enterprise standard 2FA tac_plus doesn't like the response and keeps trying to re-authenticate resulting in ~ 30 MFA push requests with 0 successes.  

Long version:

99% of this is working fine, and if I LDAP directly against Windows AD things work as expected.  The last part I need is to add 2FA into the mix.  For this we use Duo Mobile (which might be the greatest 2FA in the world, yes, I drink the kool-aid).  There is an LDAP proxy we use for tons of other LDAP authenticating tools (VPN, helpdesk tickets, remote desktop, firewalls, etc) but for some reason tac_plus doesn't like it.

It appears from the wireshark dumps that Duo LDAP proxy is returning a BIND SUCESS but tac_plus doesn't like it for some reason.  I replied to another thread and Joerg kindly replied and suggested looking at LDAP_CONNECT_TIMEOUT.  I don't think this is the issue because if I put the 2FA system in bypass mode it returns success immediately (in about 500ms).

Also, my version of tac_plus doesn't have the LDAP_CONNECT_TIMEOUT since i'm using the TACGUI package.  I did try to download and install the latest version of tac_plus onto the system and adjusted LDAP_CONNECT_TIMEOUT to 30 but it didn't seem to make a difference.  Since it made TACGUI very mad i rolled the virtual machine back to the previous snapshot so at least TACGUI was happy again.  

I also have a ton of packet captures which I've dissected in Wireshark.  I can clearly see the both LDAP connections (one from tacplus to Duo mobile and Duo Mobile to Windows AD LDAP) running and the result of both of them is bind success.  I also did a packet capture of tacplus to Windows AD (bypassing the Duo LDAP proxy) and see the same result of bind success.  The sessions look very similar and the only difference I can really see is that using the LDAP proxy it takes a minimum of 6 seconds 

If I set Duo to 2FA bypass mode then the response is even faster (sub 1 second) but tac_plus fails.  When in bypass mode I can see that tac_plus hammers the Duo proxy 30 times in about 15 seconds before giving up.  I'm not sure if this is set to 30 times, 15 seconds, or some other metric to when it gives up. I don't have a packet capture of this but I can try to get one.

We use this same LDAP proxy to authenticate the same users in the same groups successfully so I'm scratching my head as to why this hasn't worked.  I've spend about 12 hours now troubleshooting issues.  If someone has an idea to fix it in 5 seconds I'll feel stupid but very grateful!  

Any assistance is appreciated.

--Andrwe

[johol...@gmail.com]

Hello Andrew,

you can try to replace the mavis_tacplus_ldap.pl script with the one out of the DEVEL.202109260929.tar.bz2 package.

That one has the LDAP_CONNECT_TIMEOUT config option. I think the script you are using is a little bit outdated.

Cheers,

Joerg

[Andrew Duey]

Thank you for the suggestion.  Per your suggestion replaced just the mavis_tacplus_ldap.pl script from DEVEL.202109260929.tar.bz2  (just pulled it from the source with wget https://www.pro-bono-publico.de/projects/unpacked/mavis/perl/mavis_tacplus_ldap.pl). The behavior is the same.  I see 31 LDAP requests coming from tac_plus in 15 seconds.  Note: right now the 2FA system is in bypass mode resulting in ultra fast (sub 1 second) responses.  Per wireshark all result in bind success.  

Maybe I'm looking in the wrong spot but in /var/log/tacacsgui/tac_plus/2021/11/authentication/2021-11-10-authentication.log (which are the only authentication.log file) I don't see any failed login errors.  I see other ones coming in as our switch monitoring system is hammering switches with bad logins but I don't see this failed authentications for these LDAP requests.  I'll have to do more digging as to why these LDAP login failures aren't showing up in the authentication.log.

I'm feeling that this isn't a timeout issue -- yet.  Once we disable bypass mode and wait for user input, then I think we'll run up against the 5 second timeout and will have to adjust the LDAP_CONNECT_TIMEOUT.

Again, thanks for your input and ideas!

[johol...@gmail.com]

Have you used the mavistest tool just to be sure your config is ok?

For example

mavistest  /etc/your-path/tac_plus.cfg tac_plus TACPLUS "your-user" "your-password"

[Andrew Duey]

Sorry for the horrendously late reply, the project fell off the radar for a while.  

The command appears to result in a timeout condition with when the DUO LDAP proxy server is specified.  The Duo Proxy gets 30 LDAP auth requests in 15 seconds.  Duo returns an authorized message, yet TACACS/Mavis doesn't seem to like it.  It seems like TACACS+/MAVIS queries twice a second then not getting the expected response hits a timeout.

I ran: 'mavistest -d 2  /opt/tacacsgui/tac_plus.cfg tac_plus TACPLUS "AndrewD" "<<Sanitized>>" '

It only shows the input, no output:

Input attribute-value-pairs:
TYPE                TACPLUS
TIMESTAMP           mavistest-57510-1648094945-0
USER                AndrewD
PASSWORD            <<Sanitized>>
TACTYPE             AUTH

If i change my LDAP server IP to be my AD server then it shows input and output :

Input attribute-value-pairs:
TYPE                TACPLUS
TIMESTAMP           mavistest-57817-1648095093-0
USER                AndrewD
PASSWORD             <<Sanitized>>
TACTYPE             AUTH


Output attribute-value-pairs:
TYPE                TACPLUS
TIMESTAMP           mavistest-57817-1648095093-0
USER                AndrewD
RESULT              ACK
PASSWORD             <<Sanitized>>
SERIAL              D5D+ZqDoAB/jHNa01S3e1w=
TACTYPE             AUTH

Going through my Duo logs it is approving the requests (to test the speed I set Duo to bypass mode).  If I put in the wrong username it hammers Active Directory (Via LDAP) 30 times and locks out the account promptly.

Any thoughts or insight would be appreciated!

--Andrew