Ivanti Automation powered by RES

Home 

Access permissions

At Administration > Security, you can manage access to the functionality in the Console. Because any set of changes to the IT environment of your organization can be delivered from the Console, it is important to prevent unauthorized access, in order to prevent that these changes lead to unexpected and undesired results.

The access permissions of an administrative role define what a Console user is allowed to do with the items in the Console: view information (Read), change information (Modify) or nothing (Deny). You can select the permissions for an administrative role at the Permissions tab of the Ivanti Automation Console Administrative Role window.

Configuration

Security Roles - Deny

If access is set to Deny, the node, (sub)folder or object will be hidden and access to the windows and options that are associated with it will be blocked or hidden. By default, all access permissions of a new administrative role are set to Deny.

Security Roles - Read icon

If access is set to Read, the node, (sub)folder or object and the windows and options that are associated with it will be shown as read-only. Console users with Read access may still be able to configure Trusts on the item, depending on the trust permissions of their administrative role.

Security Roles - Modify icon

If access is set to Modify, the login has full access to the node, (sub)folder or object and all windows and options that are associated with it.

Security Roles: Inherit icon

In certain nodes, you can assign explicit access permissions on (sub)folders and objects that deviate from the access permissions of the "parent" node. For example, this can be useful to configure administrative roles with access permissions on specific Agents and Teams. In large Ivanti Automation environments, this makes it easier to configure permissions to Resources, Modules, Projects or Run Books that are grouped in folders, for example to differentiate between different environments. This makes it possible to configure administrative roles that grant access to certain (sub)folders only.

  • If no explicit access is set on a (sub)folder, it will inherit the access permissions of the node in which it is located.
  • If no explicit access is set on an object in a (sub)folder, it will inherit the access permissions of the folder in which it is located.
  • In the Jobs nodes, the permissions on a Job are determined by the permissions on the Agent(s) or Team(s) on which the Job is scheduled and by the permissions on the Module(s), Project or Run Book in the Job.
  • You can only create Instant Reports and Building Block items that relate to nodes and sections in the Console to which your administrative role(s) grant at least Read access. For example, a user who is denied access to the Resources node cannot create Building Blocks that include Resources.
  • You can only import those Building Block items into the related nodes to which your administrative role(s) grant Modify access, including all (sub)folders. For example, if a Building Block contains Resources and Modules, but you only have Modify access to the Resources node, it will only be possible to import Resources: the Modules in the Building Block will be disabled in the Import Building Block window.
  • If you only have Read access to the Console, it will not be possible to import Building Blocks and the import Building Block functionality will be disabled in the Console.

Was this article useful?    

The topic was:

Inaccurate

Incomplete

Not what I expected

Other