Argent Job Scheduler supports several ways to define the log on credentials used when a job is submitted to an Argent Queue Engine server for execution.

This help article discusses the supported options and describes several different techniques.

Default Queue Engine Account vs ‘Run-As’ Credentials

When a job is submitted to Argent Queue Engine for execution, it typically uses the default account defined to the Argent Queue Engine service.

This is common since many Argent customers prefer to configure their Queue Engine servers as ‘lock-down’ environments where as few user accounts and privileges are defined as possible. This improves overall security and simplifies security administration within the enterprise.

When a job must run under a different user account, it needs to supply ‘Run-As’ credentials.

Job Class

In Argent Job Scheduler, a job class serves two important functions:

1) Grouping: Job definitions (templates) are grouped by job class on the main J1 Control Panel display

2) Credentials: A job class allows customers to provide ‘Run-As’ credentials that will be in effect when a submitted job executes on an Argent Queue Engine server

Account Mapping

Argent Job Scheduler supports a technique called Account Mapping in which one or more user accounts can be mapped from the Job Scheduler server’s security credentials to the credentials on a Queue Engine server.

Although account mapping is most commonly used between Job Scheduler (Windows) and non-Windows Argent Queue Engine servers, it can be used for Windows Queue Engine servers as well.

Configuring the Argent Queue Engine Default Account

When Argent Queue Engine is installed, the setup program prompts for the account and password to be used to start and execute the Queue Engine service.

After installation, the Windows Service Control Manager display for Argent Queue Engine will appear similar to the following:

Click For Full Size

The user account and password is required by Windows for normal operation of the Argent Queue Engine service.

The Argent Queue Engine setup program also stores the user account and password as the default account for executing jobs submitted to the Queue Engine server.

To configure the default account for executing jobs, use the Argent Queue Engine Control Panel and navigate to :

System –> Configuration Options

Double-click the ‘Security’ branch. The following display (Screen ID D97B) will be shown:

Click For Full Size

In the example, the default account and password are the same as provided during installation and setup.

The user account and password needed by Windows for normal operation of the Argent Queue Engine service (Service Account) can be different than the Argent Queue Engine default account used for executing jobs submitted to Argent Queue Engine.

Typically, the service account is an Administrator on the Queue Engine server. This is because the service account requires a high degree of privileges.

All Queue Engine accounts that execute jobs on a Queue Engine server must have the following privileges configured in the Domain Security Policy, including the Queue Engine default account:

• Adjust memory quotas for a process
• Allow log on locally
• Debug programs
• Impersonate a client after authentication
• Log on as a batch job
• Replace a process level token

These privileges can be granted specifically to the Queue Engine default account.

Alternatively, a Group Policy Object can be created that has these privileges and the Queue Engine default account can be made part of the Group Policy.

Because of the high level of privileges required, many Argent Queue Engine customers are comfortable using the same account and password for both the Windows Service account and the Queue Engine default account.

Configuring Argent Job Scheduler Job Classes

Once the Argent Queue Engine has been configured properly, Job Classes can be configured to take advantage of the Queue Engine configuration.

To configure a job class in Argent Job Scheduler, navigate to the Job Templates branch of the left-hand tree pane.

To create a new job class, click on the server type, right-click then select ‘New Job Class’ from the drop-down menu:

Click For Full Size

To modify an existing job class, click on the class name, right-click, then select ‘Job Class Property’ from the drop-down menu:

Click For Full Size

The Job Class Properties display (Screen ID J120) is shown:

Click For Full Size

Type the Job Class name in the edit box provided.

Referencing the Queue Engine Default Account in the Job Class

Note that the ‘Execute job under default account of the Argent Queue Engine’ option is checked by default on screen J120.

To accept the default, simply click OK.

Now all job templates created under the job class are configured to use the Queue Engine default account configuration described above.

Configuring a Specific Queue Engine Account in the Job Class

What if a specific Queue Engine account is needed?

This might be desirable in cases where an application running on the destination Queue Engine server has very specialized security requirements for auditability and control.

