Creating a Basic Client/User Landscape

An Automation Engine system contains three clients: 0 (for overall administrative purposes), 500 (for creating objects, designing workflows, etc.) and 550 (for working with the already created objects). In this use case, the system administrator creates the necessary users and user groups, configuring their privileges and access rights to functions in an easy way and assigns them to the appropriate clients.

What Will You Learn?

How to create users and user groups.

How to assign rights and privileges.

How to duplicate and edit user definitions.

How to move users from one client to another.

How to export user groups from one client and import them in another.

Preliminary Considerations

With your Automation Engine installation, a standard user is provided in client 0 that contains all available rights and privileges, namely user UC (username) in department UC with password UC.

You need it to be able to log in for the first time and start configuring your system.

• Do not delete or rename user UC/UC/UC.

  Automic recommends duplicating the UC user and renaming the duplicate first thing after the installation. You can use the new, renamed user as system-wide administrator.

• Change its password immediately after the installation.
• Client 0 (also called system client) is already available when you install the Automation Engine. You use it to manage system-wide settings such as login information, calendars, variables, as well as to create users, user groups, clients, to set up agents, etc.

What Does this Use Case Cover?

One of the first configuration tasks is setting up your user management policy, that is, defining users, assigning them rights according to their roles in your company, defining user groups that help you manage such rights more efficiently, assigning the users to the appropriate clients, etc.

In this Use Case you will set up a system that consists of two clients:

• Client 500

  This is your DEVELOPMENT client, where users design PromptSets, create Jobs, build Workflows, etc.

• Client 550

  This is your OPERATIONS client, where users monitor processes, carry out reporting activities, register and process errors, etc.

You will create users (also client administrators) and assign them the rights they need to work in their respective clients. You will also create user groups; they help you easily and efficiently administer user rights.

The graphic below depicts the clients and their corresponding users, roughly indicating the rights they should have:

Prerequisites

Clients 500 and 550 are already available in your system.

Use Case Actors

1. Create two new Administrator users, one for client 500 and another one for client 550.

   You will need them for client-specific administration activities.

   To create a client administrator user you duplicate the system-wide administrator user (UC/UC) and, if necessary, you edit its rights. Then, you move it to the appropriate client.

   The administrator user for client 500 is called ADM_DEVELOPMENT; the one for client 550 is called ADM_OPERATIONS:

   1. Log in to client 0 with the UC/UC/UC user credentials.
   2. On the menu bar at the top of your screen click at the right hand side of the Home button.

   3. A dropdown menu opens that displays all the perspectives:

      

   4. Select Administration to open the Administration Perspective.
   5. On the Administration pane on the left hand side, click User Management to expand it.
   6. Click Users.
   7. Right-click the UC user and select Duplicate.

   8. On the Duplicate User dialog enter the name and department of the client 500 administrator user:

      

   9. Click OK.

      The ADM_DEVELOPMENT user is now available in the Users list and has the same setup and rights originally assigned to ADMIN_ALL.

      Optionally, edit it to assign it a password. In our use case we will leave it without password.

   10. Right-click ADM_DEVELOPMENT in the Users list and select Open.

   11. The ADM_DEVELOPMENT definition pages open up on the User page. In the Password section set up the following to make sure that you need not enter a password when you log in using it.

       

   12. Save the user.
   13. Repeat these steps to create the administrator user for client 550 calling it ADM_OPERATIONS.

2. Move ADM_DEVELOPMENT to client 500 and ADM_OPERATIONS to client 550.

   1. Right-click ADM_DEVELOPMENT and select Move User.

   2. The Move User to Client dialog is displayed, where you select the target client:

      

      Alternatively, type the name of the client in the Client input field.

   3. Click Move.
   4. Repeat these steps to move ADM_OPERATIONS to client 550.

   ADM_DEVELOPMENT and ADM_OPERATIONS are now available in clients 500 and 550 respectively. You can log in to those clients using these credentials.

3. Log in to client 500 with the ADM_DEVELOPMENT credentials to create the following:

   • A User Group called DEVELOPERS that has the rights and privileges necessary to work as a developer in client 500.
   • The developer Users that will work in client 500.

4. Create the DEVELOPERS User Group.

   1. On the Administration pane on the left hand side, expand the User Management section and click UserGroups.

   2. Click on the toolbar.

   3. On the Add UserGroup dialog enter the name of the group. In our case, this is called DEVELOPERS.

      

   4. The UserGroup definition pages open up displaying the Automation Engine > Authorizations sub page, where you grant/deny permissions to objects.

      

      How it works:

      Authorization Groups (Grp. column)

      You can assign up to 9 Authorization Groups to a User Group definition. They are groups of settings by which you grant the user group certain rights (read, write, delete, etc.) to a specific type of object.

      In our use case, users that belong to the DEVELOPERS User Group must be able to design and test the behavior of Scripts, Jobs, File Transfers, Workflows, Schedules, PromptSets and Variable objects. However, they must not have access to any operation associated to Calendar objects.

      Their Authorizations definition could be as follows:

      

      Selecting NOT in the Grp column means that you deny the group the selected rights for the object Type.

   5. Next you determine the functional areas to which the users in the DEVELOPERS User Group should have access rights. For this purpose, open the Privileges sub page and activate the checkboxes next to the functions for which you want to grant privileges.

      Expand this section to see possible configurations

      Access to Explorer Folders

      This controls the user access to special folders available on the Explorer navigation pane in the Process Assembly perspective. Transporting objects from one client to another is not part of the activities of this group, so you grant it all rights except this one:

      

      Administration

      This controls the access to administration activities. The only task for which this user group must have rights is starting objects without having to specify a Login object (they have no authorization to Login objects):

      

      AWI Access Control

      This control the access to perspectives and other working areas in the Automic Web Interface. DEVELOPERS need access to the Process Assembly perspective (where they design the objects), to the Process Monitoring perspective (where they check the performance of their objects) and to the Messages (for troubleshooting):

      

      Advanced Editing

      We are going to skip this as users in the DEVELOPERS group will not need any right concerning it.

      View Messages

      Users in this group need read rights to all messages except those meant for system administrators:

      

      Access Control

      Users in this group need access to deactivated tasks; they should be able to manipulate tasks statuses and to assume task ownership:

      

