Enroll Windows machines with the Windows Cloud Agent

This topic describes how to enroll Windows machines with the Windows Cloud Agent to enforce adaptive MFA without depending on direct connectivity (LAN or VPN) to the directory source (for example, Active Directory).

Before you enroll any Windows machines, you should create a policy set to configure adaptive MFA for your Windows users. The Windows Cloud Agent supports the following authentication mechanisms:

  • Mobile Authenticator

  • email

  • phone call

  • SMS

  • OATH OTP

  • security questions

Select passwordless authentication mechanisms to provide your users with a seamless log in experience. Refer to CyberArk Identity Windows Cloud Agent for more information about passwordless authentication, and other benefits of enrolling with the Windows Cloud Agent.

Remember to complete the Prerequisites for deploying the Windows Cloud Agent first.

Configure adaptive MFA for Windows users

Configure an authentication policy for Windows to enforce adaptive MFA when you enroll their Windows machines. For example, you could use additional authentication mechanisms if a user tries to log in from outside of your corporate IP range.

To configure a Windows authentication policy in the Admin Portal

  1. Log in to the Admin Portal.

  2. Click Core Services > Policies and select the policy you want to edit or click Add Policy Set to create a new one.

    The Policy Settings page opens.

  3. Select the Specified Roles or the Sets option in the Policy Assignment area.

  4. Click Add, then find and select the role or set that contains the relevant users or endpoints.

  5. Click Add.

  6. Go to Authentication Policies > Endpoint Authentication.

  7. Select Yes in the Enable authentication policy controls drop-down.

    If you want users to authenticate regardless of the log-in condition, skip the following step and use the Default Profile (used if no conditions matched) drop-down to define an authentication profile.

  8. (Optional) Click Add Rule to specify conditional access.

    The Authentication Rule window appears.

  9. Click Add Filter on the Authentication Rule window.

  10. Define the filter and condition using the drop-down menus.

    Filter Description Conditions available

    IP Address

    The computer’s IP address when the user logs in. You can create rules based on:

    • Whether the location of the IP address is inside or outside the corporate network.

      Use either the Inside corporate IP range or Outside corporate IP range condition. The corporate IP network is defined in the table in Settings > Network > Corporate IP Range.

    • A Secure Zone (an IP address range that is a subset of your internal or external corporate IP network).

      Use the inside IP range ... condition. If you select this condition, you also need to indicate the specific Secure Zone (IP range configured in the IP table in Settings > Network > Corporate IP Range).

    To configure the IP address condition, you first need to configure the IP address range in Settings > Network > Corporate IP Range. See Set Corporate IP ranges. The specified authentication profile is then applied to users whose IP address matches the specified IP address value, or falls within the specified IP address range.

    Also see Disable policy rules for Corporate IP ranges to exempt certain IP addresses or ranges from policy rules.

    • Inside corporate IP range
    • Outside corporate IP range
    • Inside IP range ...
    Identity Cookie

    The cookie that is embedded in the current browser by CyberArk Identity after the user has successfully logged in

    • Is present
    • Is not present

    Day of Week

    Specific days of the week (Sunday through Saturday). You can select one or more, based on either User Local Time or UTC.

    Authentication filters for RADIUS connections only use UTC.

    Checkboxes for each day of the week and radio buttons to select either User Local Time or UTC

    Date

    A date before or after which the user logs in that triggers the specified authentication requirement, based on either User Local Time or UTC.

    Authentication filters for RADIUS connections only use UTC.
    • Less than <selected date>
    • Greater than <selected date>

    User Local Time or UTC

    Date Range

    A specific date range, based on either User Local Time or UTC.

    Authentication filters for RADIUS connections only use UTC.

    Date pickers and radio buttons for User Local Time or UTC

    Time Range

    A specific time range in hours and minutes, based on either User Local Time or UTC .

    Authentication filters for RADIUS connections only use UTC.

    Strings representing time ranges in the format hh:mm, with radio buttons for User Local Time or UTC

    Device OS

    The operating system of the device a user is logging in from.

    • equal to
    • not equal to

    Network Level Authentication

    This filter is used to apply authentication profiles based on whether an RDP client has completed Network Level Authenticaton ("NLA").

    • is done

    • is not done

    Browser

    The browser used for opening the CyberArk Identity portal.

    • equal to
    • not equal to

    Role

    CyberArk Identity roles that a user belongs to. If a user belongs to multiple roles, the authentication rule that comes first (highest priority on top) is honored.

    If a role is renamed following the creation of an authentication rule using Role as a filter, the authentication rule will automatically update with the new role name. If a role is deleted, the portion of the any authentication rule using that role as a filter will also be deleted.

    This filter is only applicable to managing web application access.

    • equal to
    • not equal to

    Country

    The country based on the IP address of the user computer.

    • equal to
    • not equal to

    Risk Level

    Risk Level: The authentication factor is the risk level of the user logging on to user portal. For example, a user attempting to log in to CyberArk Identity from an unfamiliar location can be prompted to enter a password and text message (SMS) confirmation code because the external firewall condition correlates with a medium risk level. This Risk Level filter, requires additional licenses. If you do not see this filter, contact CyberArk support. The supported risk level are:

    • Non Detected -- No unexpected activities are detected.
    • Low -- Some aspects of the requested identity activity are unexpected. Remediation action or simple warning notification can be raised depending on the policy setup.
    • Medium -- Many aspects of the requested identity activity are unexpected. Remediation action or simple warning notification can be raised depending on the policy setup.
    • High -- Strong indicators that the requested identity activity is anomaly and the user's identity has been compromised. Immediate remediation action, such as MFA, should be enforced.
    • Undetermined -- Not enough user behavior activities (frequency of system use by the user and length of time user has been in the system) have been collected.
    • equal to
    • not equal to

    Managed Devices

    A device is considered “managed” if it is enrolled in CyberArk Identity and you use CyberArk Identity for device management. A device that is enrolled for only single sign-on or endpoint authentication is not considered a managed device. For more information about the difference, refer to Mobile Device Management or single sign-on only.

    The Windows Cloud Agent does not include device management features. Enrolled Windows machines are not considered managed devices.

    This filter is only applicable to managing web application access.

    • True
    • False

    Certificate Authentication

    Whether or not you use a digital certificate issued by your organization’s trusted certificate authority. You can upload a certificate using the Admin Portal > Settings > Authentication > Certificate Authorities. Users can also individually use CyberArk as their trusted certificate authority and automatically install the digital certificate by enrolling their devices.

    For example, if you configure an authentication rule to use the Certificate Authentication condition, then CyberArk Identity checks for a digital certificate issued by a trusted certificate authority and enforces the specified authentication profile before allowing access to this application.

    CyberArk support must enable the Certificate Authentication filter for your company.
    • is used
    • is not used
  11. Click the Add button associated with the filter and condition.

  12. Select the profile that you want applied if all filters/conditions are met in the Authentication Profile drop-down, then click OK.

    The authentication profile is where you define the authentication mechanisms. If you have not created the necessary authentication profile, select the Add New Profile option. See Create authentication profiles.

  13. (Optional) In the Default Profile (used if no conditions matched) drop-down, you can select a default profile to be applied if a user does not match any of the configured conditions.

  14. If you have no authentication rules configured and you select Not Allowed in the Default Profile drop-down, users will not be able to log in to the service.

  15. (Optional) If you have more than one authentication rule, you can drag and drop the rules to a new position in the list to control the order they are applied.

  16. If you configure one-time-passcode (OTP) as an authentication method for your users, as long as endpoint authentication is enabled in your policy setting your users can authenticate using the passcode when their machines are offline. Offline OTP requires that users first log in to User Portal with an internet connection to get the offline code. Direct users to Set up OTPs to authenticate for information on setting up offline OTP.

    If your users also have an enrolled Android or iOS device, after they successfully authenticate to their cloud agent--enrolled machine, they can refresh the Passcodes section of the Idaptive Mobile application to automatically create an offline OTP code.
  17. From the policy, select Endpoint Policies > Common Settings > Agent Settings > Lock Screen, then make a selection for MFA grace period for OS X and Windows screen unlock.

    The grace period is the amount of time that an active user session can be accessed without MFA challenges. Examples of accessing an active user session include unlocking the screen or switching between logged on users. If the user session is terminated, the grace period timer restarts.

    To specify a grace period, select one of the minute or hour values from the drop-down menu. To specify no grace period, select Immediately. In this case, a locked device immediately requires MFA challenges for unlocking. The default value is Immediately.

    Any change in the grace period setting takes effect only after the period defined in the "Update device information frequency (default 12 hours)" setting in Endpoint Policies > Device Management Settings, or if policies are manually pushed, or on device restart.

    Self-service password reset is unavailable inside the MFA grace period.

    For more information about setting the MFA grace period for Windows or Mac, see Enroll Windows machines with the Windows Cloud Agent or Require MFA for Mac endpoints, respectively.

  18. (Optional) Configure settings for self-service password reset and self-service account unlock.

  19. Click Save.

