KB ID 0001647

Problem

With the impending ‘turning off’ of cleartext LDAP queries to Windows Server, I wanted to make sure my new Duo deployments were already using LDAPS. I got LDAP deployed very quickly and easily, but making the ‘swap’ to LDAPS proved to be massively problematic.

Normally I find Duo a pleasure to deploy, but their technical documentation just confused me for this and I went running up some blind alleys, and eventually ended up logging a call to Duo to try to get it working. So to save you this pain, read on.

Solution

Firstly your domain controller(s) need to be setup to accept LDAPS queries, SORT THAT OUT FIRST. I’ve covered that in the following post;

Get Ready for LDAPS Channel Binding

In the following section I’ll assume you have LDAP already setup on your Duo ADSync, if this is a new deployment, and you are going straight to LDAPS, then you can ignore this next section.

Duo Existing LDAP AD Sync

It goes without saying, (but I’ll say it anyway,) your ADSync should already be connected, if you’re switching room LDAP!

So your domain controller(s) will be using TCP port 389.

Your transport type will be set to ‘Clear’.

Duo Deploy LDAPS for ADSync

The first thing that held me up was reading the Duo documentation, and wondering what I needed to add to my authproxy.cfg file! The truth is;

YOU DON T NEED TO ADD ANYTHING TO AUTHPROXY.CFG!!

Here’s a copy of mine for reference, you ONLY need the sections highlighted, the additional section on mine was for my Cisco ASA RADIUS client;

Rights and Permissions for Duo Service Account

Note: By default the Duo service on your Duo Auth Proxy server will be running under the LOCAL SYSTEM ACCOUNT. I had problems using this account, so I used the service account specified in the authproxy.cfg file. But there are some rights you need to assign to the account first. On the Auth Proxy server, run secpol.msc > Security Settings > Local Policies > User Rights Assignment > Log on as a service > Add User or Group > Add in your Duo service account.

All domain users should have the following right, but let’s take a ‘belt and braces’ approach! On a domain controller open ‘Active Directory Users and Computers’ > Right click your domain > Properties > Security > Advanced.

Add in the Duo service account, and grant;

• List contents
• Read all properties
• Read properties

Note: They will probably, already be selected.

Finally: Add the Duo service account to the LOCAL ADMINISTRATORS group on the Duo Auth Proxy server, (Server Manager > Tools > Computer Management).

You can now open the services console and change the account the service runs under, to the Duo Service account, (Windows Key + R > services.msc > OK > Locate ‘Duo Authentication Proxy Service’ > Properties > Log On > Change the account to your service account and enter the password.) Then RESTART THE SERVICE.

Change Duo ADSync to LDAPS

To do this you are going to need a copy of your Root CA certificate (in PEM format). If you have Microsoft Certificate services make sure you get a copy of the Root CA cert in Base 64 format, (if you don’t, when you open the Certificate with Notepad, it will link like gobbledegook!)

Open your Cert with a text editor, and it should look a bit like this, copy that, (with no additional spaces on the end!) To the clipboard, you will need to paste it into the Duo Admin Panel in a minute.

In the Duo Amin Portal > Users > Directory Sync > Active Directory > ADSync > Change the port on your Domain controllers to 636 (That’s LDAPS TCP Port 636, so it needs to be open on any firewalls between the Duo Auth Proxy, and the domain controllers!)

Go to Transport Type > Change to LDAPS > Paste in your CA Certs PEM information into the ‘SSL CA Certs’ Section > Save Directory.

Why didn’t you tick ‘SSL Verify Hostname’? Simply because it fails when I do that, I’m assuming the common name on the LDAPS cert on my domain controllers is the hostname of the DC, and not its FQDN, so I needed to leave this unticked.

All being well it should say connected.

Troubleshooting Duo LDAPS

Duo have a tool that will check your domain controller certificates are OK. It’s called acert.exe or you can enable debugging, or use the connectivity tool.

Related Articles, References, Credits, or External Links

NA