First of all: Sorry for the resolution issues with some of the screenshots, this is because of different resolutions on my smartphone and my notebooks!
Based on my Veeam Windows Hardening Script, there are various additional ways to further enhance the security of individual components—and, consequently, the overall security. As previously announced (e.g., at the Veeam User Group Meeting in Munich in November 2024), I would like to explore the possibility of implementing multi-factor authentication (MFA) at the Windows level. To this end, I have conducted several lab tests.
The goal:
In the first step, I want to test two different scenarios:
• Securing RDP logins with MFA
• Securing local logins with MFA
From my professional experience, I have already worked with similar scenarios. At that time, customers opted for Cisco Duo due to its strong price-performance ratio.
I want to emphasize that this is not a product endorsement, but I will focus my tests on the aforementioned solution because I already have hands-on operational experience with it.
Disclaimer:
Important: If the Duo application is installed on a target system and the configuration is incomplete or incorrect, access to the system may no longer be possible. I strongly recommend that every customer thoroughly test this scenario in a lab environment beforehand to prevent any disruptions in production environments.
The official Cisco Duo documentation for RDP configurations should always be reviewed in advance.
Cisco Duo:
Fundamentally, Cisco Duo offers a variety of options to implement a Zero Trust approach. The use of MFA is just one of these possibilities. In general, Cisco Duo provides the following features, among others:
- MFA
- Adaptive access policies
- Device health checks
- Remote access
- SSO (Single Sign-On)
For my test scenario, I created a test account linked to my business email address.
The scenario:
I want to secure a virtual VBR server with Duo. In the case of an RDP login, a second factor should be required for specific accounts.
For this, I am using the mentioned VBR server within my lab, as well as my iPhone as an MFA device, on which I will install and configure the Duo app as part of the test.
The solution should work both online and offline, meaning authentication via OTP should also be possible if the server is not connected to the internet.
Configuration:
1. Creating a Cisco Duo account:
First, a Cisco Duo account must be created to administratively manage the product. This is done via the Duo homepage.
Important: An MFA device is already required when creating the admin account for Duo!
Once the account has been successfully created, you will be redirected to the account homepage:
2. Creating the first, personal user:
From the main menu on the left side, you can navigate to Users to create a new user using a guided wizard:
As is often the case, the username should be unique and consistent:
Entering an email address is required for using the tool and for further registration:
3. Adding a personal MFA device:
Beforehand, the Duo Mobile app from Cisco should be downloaded and installed on the target device. In my example, the device or app is linked to the newly created user via SMS.
In the Users tab of the main menu, a new device can be added by clicking Add Phone on the upper right:
In the next step, I enter my mobile number:
The device is now basically added but not yet properly configured. I strongly recommend assigning a device name to ensure it can be identified, assigned, and managed within the Duo interface. Additionally, the operating system of the mobile device should be selected as the platform:
The preparatory configuration is now complete. You can now link the installed app to the user by selecting Activate Duo Mobile. This is where the interaction with the mobile device begins:
If the app has not yet been installed, you can choose to receive an SMS with a current link to the app for installation:
On the mobile device, you will now receive the following SMS:
You now enter a basic account name, which will be displayed on the device:
The final, completed configuration looks as follows:
Now that the mobile device and the app are properly linked to the user, the current device data is displayed in the Duo web interface:
The device setup is now complete, and you can proceed with the RDP configuration.
Important: A single device can be assigned to multiple users (see below)!
4. Provisioning the RDP application in Duo:
Now, you need to select what exactly you want to configure and protect using Duo. In the main menu, navigate to the Applications section. Use the search bar to look for “Remote Desktop” and select the application by clicking Protect:
The application is now automatically created, and for further configuration, you will need the Integration Key, Secret Key, and API Hostname. These should be carefully noted for later use:
The application policy shown here, “Duo Test,” will be configured in the next step. Since offline authentication (allowing the solution to function even when the internet connection is disabled) is required, the corresponding option must be enabled.
I recommend setting the Prevent Offline Login value to “10” to balance security and usability:
5. Creation an Application Policy:
Within the newly created application, you can create and add a policy. I recommend doing this to establish an additional rights filter for the target systems. The policy can be created and selected using the wizard mentioned above:
As objects and rules within the policy, I have limited my test to Application Policy and Duo Mobile app to define specific values for these two options:
The Authentication Policy specifies that MFA must always be used, with Duo Push as the primary method. Alternatively, multiple options can be defined here to allow authentication using, for example, the Duo Desktop App:
The policy should ultimately be applied to all existing users who use the configured application:
Important: There is a Global Policy that defines various default values. This Global Policy is always applied unless the user belongs to a specific custom group, in which case the custom policy overrides the global settings. In my test, I explicitly do not want to use the Global Policy, so I have created a separate custom policy.
6. Installation of the Windows application on the target system:
Using the Cisco website you can download the corresponding Windows application (Duo Authentication for Windows Logon) and install the software on the target system (in this case, the VBR server):
Here, you need to enter the API hostname that was generated earlier (see above):
Here, you need to enter the Integration Key and Secret Key that were generated earlier (see above):
For testing purposes and during the configuration process, it is advisable to enable the Bypass option. This ensures that login to the target system remains possible even if the internet connection fails. Additionally, other optional settings can be configured as needed:
The Smart Card Support remains disabled in my test:
7. Creating a Duo Account for the local administrator in Duo:
Duo is configured so that every user who wants to log in to the server through the defined authentication methods must be created in Duo. This allows Duo to manage how authentication should occur (e.g., with or without MFA).
Therefore, it is necessary to create a corresponding user in Duo for each system user. In this example, I am securing the local administrator of my Windows system and creating the user following the previously described steps:
Now, the newly created user must be assigned an MFA device. As mentioned earlier, one device can be assigned to multiple users. Therefore, I am using the previously configured “Private Phone” and configuring the new user to authenticate with it:
Using Attach a user, you can select the appropriate user:
The local administrator “admloc” has to be selected:
As confirmation, you can see that the specified device now has two assigned users:
8. Testing the login with Cisco Duo MFA:
After completing the installation, I am now testing the login to the system, starting with RDP authentication:
At this point, Duo intervenes and sends a push notification to request the second factor on the device associated with the user:
On the mobile device, I receive the following push notification:
Important: Since offline login via MFA was enabled earlier, Duo will initially prompt for a Duo Mobile Passcode during the first login for this user. This passcode is required for authentication when the server has no internet connection. An initial internet connection is necessary to set this up.
In my test, I configure the passcode authentication on the same device that I previously set up for online authentication:
After enabling offline login, the initial configuration is complete, and the system redirects to the Windows desktop of the target machine.
At this point, the configuration is finished, but I will also test the offline capability as well as local login (without RDP).
9. Testing login without internet connection (Offline MFA):
As a test, I have removed the default gateway from my Windows server, preventing it from establishing an internet connection. When attempting to log in via RDP, the following message now appears, prompting for offline passcode authentication:
After entering the passcode from my mobile device, I am successfully redirected to the Windows desktop without any issues.
10. Testing local login (without RDP):
I also tested the local login—in my case, via the vSphere console—and the prompt for the second factor is identical to the one displayed during an RDP login:
Further ideas and brainstorming:
Cisco Duo is, in my opinion, an excellent solution for integrating an additional authentication factor, thereby significantly enhancing the overall security of Veeam systems that are not part of an Active Directory domain.
The solution also works within Active Directory environments, but there are additional considerations to take into account regarding the overall security concept.
General Considerations:
- Every local Windows user on a VBR server must be created in Duo to enforce MFA.
- A local administrator can be authorized from multiple devices, allowing trusted administrators to log in using their personal devices.
- Within Duo, users who should have access to the RDP application can be managed through a separate user group, simplifying administration in larger environments.
- A consistent naming convention is essential, as the Duo username must match the local Windows username.
- If a user (e.g., a Break-Glass account) should not require MFA for authentication, the user still needs to be created in Duo. In this case, a bypass option must be set specifically for this user under user configuration.
For a small VBR environment (standalone server without domain membership), the following concept could be applied. One Duo user is created for the local administrator (in my case, “admloc”), along with corresponding personalized users who are granted permissions within Veeam RBAC accordingly:
By the way: If a local user is not created in Duo but still attempts to log in to the system, the following error message appears:
I also recommend using bypass options when deploying Duo on Veeam components (e.g., proxies or repositories). Additionally, all service accounts used to run Veeam should be created in Duo, explicitly labeled as service accounts, and assigned a bypass option.
Duo does not exempt users from the obligation to regularly change passwords!
