CyberArk Identity Windows Cloud Agent

This topic describes the benefits of enrolling Windows devices with the Windows Cloud Agent, as well as supported machine types and use cases.

Additional licenses might be required to enable this feature. Contact your CyberArk account representative for more information.

Enrolling a Windows machine to CyberArk Identity using the Windows Cloud Agent (cloud-join) provides the following security and convenience benefits.

Benefit

Description

Endpoint authentication

Once the machine is enrolled and configured, users can authenticate (basic authentication or multi-factor authentication) to their machines without depending on direct connectivity (LAN or VPN) to the directory source (for example, Active Directory).

This includes for fast user switching use cases. See https://learn.microsoft.com/en-us/windows/win32/shell/fast-user-switching for more detail about fast user switching.

Adaptive MFA

You can apply authentication policies to enrolled machines to allow or deny authentication based on filters such as IP address, time, date, etc. Refer to Create authentication rules for more information.

Passwordless authentication

Apply an authentication policy to enrolled machines to allow users to authenticate without a password. For example, select SMS and security question(s) as authentication mechanisms.

For AD users, a password is initially required, then stored in CyberArk Identity in an encrypted format. A password is required any time the local password differs from the AD password. For example:

  • the first time an AD user logs in to a workstation when the domain is reachable

  • the password was changed from the Identity User Portal

  • the password was changed from another workstation, or reset on the same workstation ( self-service password reset, change password during login, etc)

  • the password was changed from the domain controller

Certificate-based authentication (CBA) for Windows workstations

After logging in to a cloud-joined workstation, users can access CyberArk Identity without entering passwords or other MFA mechanisms. They simply go to your CyberArk tenant URL in a supported browser and CyberArk Identity authenticates them using a certificate installed during enrollment. The following browsers are supported.

  • Edge

  • Chrome

  • Firefox

    You have to enable CBA on Firefox by going to about:config and changing the value for security.osclientcerts.autoload to true.

In addition, access to resources such as the Identity Administration portal or specific applications can be controlled using the presence of the certificate as an authentication filter. Refer to Configure MFA for certificate-based authentication for more information.

If an existing AD user who has previously logged in to the machine is enrolled as the device owner, the user must logout or restart the machine for Certificate-Based Authentication (also known as ZSO, or Zero Sign-On) to work.

Cloud users can login only after they are granted authentication permission to the machine, so logging out or rebooting the machine is not required.

Self-Service Password Reset (SSPR)

Users with Windows Cloud Agent-enrolled machines can reset their passwords from the login Window. Enabling SSPR increases convenience for users and your help desk. You can maintain security by requiring users to pass additional authentication challenges to change their passwords.

AD users on domain-joined machines can use SSPR even if the machine does not have a connection to the domain controller (remote SSPR). CyberArk Identity validates the new password and updates AD using the CyberArk Identity Connector while sending the cached password to Windows so users can log in to the machine. AD syncs the cached password the next time the user connects to the corporate network (for example, with a VPN connection). This allows users to regain access to company resources if they forget their domain password, which is likely required to connect to the VPN.

Remote SSPR is intended as a temporary workaround for users to regain access to corporate resources. If the cached password expires before the user reconnects to the corporate network, the user will be locked out of their machine. You should encourage users to reconnect to the corporate network as soon as possible. For users who work without a connection to the corporate network on a long-term basis, CyberArk recommend using either CyberArk Cloud Directory users, or AD users on machines that are not domain-joined. Refer to Windows Cloud Agent supported user types for more details.

Refer to Configure self-service password reset (SSPR) for more information about how to configure SSPR.

You can install the Windows Cloud Agent on workstations or servers (including a domain controller) to enforce authentication profiles for a variety of use cases, as outlined in the following table.

Refer to CyberArk Identity Release Notes for a list of Windows operating systems supported by the Windows Cloud Agent.

Machine type Use case(s) where authentication profiles are enforced Additional information Installation options

Workstation
  • AD-bound workstations

  • non AD-bound workstations

    AD users on machines that are not domain joined essentially function as cloud users; they are not bound to AD infrastructure. CyberArk Identity facilitates their login through AD credentials; however, remember that features that are specific to AD-joined machines (IWA, Kerberos) are not available.

Windows Cloud Agent supported user types

Enroll Windows machines with the Windows Cloud Agent

Enroll Windows machines with the Windows Cloud Agent

Server

Servers with no open inbound ports, using the CyberArk Identity Connector as a proxy to CyberArk Identity.

Enroll a server with no inbound ports open

Windows Cloud Agent supported user types

 

Enroll Windows machines with the Windows Cloud Agent

Remote Desktop Protocol ("RDP") connections, including to a Remote Desktop Session Host ("RDS ").

CyberArk Cloud Directory users should authenticate to enrolled machines using their full UPN, while AD users can use just their username, provided there is no conflict with the same username in another supported directory source.

In this section: