• Security Policy for Users and Permissions – Best Practices

    Use the template tool and these best practices for users and permissions to maximize the security and manageability of permissions for your ControlUp users. ControlUp recommends that you follow these best practices to ensure that users can perform only those actions that are applicable to their roles. Permissions and roles are set in the Real-Time Console in the Security Policy Pane.

    General information for working in the Security Policy Pane can be found here: Security Policy Pane - Version 8.1.5 and Above

    Security Policy Planning Template

    You can find a detailed planning template listing all permissions that can be set in the spreadsheet here. You can use this template as a draft for before setting those permissions in the Real-Time Console Security Policy Pane. The benefits of planning your roles and permissions with this planning template before setting permissions in the console include:

    • The spreadsheet is fully searchable.
    • All items are expanded by default.
    • You can visually see the impact that setting a permission may have on other permissions. For example, if you set Deny on a set of permissions, you can see that the same Deny is inherited by other groups of permissions.
    • Test your settings ahead of time before implementing in the console.

    To get the most of this template spreadsheet, make a copy to your own location either online or locally, and edit it as follows:

    1. In the Google Sheets menu, select File > Make a copy to save it to a location in your Google Drive. Or you can select File > Download and select a file type to save it locally.
    2. If you want to specify different permissions for different folders in your organization that you don't want inherited from the root folder, duplicate the spreadsheet for each folder: click the spreadsheet name at the bottom and then select Duplicate.
      Security_Policy_-_Different_subfolder_permissions.png

    You can now use this spreadsheet as a planning template to set permissions for different roles on your different folders. Follow your selections in this template when working in the Real-Time Console Security Policy Pane. 

    Best Practices Overview

    Best Practice #1 – Set a group of users as organization owners instead of a user

    Only specific users can set and change permissions for other users. These users are called organization owners. This role is powerful and it is important to know who is assigned to this role. By default, the user who created the organization automatically becomes the organization owner.

    It is best practice to configure a dedicated Active Directory group that contains only those users who should be allowed to set ControlUp related permissions. This prevents any single point of failure, for example when the original organization owner cannot be contacted anymore.

    Check the Change Organization Owner article to see how to change the organization owner. 

    Best Practice #2 – Create Additional User Roles to Better Organize Permissions

    Make sure that ControlUp users receive only those permissions that are needed to fulfill a specific task. Managing such permissions can be a complex task, especially in bigger organizations.

    By default, the ControlUp Real-Time Console automatically creates a set of user roles which are:

    • Local Admins
    • Organization Members
    • ControlUp Monitors
    • Automation Admins
    • Helpdesk
    • ControlUp Admins

    It is a best practice to create additional roles for different teams or individuals. 

    Check the How to create a custom ControlUp role section to learn how to add additional roles to the ControlUp Security Pane. 

    Best Practice #3 - Configure Organization Members to Access the ControlUp Platform to "Not Set"

    The Organization Members role is analogous to the Everyone group in Windows. By default, all organization members are allowed to access the ControlUp platform. 

    It is a best practice to set all permissions for the Organization Members role to Not Set

    Check the Granting permissions section to see how to set the permission Not Set to a specific role. 

    Best Practice #4 - Create a Dedicated User Role for Monitors

    It is best practice to create a dedicated role for the monitor service. Set permissions for these actions to Allow.

    • Connect to Windows Machine
    • Connect to Linux Machine

    Check the Set Roles for Subfolders section to learn more about how to set permissions for a specific subfolder. 

    Best Practice #5 – Restrict Manage Script Actions Permission

    Users with the Manage Script Actions permission can write and import their own scripts. This may cause harm to any machine that is reachable from the ControlUp Real-Time Console. 

    It is a best practice to allow only ControlUp Admins to manage script actions. 

    Check the Set Roles for Subfolders section to see how to set permissions for a specific subfolder. 

    Best Practice #6 – Create a "View Only" Role

    Grant read-only permissions to users who should only view objects in the Real-Time Console without the ability to modify them. 
    Check the Security Policy - View Only Role article to see how to configure a "View Only" security role. 

  • Configuring Shared Credentials

    The ControlUp Real-Time Console allows you to set shared credentials for use with your configured Hypervisor, XenDesktop, and Netscaler connections. This enables streamlined management of credentials and a quicker onboarding process for new ControlUp users which does not require them to know the service usernames and passwords. 

    Create Shared Credentials

    To create shared credentials:

    1. Click the Settings tab in the Home ribbon and select Monitors.

      mceclip2.png
    2. In the Manage ControlUp Monitors window, click Monitors Settings.

      mceclip3.png
    3. Click Add Credentials Set.

      mceclip7.png
    4. In the Add New Credentials popup, enter the user, password, and friendly name of the new user. If you want to configure this user as a shared user, check the Share credentials with authorized users checkbox. 
      mceclip1.png
      The user is now added to the credentials list.

      mceclip8.png
    5. You can validate the user credentials to check if the entered credentials are valid. Mark the user that you created and click Validate. If your user credentials are validated successfully, you should see this popup message:

      mceclip10.png
      If the credentials are not successfully validated, this popup appears:

      mceclip11.png

    If the credentials you want to share are already configured, check the box under the "Shared" column to share it with your users.

    mceclip0.png

     

    Grant Permission for Organizational Users to use Shared Credentials 

    Organizational Users can not use shared credentials. You must create a Security Role to grant permission to use shared credentials. Once you've saved your credentials as shared credentials, on the bottom of your console click the Security Policy Pane and open the permissions tree for "Perform organization-wide actions"

    mceclip14.png

    Scroll down to the bottom of the organization-wide permissions tree to "Shared Credentials", choose the Security Role you wish to grant permissions to, and set that permission to "Allow".

    mceclip15.png

    Once you have created the shared credential, and granted permissions to users to make use of it, it will become available to set in the Connection Settings of your Hypervisors, XenDesktop Sites, Cloud, and Netscaler Connections.

    mceclip12.png

    Notes on Shared Credentials: 

    • The shared credentials metadata (including the friendly name, username, and domain name) is stored in the organization's public configuration store.
    • The shared password is stored in the private configuration store (located in the %AppData% folder of the Monitor network service or the console user profile) encrypted with DPAPI encryption (https://en.m.wikipedia.org/wiki/Data_Protection_API) and never leaves the customers premise 
  • Credentials Store

    ControlUp supports saving credentials for future reuse. The Credentials Store can be used to create, edit and validate saved credentials. To access the Credentials Store, open the ControlUp Real-Time Console, click the Settings tab > Credentials Store.

    mceclip1.png

    The Credentials Store opens and allows you to

    • create a new credential set,
    • add cloud credentials,
    • add key-based credentials and
    • edit, remove and validate existing credentials.

    mceclip0.png

    Scenarios for Utilizing Saved Credentials

    There are several ways in which ControlUp utilizes saved credentials:

    1. Active Directory (AD) Domain Connections can be configured to use a saved set of credentials. This is useful if your environment includes several AD domains or forests which require different credentials. When you configure an AD connection with a set of saved credentials, those credentials are utilized when deploying or manipulating ControlUp Agent instances on computers from the respective domain or forest. For more information on AD connections, refer to this page.
    2. Some management actions support choosing a set of saved credentials when executing the action. For example, when using the “Run Process As” action to execute a process on a managed computer, you can select a set of credentials to use when launching the process.
    3. Remote Desktop connections can be configured to use a saved set of credentials. You can specify credentials in the connection properties for single machines or in folders that contain a set of managed machines. For more information, refer to the Remote Desktop Pane section.
    4. When configuring a hypervisor connection, saved credentials are mandatory for enabling data collection from the virtualization layer. Additionally, all ControlUp users need to save the same service account credentials in their credentials store in order to enable data collection from the hypervisors. For more information, refer to the Connect to the Virtualization Infrastructure section.

     

    Share Credentials between ControlUp Users

    Your saved credentials are stored securely in your Windows user profile directory and are accessible solely using your own Windows user account, even when using shared configuration or copying your ControlUp settings to another user.

    In version 7.1 we have introduced Shared Credentials Store - ControlUp now allows to manage credentials centrally so all authorized users can use shared credentials sets. This enables more streamlined management of credentials and a quicker onboarding process for new ControlUp users which does not require them to know the service usernames and passwords.

    In online ControlUp environments, credentials stay personal and are never sent to the cloud services or shared with other users. In offline environments, when the centralized configuration feature is not available, sharing the configuration tree and other organization-wide settings between ControlUp users is achieved by copying the %AppData%\ControlUp folder between users. It is important to note that this operation does NOT transfer saved credentials between users. When your colleagues start ControlUp with the %AppData%\ControlUp copied from your user profile, they are prompted to reconfigure all saved credentials.

    ControlUp Monitor and Saved Credentials

    If a ControlUp Monitor is configured in your organization, note that its configuration needs to include saved credentials. They are required to access all managed computers in your environment. For more information, refer to the ControlUp Monitor section.

    Local Computer Credentials

    When saving a set of credentials, the domain drop-down allows you to select the “Local Computer” option in order to save non-Active Directory credentials. Use this option in the following scenarios:

    1. You would like to save a username and password for a local (non-domain) Windows user. These credentials can be used for Remote Desktop connections and for management actions that do not require domain access.
    2. Your environment includes a hypervisor connection that requires non-Windows credentials (for example XenServer root account).
    3. You regularly connect using Remote Desktop to computers that belong to Active Directory domains, the domain controllers of which are not accessible from your local network. For example, consider an off-site server that belongs to the AD domain external.com, for which you have valid AD credentials. You cannot save a set of credentials for the external.com domain in ControlUp, because the domain controllers for that domain cannot be accessed from your local network to validate those credentials. As a workaround, select “Local Computer” from the domain drop-down, and in the User field, enter the username in the format "domain\user", for example external.com\MyUserName.

      mceclip2.png

      This way, the credentials set is treated as local and saved without local validation.
  • Security Policy Pane - Version 8.1.5 and Above

    The Security Policy pane allows ControlUp users within the same organization to delegate administrative tasks by configuring a security policy. The Security Policy is a collection of settings that determine which actions can be performed by each ControlUp role.

    These security settings are assigned per role and may also be assigned differently for every folder in the organization tree, which enables segmenting your environment into distinct areas of responsibility.

    Note: If you are using an on-premises version below 8.1.5, see Security Policy Pane - Versions Below 8.1.5.

    Default Permissions

    By default, Local Admins are granted permission to perform all management actions available in ControlUp. This means that before a ControlUp user can perform a management action, ControlUp checks whether this user’s current Windows account is a member of the local Administrators group on the managed computer. If this validation fails, the management action is not completed.

    Organization members are allowed to perform organization-wide actions but not management actions. For example, they can see the folder tree, create or modify folders, add or remove computers and connect to computers to see their performance information, however, they cannot perform any actions on the managed computers.

    Configure Custom Roles and Restrict Actions

    You can create custom roles for different teams or individuals on your network using the Manage Roles window. Active Directory users and groups from any domain or forest configured in ControlUp may be members of these custom groups.

    Note: As a security precaution, you cannot modify the Security Policy if you have been disconnected from the Central Configuration Store for more than 24 hours. Should you wish to limit your organizations maximum offline period even further, please contact support@controlup.com

    Organization Ownership and User Roles

    Each ControlUp Organization has a designated owner record, which initially contains the identity of the user who first created the organization. The Organization Owner is a Windows user or group account that permanently possesses the ability to change permissions. Regardless of the changes to the Security Policy, the Organization Owner can always reset the Security Policy to the default settings.

    You can view the current owner for your organization by clicking the Manage Roles button on the Home ribbon of the Security Policy pane:
    1.png

    Upon initial configuration of the ControlUp Security Policy, it is recommended to configure a restricted Active Directory group with more than one user as an organization owner. This enables you to reset the Security Policy to factory settings, even if the user who originally created the organization cannot be contacted any longer.

    ControlUp evaluates administrative permissions according to your currently logged-on Windows account. Every ControlUp organization contains a list of roles that determine the permitted actions for each role member. Every ControlUp role must include at least one Windows user or security group. By default, the Security Policy includes the following user roles:

    • Local Admins - Windows users with local administrative permissions on the managed machines.
    • Organization Members - all authenticated ControlUp users in your organization.
    • ControlUp Monitors - comes with no preset permissions.
    • Automation Admins comes with only with the Create Automated Actions permission.
    • Helpdesk - comes preset with connection, credential, and viewing related actions.
    • ControlUp Admins - preset with all Management Actions.

    These default roles cannot be deleted or have their membership modified using ControlUp, however, each role can be granted some or all of the Management Actions, depending on the type of role.

    Note: Aside from the above built-in roles, new roles can be created as described below.

    The Security Policy pane features a permissions grid, which contains a column for every role and a row for every management action. The Management Actions contain various actions within them, which can be granted separately. Click the + next to a Management Action to display the actions within it.
    2.png

    New roles may be created by a Roles Manager, which is a built-in permission initially granted to the organization’s owner. Upon initial configuration of the ControlUp Security Policy, it is recommended to configure a restricted Active Directory group as a role manager.

     

    To create a custom ControlUp role:

    1. Click the Manage Roles screen from the Home ribbon in the Security Policy pane, and the Security Settings popup appears.
      Security_Setting_Popup_Screen.png
    2. Click Add New Role and the Add New Role popup appears.
      3.png
      Note: You must be logged in as a Roles Manager. If not, the button is grayed out and not clickable.
    3. Enter a name in the Role Name text box and click Add Users/Groups and the Account Browse popup appears.
      Account_Browse.png
    4. Select the appropriate users or groups from Active Directory domains available and click OK, and you are returned to the Add New Role popup with the selected roles and groups.
      Note: By default, ControlUp only displays group accounts in the search box. In order to display individual user accounts, please select the Users and Groups radio button.
    5. Click OK, and you are returned to the Security Settings popup.
    6. Click Apply and the new role is created and shown in the Security Policy pane.

    Permissions for Management Actions

    The rows in the permissions grid correspond to management actions. For more details regarding particular permissions, refer to the Action Permissions section below.

    Every ControlUp user may be either allowed or denied access to a management action, depending on their role membership and the location of the managed resource in the organization tree. Every cell in the permissions grid may be in one of the following states:

    Allow – users in the current role are allowed to run the action unless they are also members of another role that is configured with a Deny set.

    Not Set (or blank) – users in the current role are not allowed to run the action unless permitted by another role.

    Deny – users in the current role are never allowed to run the action.

    N/A - the said action does not apply to the role. This cannot be changed.

    For example, by default, a member of the Local Admins is allowed to perform all computer actions on all machines in the organization. This permission is granted since the Local Admins role has an Allow permission on all computer actions for the root folder, and all subfolders inherit this permission.

    IMPORTANT: Once the changes have been made, you MUST click Apply on the Home ribbon of the Security Policy pane to submit your changes to the Central Configuration Store. Until this button is clicked, any changes to the Security Policy are not applied.

    Security Policy Inheritance

    When a ControlUp Organization is first created, the default Security Policy is configured on the root folder of the organization, which bears the organization’s name.

    Configuring Security Policy for Subfolders

    By default, all of the subfolders under the root folder in your organization tree inherit their Security Policy from the root folder. A marked Inherit checkbox near each permission in the grid signifies this. If you would like the Security Policy of a subfolder to be different from its parent folder, you must uncheck this checkbox for the selected permission row.

    Once the Inherit checkbox is unchecked, a blue exclamation point icon on the folder, indicating that part of its Security Policy is no longer inherited from the parent folder:
    4.png

    In the above example, the Chat permission for the "CU Lab” folder is not inherited from its parent folder, hence the blue exclamation point icon n the folder in the organization tree.

    Granting Permissions

    In order to grant ControlUp user permissions for management actions, you need the following details:

    1. Folder name – the name of a folder in the organization tree, which contains resources you would like to grant permission. Select the root folder if you would like to grant permissions on machines in the entire organization, otherwise select a subfolder (e.g. Workstations)
      Note: You may also grant permissions on individual machines by selecting them in the organization tree. However, for manageability reasons, it is recommended that you grant permissions on folders only.
    2. Role name – the name of a built-in or custom role to which the user belongs. (e.g. Help Desk Users).
    3. Action name – the name of the management action which you would like to permit (e.g. Refresh Machine Policy). You can also grant permissions on an entire action group (e.g. Run Computer Actions).
      5.png

    Once you have obtained the details above, click on the desired folder name in the organization tree on the left and locate the row in the table with the desired action name in the row name.

    If the Inherit checkbox for that row is selected, deselect it. If not, click on the cell with the desired Role name in the column header and select Allow from the drop-down list.

    Click Apply on the Home ribbon to save the changes. As a result of the operations in the example above, members of the Helpdesk role have the ability to run the Refresh Group Policy action on machines located in the Workstation folder.

    Note: As with standard Windows permissions, Deny permissions always override Allow permissions. This means that any Allow permission applies only if the affected user is not a member of any other role which has a Deny permission entry in the same row.

    Denying Permissions

    ControlUp’s Security Policy includes two approaches of preventing users from running management actions:

    1. Implicit Deny – not granting permissions in the first place, or setting the permission to Not Set.
    2. Explicit Deny – settings the permission to Deny.

    The difference between these two methods is that Explicit Deny overrides any other permission, and the affected users will always be denied access to the action, even if they are members in additional roles that allow access to the same action. Implicit Deny (or Not Set) means that users are not allowed to run the management action unless permitted to another role they are also a member of.

    Note: It is considered best practice to use the Explicit Deny approach only if you need to configure an exception for an existing rule.
    For example, to enable all Local Admins to restart workstations, except for Helpdesk users, an Explicit Deny is recommended.
    However, to ban Local Admins from restarting machines, it is recommenced to use an implicit Deny (Not Set) permission.

    Resetting Inheritance

    There are several methods of restoring the default Security Policy in ControlUp, depending on your needs:

    • If there’s a single permission entry currently set on a folder and you would like to reset this permission to inherit its parent folder settings, check the Inherit checkbox next to that permission and click Apply on the Home ribbon.
    • If you have a folder with a complete Security Policy that you would like to extend to all its subfolders, select this folder and click Reset Inheritance on the Home ribbon, and then click Apply on the Home ribbon. You will need an Allow setting in the Change Permissions row for the selected folder in order to be able to perform this action.
    • If your entire Security Policy is misconfigured and you would like to reset it to factory defaults, click Reset Defaults on the Home ribbon. Please note that this operation will also remove any custom user roles you have created. In order to be able to perform this operation, your user account must be the Organization’s Owner OR a Roles Manager with sufficient permissions to change permissions on the root folder.

    Action Permissions

    This section describes all the permissions configurable in ControlUp.

    Perform Organization-wide Actions

    These actions are performed on objects in ControlUp’s organization tree only, without affecting managed resources, such as machines or user sessions. They can also be referred to as 'tree actions' since they are executed using the ControlUp Console and include the ability to add or remove machines, create and arrange folders, and change permissions.

    Change Permissions – modifies the Security Policy for the current folder or machine.
    Note: The Organization Owner is always allowed to change permissions, regardless of other settings.

    Manage ControlUp Insights Access Settings – modifies all settings on the Insights Access tab of the Settings window.

    Manage User Permissions to ControlUp Insights – modifies the per-user permissions to access ControlUp Insights in the Organization Properties window.

    Manage Data Upload Settings – modifies all settings on the Data Upload tab of the Settings window.

    Edit Stress Settings – modifies the Stress Level settings for the current folder.

    Manage Branch mapping settings  - configures the subnet-to-name lookup table on the Branch Mapping tab of the Settings window.

    Configure Incident Triggers – to view and change the configurations of incident triggers in the organization.

    Add Computer – adds new managed machines to the current folder.

    Add Folder – adds new folders to the current folder.

    Change Folder Description – modifies the description field for a folder.

    Remove Computer – removes machines from the current folder and removes the current computer.

    Remove Folder – removes the current folder.

    Run Shared Script-based Actions – globally permits execution of Script-based actions. In addition, the user needs explicit permission to perform the Script-based Action of choice (see Script-based Actions below).

    Run Draft Script-based Actions – permits the creation of new Script-based actions (drafts).

    Download and Share Script-based Actions – permits downloading SBAs shared by the community and sharing user-created SBAs with the community.

    Manage Script-based Actions – permits managing Script-based Actions for your organization.

    View Folder – see the folder in the organization tree. The folder will be invisible to users lacking this permission (except for the root folder, which stays visible).

    Launch Controllers – switch to the Controllers pane. Without this permission, users cannot launch any controllers. This is a user interface restriction, which can be configured on the root folder only.

    View Incidents – uses the Incidents Pane to display entries recorded in the organizational incidents database. Applies to the entire organization and cannot be changed for subfolders.

    View Events – uses the Events Pane to display event entries recorded on the managed machines. Applies to the entire organization and cannot be changed for subfolders.

    View Hypervisors – to view all hypervisor-related objects in the organization (VMs, Hosts, and hypervisor connections). Applies to the entire organization and cannot be changed for subfolders.

    Manage Hypervisors – to create, edit and delete hypervisor connections in the organization. Applies to the entire organization and cannot be changed for subfolders.

    Manage XenDesktop Sites - to create, edit and delete  XenDesktop site connections in this organization.

    Manage NetScaler Appliances - to create, edit and delete NetScaler connections in this organization.

    Manage Application Load Time - configure the parameters that ControlUp Agents use when measuring application load times.

    Manage Browser URL - configure the parameters that ControlUp Agents use to monitor URLs of browser processes.

    Connect to Data Source - collects data from an external data source, such as a Hypervisor, XenDesktop site, public cloud, or NetScaler appliance.

    Manage Shared Credentials - to create, edit and delete shared credentials in the organization. 

    Use Shared Credentials - connects to an organization tree view connection with Shared Credentials. 

    Run Computer Actions

    These actions are performed on the managed machines via the ControlUp Agent. Actions that have an asterisk after the action name are dependent on your currently logged-on Windows user’s rights because they use RPC to access the remote machines.

    Console-based Actions

    Monitor Computer – to connect to the ControlUp Agent and start gathering performance data.

    Change Computer Description – to edit the Description field for a machine in ControlUp.

    Event Viewer on Remote Computer – to open a new Event Viewer (eventvwr) window, attempting to connect to the remote machine.

    RDP to Computer – to switch to the Remote Desktop pane and establish an RDP session to the managed computer.

    Agent-based Actions

    The rest of the Computer Actions are performed using the ControlUp Agent on the managed machines. A user that was granted access to agent-based actions is permitted to instruct the ControlUp Agent on the managed machines to perform these actions. The ControlUp Agent on a managed machine will use its Local System account to perform the action unless otherwise specified. For example, when using the “Processes > Run as…” action, the ControlUp user can execute any process accessible by the Local System account. As a side effect, you cannot run processes from the network unless you specify valid credentials since Local System cannot access network locations.

    For a full list of agent-based actions, refer to the My Organization Pane article.

    Run Session Actions

    Actions in this group are invoked using the Sessions view and performed on the managed machines using the ControlUp Agent.

    A user who is granted access to these actions can execute them only on user sessions hosted on managed machines affected by the Security Policy you are currently editing. Note the caption on top of the permissions grid that reads “Security Policy for …”

    For more information regarding these actions, refer to the My Organization Pane article.

    Run Processes Actions

    Actions in this group act upon processes on managed machines and are executed using the ControlUp Agent.

    A user granted access to these actions can execute them only on processes running on managed machines affected by the Security Policy you are currently editing. Note the caption on top of the permissions grid that reads “Security Policy for …”

    For more information regarding these actions, refer to the My Organization Pane article.

  • Security Policy Pane - Below Version 8.1.5

    If you are using the Cloud-Hybrid version or an on-premises installation of version 8.1.5 or above, see Security Policy Pane - v8.1.5 and Above.

    The Security Policy pane is a user interface that allows ControlUp users within the same organization to delegate administrative tasks by configuring a Security Policy. ControlUp’s Security Policy is a collection of settings that determines which actions can be performed by each ControlUp user. These settings may be different for every folder in the Organization Tree, which allows for segmenting your environment into distinct areas of responsibility.

    Note: For a brief beginner’s guide to the ControlUp Security Policy, see the Secure Your Organization chapter.

    ControlUp’s Security Policy is dependent upon the Central Configuration Store which is enabled in On-Premises or Hybrid Cloud mode only. In Standalone (Offline) mode, the Security Policy pane is disabled. For more information regarding ControlUp modes please refer to the “Choose Your ControlUp Mode” chapter.

    Note: As a security precaution, you will not be able to modify the Security Policy if you have been disconnected from the Central Configuration Store for more than 24 hours. Should you wish to limit your organization's maximum offline period even further, please contact support@controlup.com.

    Organization Ownership and User Roles

    Each ControlUp Organization has a designated owner record, which initially contains the identity of the user who first created this organization. The Organization Owner is a Windows user or group account, who permanently possesses the ability to change permissions. Regardless of the changes to the Security Policy, the Organization Owner will always be able to reset the Security Policy to its default settings. You can view the current owner for your organization by clicking the “Manage Roles” button on the Home ribbon of the Security Policy pane:
    1.png

    Upon initial configuration of the ControlUp Security Policy, it is recommended that you configure a restricted Active Directory group as an organization owner. This way you will always have the ability to reset ControlUp’s Security Policy to factory settings, even if the user who originally created the organization cannot be contacted any longer.

    ControlUp evaluates administrative permissions according to your currently logged on Windows account. Every ControlUp organization contains a list of roles that determines the actions allowed for each role member. Every ControlUp role has to include at least one Windows user or a security group. By default, the Security Policy includes the following user roles:

    • Organization Members – all authenticated ControlUp users in your organization.
    • Local Admins – Windows users with local administrative permissions on the managed computers.

    These built-in roles are special in the sense that they cannot be deleted or have their membership modified using ControlUp.

    The Security Policy pane features a permissions grid, which contains a column for every role and a row for every management action:
    2.png

    New roles may be created by a Roles Manager, which is a built-in right initially granted to the organization’s owner. Upon initial configuration of ControlUp Security Policy, it is recommended that you configure a restricted Active Directory group as a Roles manager. Custom roles are created and managed using the “Manage Roles” button on the Home ribbon of the Security Policy pane:3.png

    To create a custom ControlUp role:

    1. Open the “Manage Roles” screen (using the Home ribbon in the Security Policy pane, or using the “Security Policy Settings” button on the Settings ribbon, or using the File menu > Settings > Security Policy)
    2. Click on “Add New Role” (If the button is greyed out, please ensure that your currently logged on Windows user account is a member of the “Roles Manager” group)
    3. Type a descriptive role name, such as “Help Desk Users”
    4. Click on “Add Users/Groups” and select the appropriate users or groups from Active Directory domains available to you. Please note that by default, ControlUp only displays group accounts in the search box. In order to display individual user accounts, please select the “Users and Groups” radio button.

    After your custom role is created, you should see a new column with the role’s name appear to the right of the existing role columns.

    Permissions for Management Actions

    The rows in the permissions grid correspond to management actions, which are divided into the following groups:

    1. Perform organization-wide actions
    2. Run computer actions
    3. Run session actions
    4. Run processes actions

    For more details regarding particular permissions, please refer to the “Action Permissions” section below.

    Eventually, every ControlUp user may be either allowed or denied access to the management action, depending on their role membership and the location of the managed resource in the organization tree. Every cell in the permissions grid may be in one of the following states:

    “Allow” – users in the current role are allowed to run the action unless they are also members of another role that is configured with a “Deny” entry.

    “Not Set” – users in the current role are not allowed to run the action unless permitted by another role.

    “Deny” – users in the current role are never allowed to run the action.

    For example, by default, a member of the “Local Admins” is allowed to perform all computer actions on all computers in the organization. This permission is granted since the “Local Admins” role has an “Allow” permission on all computer actions for the root folder, and all subfolders inherit this permission.

    Note: the “Apply” button on the Home ribbon of the Security Policy pane commits your changes to the Central Configuration Store. Until this button is clicked, any changes to the Security Policy are not applied.

    Security Policy Inheritance

    When a ControlUp Organization is first created, the default Security Policy is configured on the root folder of the organization, which bears the organization’s name.

    Configuring Security Policy for Subfolders

    By default, all of the subfolders under the root folder in your organization tree inherit their Security Policy from the root folder. A marked “Inherit” checkbox near each permission in the grid signifies this. If you would like the Security Policy of a subfolder to be different from its parent folder, you should uncheck this checkbox for the selected permission row.

    Once the “Inherit” checkbox is unchecked, you will see a blue “i” sign on the folder, indicating that part of its Security Policy is no longer inherited from the parent folder:
    4.png

    In the above example, the “Chat” permission for the “CU Lab” folder is not inherited from its parent folder, hence the blue “i” icon in the organization tree.

    Granting Permissions

    In order to grant ControlUp user permission for management action, you will need the following details:

    Folder name – the name of a folder in the organization tree, which contains resources on which you would like to grant permission. Select the root folder if you would like to grant permissions on computers in the entire organization, otherwise select a subfolder (e.g. Workstations) Note: You may also grant permissions on individual computers by selecting them in the organization tree. However, for manageability reasons, it is recommended that you grant permissions on folders only.

    Role name – the name of a built-in or custom role to which the user belongs. (e.g. Help Desk Users).

    Action name – the name of the management action which you would like to permit (e.g. “Refresh Machine Policy”). You can also grant permissions on an entire action group (e.g. “Run Computer Actions”).
    5.png

    Once you have obtained the details above, click on the desired Folder name in the organization tree on the left, locate the row in the table with the desired Action name in the row name.

    If the “Inherit” checkbox for that row is selected, deselect it. If not, click on the cell with the desired Role name in the column header and select “Allow” from the drop-down list.

    Click “Apply” on the Home ribbon to save the changes. As a result of the operations in the example above, members of the “Helpdesk” role will have the ability to run the “Refresh Group Policy” action on computers located in the “Workstation” folder.

    Note: As with standard Windows permissions, ControlUp “Deny” permissions always override “Allow” permissions. This means that any “Allow” permission applies only if the affected user is not a member of any other role which has a “Deny” permission entry in the same row.

    Denying Permissions

    ControlUp’s Security Policy includes two approaches of preventing users from running management actions:

    1. Implicit Deny – not granting permissions in the first place, or setting the permission to “Not Set”.
    2. Explicit Deny – settings the permission to “Deny”.

    The difference between these two methods is the fact that Explicit Deny overrides any other permission, and the affected users will always be denied access to the action, even if they are members in additional roles which allow access to the same action. Implicit Deny (or “Not Set”) means that users are not allowed to run the management action unless permitted to another role they are also a member of.

    Note: It is considered best practice to use the explicit Deny approach only if you need to configure an exception for an existing rule. For example, “all Local Admins should be able to restart workstations, except for Helpdesk users” is a valid example for explicit Deny. However, a rule such as “Local Admins should not be allowed to restart computers” should be configured by using implicit Deny (“Not Set”) permission only.

    Resetting Inheritance

    There are several methods of restoring the default Security Policy in ControlUp, depending on your needs:

    1. If there’s a single permission entry that is currently set on a folder and you would like to reset this permission to inherit its parent folder settings, check the “Inherit” checkbox next to that permission and click “Apply” on the Home ribbon.
    2. If you have a folder with a complete Security Policy you would like to propagate to all its subfolders, then select this folder, click “Reset Inheritance” on the Home ribbon, and then click “Apply” on the Home ribbon. You will need an “Allow” setting in the “Change Permissions” row for the selected folder in order to be able to perform this action.
    3. If your entire Security Policy is misconfigured and you would like to reset it to factory defaults, click on the “Reset Defaults” button on the Home ribbon. Please note that this operation will also remove any custom user roles you have created. In order to be able to perform this operation, your user account has to be the Organization’s Owner OR a Roles Manager with sufficient permissions to change permissions on the root folder.

    Action Permissions

    This section describes all the permissions configurable in ControlUp.

    Perform Organization-wide actions

    These actions are performed on objects in ControlUp’s organization tree only, without affecting managed resources such as computers or user sessions. They can also be referred to as “tree actions” since they are executed using the ControlUp Console and include the ability to add or remove computers, create and arrange folders, and change permissions.

    Change Permissions – modify the Security Policy for the current folder or computer.

    Note: The Organization Owner is always allowed to change permissions, regardless of other settings.

    Manage ControlUp Insights Access Settings – modify all settings on the Insights Access tab of the Settings window

    Manage User Permissions to ControlUp Insights – modify the per-user permissions to access ControlUp Insights in the Organization Properties window

    Manage Data Upload Settings – modify all settings on the Data Upload tab of the Settings window

    Edit Stress Settings – modify Stress Level settings for the current folder.

    Manage Branch mapping settings  - configure the subnet-to-name lookup table on the Branch Mapping tab  of the Settings window

    Configure Incident Triggers – view and change the configurations of incident triggers in the organization.

    Add Computer – add new managed computers to the current folder.

    Add Folder – add new folders to the current folder.

    Change Folder Description – modify the description field for this folder.

    Remove Computer – remove computers from the current folder / remove the current computer.

    Remove Folder – remove the current folder.

    Rename Folder – rename the current folder.

    Run Shared Script-based Actions – globally permits execution of Script-based actions. In addition, the user will need explicit permission to perform the Script-based Action of choice (see Script-based Actions below).

    Run Draft Script-based Actions – permits the creation of new Script-based actions (drafts).

    Download and Share Script-based Actions – permits downloading SBAs shared by the community and sharing user-created SBAs with the community.

    Manage Script-based Actions – permits managing Script-based Actions for your organization.

    View Folder – see the folder in the organization tree. The folder will be invisible to users lacking this permission (not applicable for the root folder, which has to stay visible).

    Launch Controllers – switch to the Controllers pane. Without this permission, users cannot launch any controllers. This is a user interface restriction that can be configured on the root folder only.

    View Incidents – use the Incidents Pane to display entries recorded in the organizational incidents database. Applies to the entire organization and cannot be changed for subfolders.

    View Events – use the Events Pane to display event entries recorded on the managed computers. Applies to the entire organization and cannot be changed for subfolders.

    View Hypervisors – View all hypervisor-related objects in the organization (VMs, Hosts, and hypervisor connections). Applies to the entire organization and cannot be changed for subfolders.

    Manage Hypervisors – Create, edit and delete hypervisor connections in the organization. Applies to the entire organization and cannot be changed for subfolders.

    Manage XenDesktop Sites - Create, edit and delete XenDesktop site connection in this organization.

    Manage NetScaler Appliances - Create, edit and delete NetScaler connection in this organization.

    Manage Application Load Time - configure the parameters that ControlUp Agents are using when measuring application load times.

    Manage Browser URL - configure the parameters that ControlUp Agents are using to monitor URLs of browser processes.

    Connect to Data Source - Collect data from an external data source. such as Hypervisor, XenDesktop site, public cloud or NetScaler appliance.

    Manage Shared Credentials - Create, edit and delete shared credentials in the organization. 

    Use Shared Credentials - Connect to an organizational tree view connection with Shared Credentials. 

    Run Computer Actions

    These actions are performed on the managed computers via the ControlUp Agent. Actions that have an asterisk after the action name are dependent on your currently logged-on Windows user’s rights because they use RPC to access the remote computers.

    Console-based Actions

    Monitor Computer – connect to the ControlUp Agent and start gathering performance data.

    Change Computer Description – edit the “Description” field for a computer in ControlUp

    Event Viewer on Remote Computer – open a new Event Viewer (eventvwr) window, attempting to connect to the remote computer.

    RDP to Computer – switch to the Remote Desktop pane and establish an RDP session to the managed computer.

    ControlUp Agent Management

    Agent-based Actions

    The rest of the Computer Actions are performed using the ControlUp Agent on the managed computers. A user who is granted access to agent-based actions is permitted to instruct the ControlUp Agent on the managed computers to perform these actions. The ControlUp Agent on a managed computer will use its Local System account to perform the action unless otherwise specified. For example, when using the “Processes > Run as…” action, the ControlUp user will be able to execute any process accessible by the Local System account. As a side effect, you will not be able to run processes from the network unless you specify valid credentials since Local System cannot access network locations.

    For a full list of agent-based actions, please refer to the chapter regarding My Organization Pane.

    Run Session Actions

    Actions in this group are invoked using the Sessions view and performed on the managed computers using the ControlUp Agent.

    A user who is granted access to these actions will be able to execute them only on user sessions hosted on managed computers affected by the Security Policy you are currently editing. Please note the caption on top of the permissions grid, saying “Security Policy for …”

    For more information regarding these actions, please refer to the chapter regarding My Organization Pane.

    Run Processes Actions

    Actions in this group act upon processes on managed computers and are executed using the ControlUp Agent.

    A user who is granted access to these actions will be able to execute them only on processes running on managed computers affected by the Security Policy you are currently editing. Please note the caption on top of the permissions grid, saying “Security Policy for …”

    For more information regarding these actions, please refer to the chapter regarding My Organization Pane.