One example might be a heavily secured payroll application.

To reference a specific Queue Engine account in the job class, the Queue Engine account must exist and be configured properly.

Reminder: All Queue Engine accounts that execute jobs on a Queue Engine server must have the following privileges configured in the Domain Security Policy, including the Queue Engine default account:

• Adjust memory quotas for a process
• Allow log on locally
• Debug programs
• Impersonate a client after authentication
• Log on as a batch job
• Replace a process level token

These privileges can be granted specifically to the Queue Engine default account or through a Group Policy Object.

The account created must be defined to Windows on the Queue Engine server but does not have to be defined or configured within Argent Queue Engine. Only the Queue Engine Default Account needs to be defined to Argent Queue Engine.

To configure the specific account, uncheck the ‘Execute job under default account of the Argent queue Engine’ option on screen J120:

Click For Full Size

Type the user name, domain name, and password in the edit boxes provided, then click ‘Ok’ to accept your changes.

Notes:

Controlling End User Access to Job Details Using the Job Class

To limit access by Job Scheduler end users to job information, use the ‘Permissions of Jobs in This Job Class’ section of screen J120.

Generally, it’s useful to provide administrators access to all of the capabilities controlled by the job class:

• Read (Read job information about jobs within the job class)
• Change (Change job template information for jobs within the job class)
• Submit (Submit jobs within the class for execution on a Queue Engine server)
• Control (Cancel, hold, release, or abort jobs within the job class)

For most users, it’s sufficient to provide ‘Read’ access to jobs within the class.

In the example above, the group ‘Everyone’ has been granted ‘Read’ access. Only members of the Administrators group have all privileges.

Often, a departmental manager in an enterprise is given both ‘Submit’ and ‘Read’ privileges so the manager can initiate jobs and view them, but can not change job definitions (templates) and can not hold, cancel, or abort jobs within the job class.

For most Argent Job Scheduler customers, the ‘Change’ privilege and the ‘Control’ privilege is limited to users and groups that fully understand the implication of their actions and are authorized to do so.

The ‘Permissions of Jobs in This Job Class’ section of screen J120 allows customer to configure either specific user accounts, user group names, or both.

Exceptions to The Rule: Overriding Argent Job Scheduler Job Classes

The chief benefit of using Job Classes to implement credentials for jobs that execute on an Argent Queue Engine server is that security information does not have to be repeated for each job template within the job class.

When security credentials or privileges need to be changed, using job classes in Argent Job Scheduler affords the greatest convenience by allowing customer to make the fewest changes possible to meet their needs.

Occasionally, there are exceptions to the security credentials rule expressed in a job class.

Example #1: Job Class FTP_PRODUCTION_JOBS uses the ‘Execute job under the default account of the Argent Queue Engine’ default option. One job within the class requires special permissions to run.

Example #2: Job Class ALL_PROD_BATCH uses a general purpose set of credentials useful for most batch jobs. One job within the class runs a report that launches a GUI dialog prompt to collect report parameters before running the desired report.

In both of the above examples, a template-level override of the rule expressed in the job class must be provided for normal execution of the job that does not follow the job class rule.

Configuring Job Template-Level Exceptions to the Job Class Rule

To configure Job Template-level exceptions to the job class rule, navigate to the individual job within the class then click the ‘Users and Security’ icon. The Job Security display (screen ID J20B) is shown:

Click For Full Size

On the J20B display, an exception to the Job Class rule can be configured.

Available options:

• Execute Job Under Default Account Of The Argent Queue Engine
• Use Password Setting Specified in the Job Class Table
• Use This Password (GUI Programs Must Use This Option)

Use the Job Security display (screen ID J20B) to configure exceptions to the rule specified at the Job Class level then click ‘Ok’.

The Job Security display of the Job Template need only be used to configure an exception to the rule expressed at the Job Class level, either for security credentials or for job information access privileges.

Example #1:

1) The Job Class expresses the ‘Execute job under the default account of the Argent Queue Engine’ option

