Defining Users
A User object contains the configuration (personal data, password, privileges, authorizations, and so on) that an Automic Automation user needs to accomplish their tasks. As an administrator, you define User objects and assign them to the Client(s) to which they should have access.
As soon as you add a User object and give it a username and department, the User object opens to its definition pages. It consist of the following:
-
Common pages that are always available for all objects, no matter its type.
-
User-specific pages:
-
User page (described here)
-
User Groups page, see Assigning Users to User Groups
-
Automation Engine page
-
This page describes how to configure the User page
Defining Users: General Settings
In this section, you can define the following:
-
When you create a new User object, you specify its name and department on the Create User dialog. The User name/department combination is displayed in the Name filed, which is read only. You cannot change the User name here, for this purpose, you use the Rename function. For more information, see Renaming Objects and Folders.
-
By default, a newly created User is always active (the User is active checkbox is checked). If you uncheck this option, the User is set to inactive and is not allowed to log in.
When Users enter a wrong password multiple times, they will be locked and cannot log in anymore. You as an administrator configure the maximum number of invalid login attempts in the PWD_ATTEMPTS_MAX variable (see PASSWORD Parameters).
Important! If you deactivate a User under whose name there are still running tasks, those tasks will continue running.
-
The administrator or the LDAP Sync tool can activate the User is locked option to disable the User. This option is useful in the context of LDAP connections where the user in Automation Engine is synced regarding the state with the LDAP server.
-
Select LDAP Connection and Synchronize if your organization is using LDAP. This will synchronize the data with the LDAP server and the User data fields will be populated with the information contained in the directory service. This means that the User login will be authenticated by a directory service, such as the Microsoft Active Directory, rather than by the Automic Automation system.
If you activate this option, most of the fields on the page are disabled because data is retrieved from the directory service. The only fields that you can still specify here are the User Status options and Email 2.
You specify the LDAP connection parameters in the UC_LDAP_EXAMPLE variable (see UC_LDAP_EXAMPLE - LDAP Connection Variable).
Note: You can also activate the LDAP connection directly from the User list. Select one or more Users, right-click and select Activate LDAP Connection from the context menu. If you do so in Client 0, you can activate it for User from different Clients in a go.
-
The Distinguished Name (DN) field is only enabled if you have activated the LDAP connection. If you enter a value here, the distinguished name specified in the UC_LDAP_EXAMPLE variable will be ignored.
-
Optionally, enter the User's First/Last Names; they are displayed in various areas of the user interface.
-
Optionally, enter the E-Mail 1/E-Mail 2 addresses. If you have configure an SNMP connection, the User will receive alerts and notification in these email addresses. Automic Automation uses Email 1 as the primary address and will send alerts and notifications there. If you enter an address in Email 2, it will be used as a cc address.
You can enter up to 50 characters in the Email fields.
Defining Users: Password Policy
When you create a new User, its default password is pass. You must change it immediately after creating it or the user must change it when they first log in to the system.
As an administrator, you define the password policy to be adhered to in the PASSWORD variables (see PASSWORD Parameters). In this variable you define the required password structure, the intervals in which passwords must be changed, the number of failed login attempts that is allowed, the default password for new Users and so forth.
- Activate Change Password to assign the User a new password. This activates the password input fields.
- Enter the new password twice, once in Password and then again in Confirm password.
- Alternatively, activate User must change password at next login. The User will have to login first using the assigned password and change it after that.
- Activate Password never expires if your company's policy does not require regular password changes.
Tip: Avoid special national language characters (umlauts (ä), accents (è), special letters (ß), etc.) if Users are in various international locations. Not all keyboards in all countries support such characters.
Defining Users: Tokens
Automic Automation supports the following authentication methods, Basic Authentication and User Tokens. Depending on your User privileges, you can generate and manage tokens from two different AWI areas:
-
Users with access to their User object definition who have the Token access and token creation privilege.
You generate and manage your tokens in the Tokens section on the User page in the Administration perspective.
-
All Users, regardless of their User object definition
You generate and manage your tokens in the Tokens tab on the Settings dialog. For more information see Generating and Managing User Tokens.
User tokens have an expiration date. When a token expires, all requests result in an "Access denied" error message. This is why it is recommended that you create various tokens whose expiration dates overlap so that you can authenticate successfully at any time. System administrators can determine whether tokens are deleted automatically after they have expired in the DELETE_EXPIRED_TOKEN system variable.
Important!
For security reasons, only Automic Automation users can create their own tokens. Administrators CANNOT create the tokens for them. This restriction guarantees that knowledge about the tokens is safeguarded and limited to the User that will use them.
A token is always tied to a User object. However, bad practices when storing and/or using them can lead to accidentally exposing them publicly. It is recommended that you enforce a strong security policy to avoid these situations. These recommendations can help you with it:
-
Protect the token by separating your REST client from the location where you store the token,
-
Delete tokens that are no longer needed.
-
Rotate the tokens periodically and define expiration times that are no longer than necessary and that they comply with your company's security policy.
To Add a Token
-
Click Add Token.
-
On the Add Token dialog, enter the Token Name that is unique within your User definition. Specify a name that helps you remember the purpose of the key later on.
-
Specify an Expiration Date. You will not be ale to authenticate using this key once this date has passed.
-
Click Add.
-
The Token dialog is displayed. The Automation Engine automatically generates the token (an alphanumeric string) and displays it here.
Important! This is the only time in which you will be able to see the token. Once you close this dialog, you will not have access to it any more. Copy it now and save it elsewhere in case you need it later on.
-
Click Copy to Clipboard.
-
Paste the key in your REST client application or save it for later use.
-
Go back to AWI and click Close to return to the User page. The name of the token and its expiration date are added to the list, however, the key itself (the string) is not; the string is obfuscated and saved to the database.
To Remove Tokens
Select one or more tokens and click Remove. Once they are removed, your requests can no longer authenticate using them and will result in an "Access denied" error message.
To Export the Tokens
Click the Export Table button. The resulting CSV file contains the data from the Token Name and Expiration Date columns
For more information, see AE REST API Authentication.
Defining Users: Advanced Settings
In this section you can define the following:
-
Time Zone that will be applied to this User. If you leave this option empty, the Client's predefined Time Zone is used.
-
Default Login, which is the Login object that will be assigned to the objects used by this User object. The Login objects contains the credentials that the Agent needs to access the target system. For more information, see Login (LOGIN).
Defining Users: Session Settings
In this section you can restrict the login possibilities for this User.
-
Select Login Restrictions to limit the times and days that this User can log in to the system:
-
From / To
Specify the period of time in hours and minutes within which the User can log in to the system. Outside this time, any login attempt will be denied.
-
If Calendar Conditions Are Met
Select the Calendar and Calendar Event that contain the dates on which the User will be able to log in to the system. Login attempts outside these dates will be denied.
-
-
Max. Parallel Sessions
Select the maximum number of parallel logins you will allow for this User. 0 enables unlimited parallel access.
-
Min. Activity Refresh
Select the minimum time interval (in seconds) for refreshing the following views in the Process Monitoring perspective:
-
The list of Tasks
-
The Schedule Monitor
-
The Workflow Monitor
Process Monitoring users can customize these intervals on the User and session Settings dialog. However, the value that you enter here determines the value that users will see as default in the User and session Settings dialog. This table explains how:
Your parameter in "Min. activity refresh" Affects the "Default" value on the Settings dialog, which is ... And the "User Defined" value on the Settings dialog, which is ... Lower than 90 seconds 90 seconds
Taken over from Min. activity refresh 90 seconds
90 seconds
90 seconds Greater than 90 seconds
Taken over from Min. activity refresh Taken over from Min. activity refresh For more information, see Refresh Interval.
Notes:
-
By default, this value is 90 seconds, the minimum value is 10 seconds.
-
If the User clicks the Refresh button between the defined intervals, the system will ignore the new refresh request and finish processing the previous one. This prevents the system from getting jammed up with multiple refresh requests in rapid succession.
-
See also: