Page History

...

JobScheduler components use the following connections:

Network Connections

All network connections are unidirectional, as indicated by the direction of the arrows in the above diagram.

...

• Do not use the default configuration with local authentication for the JOC Cockpit REST Web Service.
  • Instead use LDAP authentication as explained in with the JOC Cockpit - Authentication and Authorization section.
• Do not allow any network connections to the JobScheduler Master and Agents except as stated above. This makes any authentication mechanism unnecessary.

Credentials Management

Database Credentials

...

• It is a bad idea to run a JobScheduler Master or Agent using a Unix root account or Windows Administrator account.
  • Certainly this makes life easy when it comes to switching to other user accounts or accessing files.
  • However, you should not grant more permissions to a process than required.
• Use specific user accounts to run JobScheduler Masters and Agents:
  • Do not use the system account (Windows) or root (Unix).
  • Create specific service accounts that are limited to privileges that are required to execute jobs.
• Do not specify credentials for Windows Service accounts during installation:
  • The installer will store such credentials in its installation response file (Master: jobscheduler_install.xml, Agent: jobscheduler_agent_install.xml)
  • Instead, use the Windows Service Panel to manually specify credentials for the service account.
• There are a number of options when it comes to running jobs for different user accounts:
  • For Unix environments
    • Your job scripts can switch to a different user context by use of sudo or su commands. sudo is the preferred option as this the standard Unix tool that allows secure configuration of the users that are allowed to execute certain commands (sudoers file). In addition sudo provides reporting capabilities about (ab)use of commands.
  • For Windows environments
    • You can use the Windows Credential Manager to safely store credentials of the user account that a job should be executed for. The JobScheduler will then read the credentials and create a new process to run a job in the target user context. This is the preferred solution as it does not store credentials with the JobScheduler configuration.
    • Find detailed information from the JobScheduler Universal Agent - Running jobs as a different user article.
  • For all environments
    • You can run a number of Agents in parallel for different user accounts.
    • For details see the JobScheduler Universal Agent - Running multiple instances article.
• For jobs that require credentials, e.g. to access a database, a credential store can be used, see the Using a Credential Store for Jobs article.
  • Credentials are not provided from parameters (that could be logged in clear text), instead an interface is provided that allows on demand access to the credential store. 
  • This feature is available for Shell jobs and for API jobs (JavaScript, PowerShell etc.).

File Transfer Credentials

...

• Use the YADE Credential Store to manage credentials centrally in a store that is referenced by YADE configuration items, see the How to set-up the Credential Store and YADE Parameter Reference - CredentialStoreFragment articles.
• Should you use FTP connections then consider to switch to use of SFTP.
• SFTP connections can be used with private/public key files, there is no need to use passwords for such connections.

Further Resources