Install or Upgrade Duo Authentication for Windows Logon

原文：Install or Upgrade Duo Authentication for Windows Logon — theDXT (Daniel Keer)

In this post, I will show you how to use my Duo Authentication for Windows Logon PowerShell scripts to check whether Duo Win Logon is installed, install Duo Win Logon, or upgrade Duo Win Logon.

How Duo Authentication for Windows Logon Works

Duo Authentication for Windows Logon installs a credential provider on the Windows client. Rather than replacing the built-in password provider, it chains after it. When a user logs on at the console or over Remote Desktop, Windows validates the username and password exactly as it did before Duo was installed, and only after that succeeds does the Duo provider ask for a second factor: a push, a phone call, a passcode or a hardware token. A wrong password still fails at the Windows stage, before Duo is ever consulted, so the product strengthens the logon rather than replacing any part of it.

A few consequences of that design are worth knowing before you deploy it:

• The setting that decides whether the second factor applies to console logons as well as Remote Desktop is RDPONLY. With RDPONLY="0" every interactive logon is protected; with RDPONLY="1" only remote sessions are.
• Installation settings are written to the registry under HKLM\Software\Duo Security\DuoCredProv. If you manage the client through the Duo Group Policy templates instead, those values live under HKLM\Software\Policies\Duo Security\DuoCredProv and take precedence over the local ones.
• When a user switches accounts through a UAC elevation prompt, Duo does not treat it as a remembered session and the second factor is requested again for that account.
• The client writes a duo.log file in the Duo Security program folder, which is the first place to look when a logon behaves unexpectedly.

Prerequisites for a Fleet Deployment

Before you start, line up the following:

• A Duo application of type RDP in the Duo Admin Panel, which gives you the integration key (IKEY), secret key (SKEY) and API hostname (HOST). The secret key is a credential in its own right, so store and distribute it the way you would any other secret.
• Local administrator rights on the client, or a deployment tool that has them: Intune, Configuration Manager, Group Policy, or a scripting tool.
• Microsoft Visual C++ 2022 Redistributable. Versions 4.3.16 and later of Duo for Windows Logon depend on it, and this dependency is the single most common reason an MSI deployment ends up with a client that installs but does not authenticate.
• Decisions already made about fail-open versus fail-closed, auto-push, smart card support and whether console logons are protected. Changing these later means editing the registry or reinstalling, so agree them first.
• A break-glass plan. If you deploy Duo with the wrong keys and fail-closed, you can lock yourself out of the machine. Duo ships a documented escape hatch: boot into Safe Mode and unregister the credential provider from an elevated command prompt.

regsvr32 /u "C:\Program Files\Duo Security\WindowsLogon\DuoCredProv.dll"
regsvr32 /u "C:\Program Files\Duo Security\WindowsLogon\DuoCredFilter.dll"

On installs of Windows Logon 2.0.0.42 and earlier, the same DLLs live in C:\Program Files\Duo Security\DuoCredProv\ instead. Re-register them without the /u switch to turn protection back on. For the server side of the same stack, the companion post Duo Authentication Proxy Upgrade covers the RADIUS and LDAP proxy, and Windows Admin Center SSO covers single sign-on for administration portals.

Why the EXE Installer Replaced the MSI Approach

Previously, I wrote the blog post Upgrading Duo Authentication for Windows Logon. That blog post covered how to upgrade Duo Win Logon using the MSI. However, later on, Duo changed Duo Win Logon enough that the application now requires Microsoft Visual C++ 2022 Redistributable, which is not bundled with the MSI installer but is bundled with the EXE installer.

Another limitation of the MSI deployment is that you need to create a transform file to silently install Duo Win Logon. With the EXE installer version of Duo Win Logon, you can specify everything with silent install arguments.

Silent Install Arguments Explained

The EXE installer accepts a full set of parameters, which is what makes it suitable for automated deployment without a transform file. The parameters are passed through the InstallShield wrapper to the underlying Windows Installer package, so the whole set sits inside one /V" ... " argument:

duo-win-login-5.2.1.exe /S /V" /qn IKEY="DIXXXXXXXXXXXXXXXXXXXX" SKEY="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" HOST="api-xxxxxxxx.duosecurity.com" AUTOPUSH="#1" FAILOPEN="#1" SMARTCARD="#0" RDPONLY="#0""

Note that the parameter names are case-sensitive, and that DWORD values are prefixed with a pound sign, for example RDPONLY="#1". Getting either of those wrong does not always produce an error, which is why a functional test at the end of the deployment matters.

Every one of these can also be supplied later through the Duo Group Policy templates rather than on the command line, and the values stored under the policy key override the local ones. Duo publishes the complete current list of switches in its support article on silent installation, so check it before you assume a setting has not been added.

The PowerShell Scripts

Duo-Win-Logon-Checker.ps1

The first PowerShell script checks if Duo Win Logon is installed and reports its version. It is a refactored version of the duo-checker function from the Duo Win Logon MSI upgrade script.

The script uses the Prog-Finder function from the Install Matrix project.

It also tells you if the version of Duo Win Logon is old. For the old version detection to work correctly, you will need to edit the NewVersion variable. You can check for Duo Win Logon releases by reviewing the Duo Win Logon release notes.

Duo-Win-Logon-Install.ps1

This script uses various functions from the Install Matrix project to install Duo Win Logon.

For this script to work, you will need to edit the InstallArgs variable.