2) The Job Template-level ‘Job Security’ display (Screen J20B) expresses the ‘Execute Job Under Default Account Of The Argent Queue Engine’ option, and the ‘Read’, ‘Change’ ‘Submit’, and ‘Control’ privileges are the same at both the Job Class level and the individual Job Template level, then the Job Security display at the Job Template level is redundant, requires additional database storage unnecessarily, and wastes valuable CPU resources at run time.

Example #2:

1) The Job Class expresses the ‘Execute job under the default account of the Argent Queue Engine’ option

2) The Job Template-level ‘Job Security’ display (Screen J20B) expresses the ‘Execute Job Under Default Account Of The Argent Queue Engine’ option

3) The Job Template-level ‘Job Security’ display expresses a different list of users and groups authorized to ‘Read’, ‘Change’, ‘Submit’, and ‘Control’ jobs than is expressed at the Job Class level

4) In this case, there is no redundancy because the Job Template-level override is needed to express an override of the job information access privileges

Advanced: Account Mapping

When a job needs to execute on a Queue Engine server that does not follow the Windows security model, it is often important to provide a way to ‘map’ users from one platform’s security approach to another.

Examples include:

• Windows Job Scheduler user needs to submit jobs to run on a UNIX / Linux Queue Engine
• Windows Job Scheduler user needs to submit jobs to run on Argent Job Scheduler Adapter for iSeries
• Windows Job Scheduler user needs to submit jobs to run on an SAP server
• Windows Job Scheduler needs to submit jobs to run in a ‘foreign’ (i.e. non-trusted) domain

Example: UNIX / Linux

In cases where the destination Argent Queue Engine server is implemented on UNIX or Linux, user accounts in Windows do not map natively to UNIX / Linux accounts.

Job Class definitions and Job Template-level overrides might need to refer to a UNIX / Linux account instead of a Windows user account.

Example: IBM iSeries

In cases where the destination server is implemented using the Argent Job Scheduler Adapter for iSeries, user accounts in Windows do not map natively to IBM iSeries user profiles.

Job Class definitions and Job Template-level overrides might need to refer to an IBM iSeries user profile instead of a Windows user account.

Argent Job Scheduler provides a facility called ‘User Account Mapping’ that performs an at-the-last-minute translation from normal Windows user account structure to the user account structure native to the destination execution platform.

Example: ‘Foreign’ (i.e. Non-Trusted) Windows Domains

In cases where the destination server is implemented by Argent as a regular Windows Queue Engine but the domain of the Job Scheduler server is not a trusted member of the destination Windows Queue Engine server, it is common for a Job Scheduler user to have two accounts in two separate domains.

Configuring User Mapping in Argent Job Scheduler

To configure User Mapping using the Job Scheduler Control Panel, navigate to the ‘Servers Where Jobs Run’ branch of the left-hand-tree pane.

Click on any of the server types listed.

Right-click then select ‘Remote/UNIX/iSeries/SAP Server Management’ from the drop-down menu:

Click For Full Size

The Remote/UNIX/iSeries/SAP Server Management’ Display (Screen ID J87) is displayed. Click on the ‘Account’ tab. The J87B display is shown:

Click For Full Size

The J87B display allows Argent Job Scheduler customer to configure a mapping of Windows account information local to the Argent Job Scheduler server to accounts on:

• UNIX / Linux Queue Engine servers
• Argent Job Scheduler Adapters for iSeries
• SAP
• ‘Foreign’ (i.e. Non-Trusted Windows domains)

On the J87B display, click ‘New’ to provide a new account mapping:

Click For Full Size

Specify the destination server information for the ‘Target Server:’ prompt.

Specify the local Windows Job Scheduler account related to the destination server.

Specify the Server Account to which the local Windows account will be mapped.

Specify the password on the destination server that applies to the ‘Server Account’ just specified.

Click ‘Close’ to save your changes and continue.

The J87B display allows Argent customers to enhance and extend the Job Class-level configuration capability and the companion Job Template-Level Override capability by allowing customers to logically map local Windows user account information into the native forma used by important destination servers.