DuoAuth with Sonicwall and LDAPs

[beyond]

I’m trying to get the Duo proxy configured with ldaps to azure and am wondering how to actually test that ldap is working.

I have the proxy setup right (I THINK) with the certificate in the conf folder. I’m then using ldap auth on port 389 to the sonicwall. On test the sonicwall fails with a cert error to the proxy. My thought was the proxy would use the cert on 636 to contact azure, but the sonicwall wouldn’t need the cert since it’s connecting over on 389 to the proxy.

Is that wrong? I could have the proxy setup wrong but without knowing how to actually test I’m flying blind.

Any ideas?

[DuoKristina]

Without seeing your authproxy.cfg it sounds like you are trying to set up the following:

Sonicwall > LDAP to Duo Proxy > LDAPS to Azure

So, when your client connects to the Sonicwall the proxy will eventually connect to Azure, and need to use that LDAP cert.

Have you enabled debug logging on the proxy to see all operations? https://help.duo.com/s/article/1126

We also have a comprehensive guide to understanding the debug output. https://help.duo.com/s/article/2953

[beyond]

Thank you for your help!

I’ll give the debug a try and let you know how it goes.

[beyond]

Ok so I’ve got the debug on and i see no errors in my log when starting the duo proxy.

If the proxy is not connecting to the ldaps service correctly would this throw an error in the log?

I have the certificate on my sonicwall and went through the steps and got the .pem and .key in the duo conf file. I’m seeing an " unable to get local issuer certificate" error.

I guess my question is does the proxy pass the sonicwall’s request through to the ldap server or does the query hit the proxy then the proxy pass it on? I’m trying to figure out where the certificate is wrong in this chain and am having no luck.

Is there a command to test an ldap lookup through the duo proxy?

Thank you again for your help.

[DuoKristina]

beyond:

If the proxy is not connecting to the ldaps service correctly would this throw an error in the log?

Not at proxy startup. You would only see an error during an authentication attempt.

beyond:

I’m seeing an " unable to get local issuer certificate" error.

You see this in the authproxy.log output? Is the path to the cert and key files correct (or no path needed if you put them in the conf directory alongside authproxy.cfg)? Have you ensured that the key file does not require a password? Is the full cert chain represented in the PEM file (f not known/trusted CAs)?

beyond:

does the proxy pass the sonicwall’s request through to the ldap server or does the query hit the proxy then the proxy pass it on?

This sounds like the same thing twice? Yes, the Sonicwall’s request goes to the proxy and yes the proxy passes the query on to the LDAP server.

beyond:

Is there a command to test an ldap lookup through the duo proxy?

Yes, you can use ldapsearch or an LDAP browser like LDP or Softerra.

If you are stuck please don’t hesitate to contact Duo Support for 1:1 troubleshooting.

[beyond]

Ok so now I’m able to start the proxy service but no ports are being open even after specifying the port=xxx line in the [ad_client] config.

Quick question on this; I’m labbing this with a laptop running windows 10 pro x64. Would this cause any issues for the proxy service?

[DuoKristina]

Note that we specifically support server platforms but you should be able to test on desktop editions. Perhaps the Windows 10 firewall is interfering?

[beyond]

Yeah that sounds right. I’ve moved over to a server 2016 VM and still no ports are being opened.

I think at this point I need to open a ticket with support. Something isn’t right and it doesn’t seem that this proxy has testing tools built in so I’m stuck in the mud.

Thanks for the help!

[beyond]

So now the ports are opening but same issues are happening. It either doesn’t like one of the certificate parts or something else is wrong.

Do you guys have a log reader that parses the log into something a non-duo employee can understand?

[DuoKristina]

We read the logs the same way you do.

Please don’t hesitate to contact Support! However, if you’d rather not do that yet, feel free to post your log output here, taking care to obfuscate any personal info like your ikey, skey, API host name, secrets, passwords, or public IP addresses.