Example

[string]$InstallArgs = '/S /V"REBOOT=ReallySuppress /qn IKEY="IKEY_HERE" SKEY="SKEY_HERE" HOST="API_HOST_HERE" FAILOPEN="#0" RDPONLY="#0""',Code language:PowerShell(powershell)
* Replace IKEY_HERE with your Duo Win Logon IKEY.
* Replace SKEY_HERE with your Duo Win Logon SKEY.
* Replace API_HOST_HERE with your Duo Win Logon API hostname.

The other arguments are to ensure Duo Win Logon fails closed if the Duo API can’t be reached and to protect RDP and console logins.

If you want to add more options, here is the Duo support article that lists all the silent switches.

The script also uses the always-current URL for Duo Win Logon, which is https://dl.duosecurity.com/duo-win-login-latest.exe

Duo-Win-Logon-Upgrade.ps1

This script combines Duo-Win-Logon-Checker and Duo-Win-Logon-Install into a single script that first checks whether Duo Win Logon is installed, then checks whether it is an old version. If it is an old version, it upgrades Duo Win Logon.

You will also need to set the NewVersion variable to the Duo Win Logon version you are upgrading to.

As with the Duo-Win-Logon-Install script, you will need to edit the InstallArgs variable. Replace IKEY_HERE, SKEY_HERE, and API_HOST_HERE with the values needed for your Duo Win Logon deployment.

Verifying the Deployment

Installed is not the same as working. Verify the installed version, the configuration values and the credential provider registration.

The version that Windows thinks is installed comes from the uninstall registry keys. Checking both the 64-bit and 32-bit hives avoids surprises on older builds:

$paths = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty $paths -ErrorAction SilentlyContinue |
  Where-Object { $_.DisplayName -like 'Duo Authentication for Windows Logon*' } |
  Select-Object DisplayName, DisplayVersion

Then confirm the settings actually landed. Dump the Duo configuration key, and the policy key if you manage the client through Group Policy:

Get-ItemProperty 'HKLM:\SOFTWARE\Duo Security\DuoCredProv' | Format-List *
Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Duo Security\DuoCredProv' | Format-List *

Finally, check the version of the credential provider DLL itself, which tells you what will actually run at the logon screen rather than what the installer registered:

Get-Item 'C:\Program Files\Duo Security\WindowsLogon\DuoCredProv.dll' |
  Select-Object -ExpandProperty VersionInfo |
  Select-Object FileVersion, ProductVersion

With all three confirmed, log on locally and over Remote Desktop on a pilot machine, complete a push, and check that a remembered device behaves the way you intended. If anything fails, read duo.log in the Duo Security program folder before changing any settings.

Rolling the Change Out at Scale

The scripts are designed to be dropped into whatever deployment tool you already use. A few rules keep the rollout uneventful:

• Deploy in rings. Start with a pilot group, then IT, then the wider estate. A single machine you can physically reach is enough to prove the configuration before it reaches hundreds of clients.
• Let the deployment tool do the version decision rather than doing it yourself. The upgrade script already checks whether the product is installed and whether the installed version is older than the target, so a scheduled task or an Intune detection rule can run it repeatedly and safely.
• For Intune, package the EXE as a Win32 app with the silent argument string as the install command, and use the file version of DuoCredProv.dll as the detection rule. That way the client reports as compliant only when the current build is actually present.
• Suppress the reboot in the installer, but plan the reboot anyway. The credential provider cannot be fully swapped while users are logged on, and users should not be logged out mid-session by a surprise restart.
• Keep an offline copy of the installer, the argument string and the unregister commands in your build documentation, so the next person can reproduce or back out the change without guessing.

Troubleshooting

The Duo prompt never appears

Check that the credential provider DLLs are registered. If a previous removal left them unregistered, registering them again from an elevated prompt restores the prompt at the logon screen.

The client installs but authentication fails

Dump the configuration registry key and confirm IKEY, SKEY and HOST are present and correct. An installation without those values, for example an MSI deployed without a transform and without a Group Policy supplying them, installs successfully and then does not function at all.

The MSI deployment worked before and does not now

This is almost always the Visual C++ 2022 Redistributable. The EXE installer bundles it, the MSI installer does not. Either deploy the redistributable alongside the MSI or move to the EXE installer as described in this post.

The upgrade removed settings that were created after the original install

There is a known issue in the 5.2.0 installer where a silent upgrade can remove registry keys created after the initial installation, which affects offline access enrolments and passwordless logon state. Do not silently install that specific build; use a later release.

Logons feel slow

Auto-push sends the request to the first capable device attached to the user. If that device is an unused tablet sitting in a drawer, users wait for the push to time out. Turning auto-push off, or letting users choose their factor, is usually faster in practice on mixed estates.

Summary

To avoid unexpected reboots during a Duo Win Logon install or upgrade, both Duo-Win-Logon-Install and Duo-Win-Logon-Upgrade scripts suppress the reboot requirement. You should still plan a reboot during your maintenance window.

All three scripts can help you install or upgrade Duo Authentication for Windows Logon. I have used each for various installations and upgrades.

You can find all 3 scripts on my GitHub.https://github.com/thedxt/Duo

As a checklist for the next deployment: confirm the RDP application exists and you have the IKEY, SKEY and HOST; run the installer silently with the argument string that matches your policy; verify the version, the registry values and the DLL, then log on locally and over RDP before the change is closed.