5. Create the first developer User.

   Duplicate the ADM_DEVELOPMENT user, rename it to JOE/DEV.

   1. In the Users list click Add User on the toolbar.

   2. On the Create User dialog enter the Username (JOE) and (optionally) the department (DEV).

      

   JOE/DEV is now available in the Users list in client 500. It has all rights and privileges of the ADM_DEVELOPMENT user, so you must change this.

6. Assign JOE/DEV to the DEVELOPERS User Group.

   This way, you automatically grant it the rights and privileges of that group without having to define anything specifically for the user.

   1. In the Users list, right-click JOE/DEV and select Open. Alternatively, double-click it.
   2. Open the UserGroups page. Here is where you assign the user to an existing user group.

   3. Select DEVELOPERS in the Not Member of column and click the arrow to insert it in the Member of column:

      

   4. Save your changes

   User JOE/DEV has now all necessary rights to work as a developer in your company.

7. Create the other developer user in client 500.

   1. In the Users list, right-click JOE/DEV and select Duplicate.
   2. On the Duplicate User dialog enter the name and department of the new user, in this case ARF/DEV.

   3. Click OK.

      The ARF/DEV user is now available in the Users list and has the same setup and rights originally defined for JOE/DEV including its User Group assignment.

The setup of client 500 is now finished )the client administrator, the User Group and the Users are configured). You can now reuse these definitions for setting up client 550.

8. Export the DEVELOPERS User Group from client 500.

   When you create a User Group in the Administration Perspective, this group is also available as object in the AUTOMIC root folder in the Process Assembly perspective. To move it from one client to another, you must export the User Group object from the Process Assembly perspective and import it in the target client.

   1. Search for the DEVELOPERS user group object. You have two possibilities:

      • Switch to the Process Assembly perspective; the DEVELOPERS object is available in the objects list.
      • Use the Global Search functionality. This is useful if you already have many objects in the list and finding it is difficult.

   2. Right-click it and select Import / Export.

   3. On the Import / Export Objects dialog activate the Export and Settings: Export with references options and click Export.

      

   4. The XML file containing the User Group information is saved to your default Downloads folder.

9. Export the users from client 500.

   You want both developer users to have read rights to the objects in client 550. For this purpose, you export their definitions from client 500, import them in client 550 and edit them there.

   1. Log in to client 500 using the ADM_DEVELOPMENT credentials.
   2. Switch to the Process Assembly perspective and search for the two User objects you want to export (JOE/DEV and ARF/DEV).
   3. Right-click both and select Import / Export.

   4. On the Import / Export Objects dialog activate Export and click the Export button.

      

   5. The XML file containing the data on the User objects is saved to your default Downloads folder.

10. With all reusable definitions being already available for importing, log in now to client 550 with the ADM_OPERATIONS user credentials.

11. Import the DEVELOPERS User Group to client 550.

    1. Open the Process Assembly perspective and right-click anywhere in the objects list to select Import / Export.

    2. On the Import / Export Objects dialog click the upload icon:

       

    3. Select the XML file where you have exported the DEVELOPERS User Group definitions and click Open.

       The DEVELOPERS user group is now in client 550. It grants read, write, execute, etc. rights to its users. However, you want users associated with this User Group to have only Read rights in client 550, so you have to edit the User group.

12. Edit the DEVELOPERS User group in client 550.

    1. Switch to the Administration Perspective and open the User Group list.
    2. Right-click DEVELOPERS and select Open.
    3. Open the Authorizations sub page and deactivate all checkboxes except those in the R-Read column.
    4. Save your changes.

13. Import the developer users to client 550.

    1. Switch to the Process Assembly perspective and right-click anywhere in the objects list to select Import / Export.

    2. On the Import / Export Objects dialog click the upload icon:

       

    3. Select the XML file where you have exported the the user definitions and click Open.

       The two users are now available in the Users lists of client 550. They have the rights and privileges that are defined in the DEVELOPERS User Group in client 550, that is, only Read rights to the objects.

14. Create the OPERATIONS User Group. It has the rights and privileges necessary to work as an operator in client 550.

    Operator users work with the same objects as the developers. However, they do not design objects or write scripts, so they do not need some of the authorizations that developers do.

    Their Authorizations definition could be as follows:

    

    Define their Privileges.

    Expand this section to see possible configurations

    

    

15. Create the OPERATORS user.

    1. In the Users list click Add User on the toolbar.

    2. On the Create User dialog enter the name and (optionally) the department of the user:

       

    3. Save your changes.

16. Assign MAR/OPS to the OPERATORS user group.

    This way, you automatically grant it the rights and privileges of that group without having to define anything specifically for the user.

    1. Switch to the UserGroups page.

    2. Select OPERATORS in the Not Member of column and click the arrow to insert it in the Member of column.

    3. Save your changes.

Congratulations, you're done!

Useful Links

This use case contains references to a number of functions that you might want to know a bit more about.

• Information on client 0 - System Client 0000
• Global Search
• Importing/Exporting Objects