Enroll Windows machines with the Windows Cloud Agent

You can either enroll a machine individually, or for AD-joined machines you can enroll in bulk.

Step 1: Generate an enrollment code.

    You need a randomly generated enrollment code to enroll machine. You must be a member of the System Administrator role to generate enrollment codes.

    1. Log in to the Admin Portal.

    2. Click Settings > Endpoints > Enrollment Codes.

    3. Click the Add button.

      The Generate Bulk Enrollment Codes window appears.

    4. (Optional) Select the details to be used to generate the enrollment code.

      • Set an expiration date if the code should expire.

      • Specify the maximum number of devices that can be enrolled or leave Unlimited selected.

      • Enter a description.

    5. Click Save to generate the enrollment code.

    6. Click Copy to copy it to the clipboard.

Step 2: Download and install the Windows Cloud Agent on Windows machines in your organization.

The procedure for installing on an individual machine is appropriate if you are enrolling a server. Use one of the bulk install procedures to deploy the Windows Cloud Agent on workstations throughout your organization.

A bulk deployment that maps one user per machine requires Windows Cloud Agent version 21.3 or higher.
  1. Log-in to the Admin Portal.

  2. Click Downloads and select Agents from the software list.

    All the agents available for download are displayed.

  3. Click download for the Windows Cloud AgentWindows Device Trust installer.

  4. When the download completes, use the Windows native package manager to install.

  5. Enter values for the following parameters.

    • Tenant URL - Your tenant URL. You can find it in the Admin Portal, Settings > Customization > Tenant URLs.
    • Enrollment Code - Paste the value of the enrollment code generated previously (In the Admin Portal, Settings > Endpoints > Enrollment Codes.
    • Optional parameters - CyberArk recommends adding the following parameters to assign users permission to log in to the enrolled machine.

      • -l <role> to specify the role containing the users who you want to be able to sign in to the machine.

        This should be the same role that the policy set enabling Endpoint Authentication is applied to. Remember to use quotes around role names with spaces.

        If you are setting permissions for a Windows server, add the AD group listed in the server's Remote Desktop Users list to enforce your authentication policies via RDP connections.

        Although users who received permission via role assignment can authenticate to the machine and generate offline OTPs for offline authentication, CyberArk Identity does not consider them the machine owner.

      • -e <user> where <user> is the user's userPrincipalName.

        Users explicitly assigned during enrollment are considered the owner of the device; the user can find the device on the Devices tab of the User Portal.

      If you are enrolling a server that can only access the internet through a proxy server (for example, a domain controller), use -p <proxy url> where <proxy url> is the URL of the proxy server the machine uses to connect to the internet.

      If you are enrolling a server with no open inbound ports, use -p <proxy url>, where <proxy url> is the IP address and port of the server hosting the CyberArk Identity Connector; the CyberArk Identity Connector acts as a proxy to CyberArk Identity.

      Refer to Windows Cloud Agent CLI reference for more information about available parameters.

    If it's necessary, you can give additional users permission later: Grant authentication permission to additional users. Users given permission after enrollment are not considered the machine owner, regardless of whether they are explicitly given permission or given permission via role membership.

  6. Click Finish to enroll the machine.

    If enrollment does not initiate or complete, you can manually enroll the machine using the CLI. Refer to Windows Cloud Agent CLI reference for more information.

This procedure is only applicable to AD-joined machines. It deploys the Windows Cloud Agent on Windows workstations throughout your organization by granting authentication permissions to a role.
  1. Generate the MST file.

    1. Log in the Admin Portal.

    2. Click Downloads and select Agents from the software list.

      All the agents available for download are displayed.

    3. Click download for the Windows Cloud Agent.

    4. Create a backup copy of the installer file.

    5. Right-click the installer file and select Edit with Orca.

    6. Select Transform > New Transform.

    7. Select the Property table in the left hand pane.

    8. Right-click in the main pane and select Add Row to specify the relevant properties and values.

    9. Specify the following properties and corresponding values one at a time into the pop-up window:

      Property Value

      Notes

      TENANTURL <tenant url>

      Your tenant URL. You can find it in the Admin Portal, Settings > Customization > Tenant URLs. See Configure UI fields for more information on tenant URLs.

      ENROLLCODE <enrollment code>

      The enrollment code you generated. See Generate an enrollment code..

      PARAM -l <role>

      <role> should be the role containing users you want enrolled. This role should be the same one you specified in your policy assignment settings -- the Admin Portal, Core Services > Policies > Policy Settings > Policy Assignment configuration area.

      Although users who received permission via role membership can authenticate to the machine and generate offline OTPs for offline authentication, CyberArk Identity does not consider them the machine owner.

      If it's necessary, you can give additional users permission later: Grant authentication permission to additional users. Users given permission after enrollment are not considered the machine owner, regardless of whether they are explicitly given permission or given permission via role membership.

      Refer to Windows Cloud Agent CLI reference for more information about available parameters.

    10. Repeat the previous steps to create the required properties.

      The following image shows a created tenant URL property/value and the window available for the next property.

    11. Select Transform > Generate Transform to save your modifications to the MST file.

    12. Select Transform > Close Transform.

      Be sure to save the MST file in the same folder as the MSI file. If the MST and MSI files are in different folders, the MST file will not execute when you execute the MSI file.
  2. Deploy the MSI file to your organization.

    Deployment methods include:

    The rest of the steps are an example of how to deploy the MSI file using the domain controller.

  3. Apply the MSI file to the following path in your Group Management Policy Editor: Computer Configuration > Policies > Software Settings.

  4. Add the MST file to the MSI file.

    1. Navigate to the following path in your Group Management Policy Editor: Computer Configuration > Policies > Software Settings.

    2. Right click Software Installation.

    3. Click New > Package.

    4. Select the MSI file.

    5. Click Open.

    6. Select Advanced and click OK.

    7. Select the Modifications tab.

    8. Click Add, then select the MST file and click OK.

      The software is installed at the next group policy update.

    For more complete information about creating and using group policies and Group Policy Objects, see your Windows or Active Directory documentation.

This procedure is only applicable to AD-joined machines. It deploys the Windows Cloud Agent on Windows workstations throughout your organization by mapping individual users to each workstation.
  1. Log in to the CyberArk Identity Admin Portal.

  2. Click Settings > Endpoints > Corporate-owned Devices > Import.
    The Corporate-owned Devices Import window opens.

  3. (Optional) Click the Corporate-owned devices import template link if you need to create the CSV file.

  4. (Optional) For Windows devices, open the CSV file and enter a username with the domain suffix in the Assigned User column to assign each Windows device to a user.

  5. Click Browse, navigate to your CSV file, then upload the file.

  6. Click Next.

  7. Review the data fields and click Next.

  8. Verify the email address for report delivery and click Confirm.
    The imported devices and serial numbers appear in the Corporate-owned Devices list in the Admin Portal (Settings > Endpoints > Corporate-owned Devices).

  1. Click Downloads and expandAgents in the software list.

  2. Click download for the Windows Cloud Agent.

  3. Deploy the Windows Cloud Agent with the tool of your choice.

    For example, you could use SCCM. After you deploy the Windows Cloud Agent, only the users assigned in the CSV file can authenticate to each machine.