I did a Duo run through a few weeks ago, and to be honest their documentation is usually pretty good. I was spinning this up as a PoC for a client so I thought I’d put my take on the procedure here.
ADFS Duo Pre-Requisites
I already have a Duo Authentication Proxy server setup and my users are enrolled, you will need to set this up first. See the following article;
Log into the the Duo Admin Portal > Applications > Protect an Application > Search for and select Microsoft ADFS > Protect This Application.
Copy the Integration Key, Secret Key and the API hostname to notepad.
Download the Duo AD FA MFA Adapter on your ‘first‘ ADFS server. Enter the information you copied to Notepad, (above). Tick ‘Bypass Duo Authentication when offline’, and because my users are logging on with their Office 365 UPNs, I’m also ticking ‘Use UPN username format’ (SEE USERNAME NORMALISATION NOTE BELOW.)
Note: I only have one ADFS server, if you have an ADFS Server farm you will need to install each one with the SAME shared session key, you can generate one of these yourself in PowerShell with the following commands;
I only have one, so I’ll simply ‘Generate new session key‘ > Finish the install wizard.
Note: If one has already been deployed, and you don’t know the key, go to the ADFS server on which it’s working, and look in the following registry key.
USERNAME NORMALISATION: Because I’m logging users on with UPNs (first-name.last-name.domain-name.com) Back in the Duo Portal under protected applications Microsoft ADFS > Set username normalisation to ‘None” > Scroll down and save the change.
Server 2019 Only: I’m deploying on Server 2019 so I also need to execute the following Powershell command, you will need to enter YOUR API Hostname (you copied above).
Tick ‘Duo Authentication for AD FS {version}’ > Apply > OK.
Relying Party Trust > Here I have my Office 365 trust, yours may be for something else! Edit Access Control Policy.
Click ‘Use Access Control Policy’ > The one I want is ‘Permit Everyone and Require MFA for Specific Group‘. This way I can select who gets 2FA challenged, and I can migrate users slowly into this group once I know they are enrolled, (also I use the same group to Sync the users to Duo to make things simple). Change the <parameter> and locate you domain security group.
Now when the users connect to ADFS, after they logon, they are challenged to provide 2FA authentication.
like so;
Related Articles, References, Credits, or External Links
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;
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
This was asked as a question on Experts Exchange this week, and it got my interest. A quick search turned up a bunch of posts that said, yes this is possible, and you deploy it with FreeRADIUS and it works great. The problem was, a lot of the information is a little out of date, and some of it is ‘wrong enough’ to make the non-technical types give up. But I persevered, and got it to work.
Disclaimer: This is not an exercise in deploying AnyConnect, I’ve got that covered to death all over the website, use the search function above, or simply go to the following article;
So before proceeding I’ll assume you have AnyConnect setup, and you can connect with a local username.
Disclaimer 2: Please don’t email me with questions like, “Can I take this and integrate it with Active Directory, eDirectory” etc. Or “I’m trying to get this to work with ‘insert name of some Linux distro” and I’m getting an error.
Prerequisite: You will need to have the Google-Authenticator app on a device, (probably an IOS or Android phone), and have that running, and ready to accept a new identity/account.
Solution
Setup FreeRADIUS
I’m not a Linux guru, I just downloaded the latest version of Ubuntu Server (16.04.1 at time of writing). and deployed it as an ESX host.
Non Linux Types Note: A lot of the commands below require you to either be logged on as root, or ‘su‘ to root, (if that’s not an option, you will need to prefix the commands with ‘sudo‘.
Ubuntu Enable Root Account: I quickly learned that these days the root account is disabled, (for sensible reasons). However because of the way FreeRADIUS works, it needs to run under the root account.
[box]
sudo passwd root
ENTER AND CONFIRM PASSWORD
sudo passwd -u root
[/box]
Ubuntu: Install Prerequisites: We need to get all current updates, then install NTP, (because the authenticator keys are time specific). Then there are some tools that we will need to install the Google Authenticator software.
Install Google Authenticator: This is quite cool, (if like me you don’t do a lot of Linux). We need to connect to a folder on a web server, then move into that ‘Directory’ and install the software.
[box]
cd ~
git clone https://github.com/google/google-authenticator.git
cd google-authenticator/libpam/
./bootstrap.sh
./configure
make
make install
[/box]
Configuring FreeRADIUS and Google-Authenticator
Ubuntu has nano installed by default thats what I’m going to use, if you’re a sandal wearing ‘vi’ user, then feel free to use that instead.
First we are going to change FreeRADIUS, so it runs under the ‘root’ account.
[box]nano /etc/freeradius/radiusd.conf[/box]
At the bottom of the file, change the user and group from freerad to root, save the file and exit.
Like so:
Next we are going to create a group called radius-disabled, then if you need to deny a user access, you can simply make them a member of this group.
[box]addgroup radius-disabled[/box]
Then configure FreeRADIUS to reject members of that group.
[box]nano /etc/freeradius/users[/box]
Locate the lines indicated below;
Change and un-comment them, to add the following text;
[box]
DEFAULT Group == "radius-disabled", Auth-Type := Reject
Reply-Message = "Your account has been disabled."
DEFAULT Auth-Type := PAM
[/box]
So it looks like below, then save and exit the file;
Enable Pluggable Authentication Mode (PAM): Edit the following file;
Locate the line with ‘pam’ in it and uncomment it (remove the hash/pound sign), like so
Before;
After;
Exit and save the changes.
Configure FreeRADIUS to use Google Authenticator: Edit the following file;
[box]nano /etc/pam.d/radiusd[/box]
Locate all the lines that start with an ‘@’ symbol and comment them out, (prefix them with a “#”), then paste the following text onto the end of the file;
The easiest way to do this is setup a test user, then create a password for them, then assign a Google-Authenticator Code to that user, on your Linux server;
[box]
adduser tommytester
ENTER AND CONFIRM PASSWORD
su tommytester
ENTER THE PASSWORD
google-authenticator
[/box]
Now you can either scan the QR code into the Google Authenticator app on your phone, or type in the ‘secret-key‘.
Once done, you should be looking at a 6 digit number, that changes every 30 seconds;
Test Authentication on the FreeRADIUS Server first! To do that issue the following command;
Note: the password for tommytester is ‘password‘ and the 6 digit code is added to the end of it, the testing123 value is set within FreeRadius in the /etc/freeradius/clients.conf file.
Successful Authentication
[box]
tommytester@RADIUS-HOST:/home/petelong$ radtest tommytester password302971 localhost 18120 testing123
Sending Access-Request of id 165 to 127.0.0.1 port 1812
User-Name = "tommytester"
User-Password = "password302971"
NAS-IP-Address = 192.168.110.85
NAS-Port = 18120
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=165, length=20
tommytester@RADIUS-HOST:/home/petelong$
[/box]
Unsuccessful Authentication
[box]
tommytester@RADIUS-HOST:/home/petelong$ radtest tommytester password302973 localhost 18120 testing123
Sending Access-Request of id 36 to 127.0.0.1 port 1812
User-Name = "tommytester"
User-Password = "password302973"
NAS-IP-Address = 192.168.110.85
NAS-Port = 18120
Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=36, length=20
tommytester@RADIUS-HOST:/home/petelong$
[/box]
Troubleshooting: If there’s a problem, make sure that the time on the FreeRADIUS server is correct, (is NTP getting blocked at the firewall?) Then what I do is, SSH into the server from another session, and enable debugging, then back at the console test authentication again, then you can see the debugging output on the other screen, which will point you in the right direction.
To enable debugging;
[box]
service freeradius stop
freeradius -XXX
[/box]
Add the Cisco ASA Firewall as a RADIUS Client: You need to add the firewall as a ‘client’ before it can authenticate. Edit the following file;
[box]nano /etc/freeradius/clients.conf[/box]
Add the following test to the end of the file, (cisco123 is the shared secret we will enter on the ASA later);
On the ASA you create an AAA group, set its authentication type to RADIUS, then add the FreeRADIUS server as a host, specify the secret key you used above. REMEMBER you need to specify the ports or authentication will fail, (you get a no response error).
Change AnyConnect AAA Authentication Method: With nothing set, your AnyConnect is probably using its LOCAL database of usernames and passwords, we now need to change it to use the RADIUS host we just setup. You do that in the AnyConnect’s ‘tunnel-group general-attribures’ section. Issue a show run tun command, to see the tunnel groups listed.
[box]
Petes-ASA# show run tun
tunnel-group ANYCONNECT-PROFILE type remote-access
tunnel-group ANYCONNECT-PROFILE general-attributes
address-pool ANYCONNECT-POOL
default-group-policy GroupPolicy_ANYCONNECT-PROFILE
tunnel-group ANYCONNECT-PROFILE webvpn-attributes
group-alias ANYCONNECT-PROFILE enable
[/box]
Then add your RADIUS GROUP as the authentication server.
Later on in the year I’ve got a big RSA and SharePoint deployment, as I know ‘Zippity Squat’ about SharePoint, I thought the best way to get some hands on experience, was to work out how to integrate SecureID with Exchange 2013, (which I know a few things about!)
Solution
I’m assuming you already have RSA Authentication Manager setup and users/tokens deployed. This run though is simply to get your RSA solution working with Exchange/OWA
1. Create a user in Active Directory, (here I’m using SVC_RSA_Access), and ensure that user has a mailbox, you can do this in the Exchange Admin Center, but I prefer to use the shell.
6. We need to have the .Net 3.5 Feature added. (Server Manager > Add Roles and Features).
7. Log onto the Security Console of your RSA Authentication Manager appliance > Access > Authentication Agents > Generate Configuration File > Follow the wizard > Download the file.
8. Place the file you downloaded (sdconf.inf) on the Exchange server in the C:Windowssystem32 folder.
9. Download and install the RSA Authentication Agent for Web for IIS, Install and accept all the defaults, it should locate the config file you have just downloaded.
10. On the Exchange server launch ‘RSA Web Agent’, and don’t be surprised when IIS Manager opens.
