The Okta Credential Provider for Windows prompts usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control. for MFA when signing in to supported Windows servers with an RDP clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. . It supports all Okta-supported MFA factors except Windows Hello and U2F tokens.
Note the following requirements before installing the Okta Credential Provider for Windows:
Proxy Configuration: The Okta Credential Provider for Windows does not support a discrete proxy configuration but will obey system level proxy configurations. To understand management of proxies on Windows Servers, refer to www.technet.com.
- The Windows server used for installation must have an active internet connection with port 443 open.
- The installing account must have administrative rights to install the OKTA Windows Credential Provider AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations., Visual C++ Redistributable and .NET 4.0+.
- End usersIn Okta literature, we generally refer to "end users" as the people who have their own Okta home page (My Applications), using chiclets to authenticate into all of their apps. End users do not have any administrative control. When we refer to "users" we are generally referring to the individual(s) who have administrative control. must have enrolled their MFA tokens previously, by choosing an MFA option for their account when signing in to Okta the first time or after a reset. End user cannot enroll a token during an RDP sign in. End users with unenrolled tokens receive an authentication failed response from Okta when attempting to sign into an RDP server.
For information on enabling TLS 1.2 in .NET and in Microsoft Internet Explorer browsers, see Okta ends browser support for TLS 1.1.
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2008
- Windows Server 2008 R2
Sign in to Okta and verify or set up policies. Install the agent on the Windows server and return to Okta to create an appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. and assign users. Test the setup once the installation has been successful. The installation contains three major installation steps and one testing step. Be sure to complete the testing after the installation.
Before installing the Okta credential provider for Windows, your orgThe Okta container that represents a real-world organization. must have the following three items configured.
- Configured MFA factors that include the factor to use for RDP sign in. For instructions, see MFA.htm.
- A group for the end users who will authenticate RDP sign ins. For instructions, see Group Types Used in Okta.
Add the Microsoft RDP app
On the Applications page, select Add Application and enter Microsoft RDP (MFA) in the search box. Then, add the application. On the General tab, assign any desired application label. You can assign people to the app now or later, as described in step 3, below.
Org admins need to ask Okta Support to provide them with the download link for OKTA Windows Credential Provider Agent (version 1.1.3). After obtaining the file, complete the following four steps. During the installation process, keep Okta open in another window on the Microsoft RDP (MFA) application screen. You can perform a standard installation or a silent installation.
On the Windows server, extract the files from the .zip archive provided to you by Okta Support and run Setup.exe. Follow the prompts to complete the installation.
Note: The package contains the C++ installer. The installer prompts your to install it if it is not present, or to repair it, if it is present. Then, the installer prompts for the Visual C++ 14 Runtime Libraries, as shown below. Screenshot
During the installation, two App Configuration screen display appear. The first requests a client ID, a client secret, and an Okta URL, as shown below. Screenshot
To obtain this information, return to the Microsoft RDP (MFA) app in Okta. On the General tab, scroll down to the Client Credentials section to see the values for the client ID and the client secret. The Okta URL is the URL your org uses to reach Okta in the format
Enter this information in the App Configuration screen, shown above and click Next. Then, click Next and Close to complete the installation.
- In the second App Configuration screen that opens, select from the following two options, as shown below.
- Filter Credential Provider – this option provides a workaround when multiple credential providers are installed on a server. If selected, this option makes the Okta MFA Credential Provider the only method for applying MFA to RDP connections and does not permit unauthenticated users to select which credential provider to use.
- RDP Only – By default, the installed credential provider inserts Okta MFA between both an RDP and a local authentication event. Checking this box will remove Okta MFA from local (interactive) logons.
To verify the installation, lock the machine. In the sign-in screen that appears, verify that the Okta icon appears as a sign-in option, as shown below on a Windows Server 2012 R2. The screen is slightly different in Windows Server 2016. Screenshot
Extract the files from the .zip archive.
- On the Windows server, run the following command from the
vcredist_x64folder of the unzipped archive.
vcredist_x64.exe /install /quiet /norestart
Run the following command to install Okta Windows Credential Provider silently.
msiexec /qb /log log.txt /i OktaWindowsCredentialProvider.msi CLIENT_ID="cid" CLIENT_SECRET="cs" OKTA_URL="https://a.b.c"
CLIENT_ID– find this value on the General tab of the Microsoft RDP (MFA) application in Okta. Can also be edited manually in the RDP agent config file.
CLIENT_SECRET– find this value on the General tab of the Microsoft RDP (MFA) application in Okta. Resetting the ClientSecret will require reinstallation of the agent as the value in the config file is encrypted. Can also be edited manually in the RDP agent config file.
OKTA_URL– Your org URL. Must use the format https://org_name.okta.com. HTTPS is required. Also supported are *.oktapreview.com or *.okta-emea.com.
Modify additional properties
In addition to the parameters you added in the previous step, you can modify the following properties to ensure MFA is always enforced.
Property Definition Default Value Suggested Value
This property provides a workaround when multiple credential providers are installed on a server. If true the Okta MFA Credential Provider is the only method for applying MFA to RDP connections and does not permit unauthenticated users to select which credential provider to use.
Setting FilterCredentialProvider to true and RdpOnly to false will cause the agent to prompt for MFA if required by the policy.
Sets authentication flow behavior if network connectivity is lost. When true, a user attempting to authenticate across RDP is not challenged for MFA and is granted access based on password alone; when false, a user attempting to authenticate across RDP is not granted access because the credential provider cannot reach the Okta service.
InternetFailOpenOption governs proper access if the target machine does not have Internet access for MFA.
Set this property to true if Internet connectivity is a frequent issue.
By default, the installed credential provider inserts Okta MFA between both an RDP and a local authentication event. Setting this property to true removes Okta MFA from local (interactive) logons.
Setting FilterCredentialProvider to true and RdpOnly to false will cause the agent to prompt for MFA if required by the policy.
The number of seconds before timeout. To prevent the possibility that Windows might close the RDP session, this value must be smaller than the idle timeout set in Windows. 60 30
The timeout after which the RDP session is closed when an error message is displayed. 30 30
Enforce timeout for both Windows 2012 and 2016. false true
Validate the public key of the Okta server to which the agent is connecting. true true
To modify these properties, edit the file
rdp_app_config.jsonthat is typically located in the
C:\Program Files\Okta\Okta Windows Credential Provider\configfolder, or use the following power shell script.
You can run this script from the same location you ran the installation in step 2, above.
Note: This script was test with Powershell versions, 3, 4, and 5. To find the version of Powershell on your system, use
After completing the installation, you can configure the behavior of the authentication flow if network connectivity is lost.
To make this specification, edit the file
rdp_app_config.json that is typically located in the
C:\Program Files\Okta\Okta Windows Credential Provider\config folder. Toggle the InternetFailOpenOption value to one of the following values.
true – if internet connectivity is lost, a user attempting to authenticate across RDP is not challenged for MFA and is granted access based on password alone.
false – if internet connectivity is lost, a user attempting to authenticate across RDP is not granted access because the credential provider cannot reach the Okta service.
Note: You can also modify any of the other properties listed in Step 4 in the Silent Installation section, above.
To ensure that MFA works as expected, verify that the Okta sign in session times out before the Windows session.
Note the following:
- By default, the Okta widget timeout session is set to 60 seconds.
- Determine the timeout duration in your Windows environment then set the session timeout duration for the Okta widget to be shorter than the Windows timeout session.
Important: Set up a test in the environment by manually timing the session duration for both Windows and Okta to ensure that the timeout duration specified for each work as expected.
To configure the Okta widget timeout session duration:
- Navigate to
C:\Program Files\Okta\Okta Windows Credential Provider\config
- Edit the following file using an editor of your choice:
- Add the following properties and values to the file. Delineate each entry with a comma:
Note: You may specify another value for timeout as long as it is lower than your Windows session timeout duration.
If you have users that do not need to provide MFA to sign in to the server, assign them to the app, but exclude them from the app-based sign on policy for the Microsoft RDP (MFA) app. The App-SignOn Policy is the only policy that is relevant to the Microsoft RDP App.
In the Microsoft RDP (MFA) app in Okta, select the Sign On tab. In the Settings section, select Edit and choose the Application username format to assign to users of this app. In the example below, AD SAM account name is chosen, but you can make any choice.Screenshot
Important: When the end user signs in to the Windows server, the application user format must match exactly.
Select the Assignments tab and assign the app to users or groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups.. After selecting Assign, enter the user name. For more information on assigning apps, see Assign Applications.
Important: The user name entered here must match the format you selected in the preceding step. For example, in the case that the full UPN for a user is in the format
firstname.lastname@example.org, and you entered AD SAM account name for the username format above, enter only the name portion of the UPN for the user name. The @yourorg.com portion of the UPN is included in the AD SAM account name.
Select Done when finished. Your system is completely configured.
This verification process is the end-user sign in process.
Sign in to a machine which has the RDP client installed. Be sure that this machine can connect to the server into which you want to make a remote connection.
Enter the server name for the RDP client, your username, and password and then, click Connect.
In the RDP sign in screen that opens, sign in as the user that has the Microsoft RDP (MFA) application assigned in Okta.
Important: In both cases, the value for
usermust match the user name that was used when the app was assigned in Okta.
All users, including those that just set up MFA in the preceding step, are prompted to choose the MFA factor to use for authentication.
After providing the second factor, verify the RDP connection to the Windows server. If you cannot sign in, see the Troubleshooting section below.
If you see the MFA Bypass screen shown below when signing into the server, verify in Okta that the user is included in an MFA policy. Screenshot
Note: An App-SignOn Policy is the only policy that is relevant to the Microsoft RDP App.
If you see the Display Failed screen shown below when signing into the server, verify the following: Screenshot
- The client ID, the client secret, and the Okta URL are configured correctly.
- The username entered into the Windows server sign in matches the username in Okta.
If you cannot RDP into a server, verify that it is setup to accept remote connections in the System Properties screen, as shown below. Screenshot