Page History
Table of Contents |
---|
Scope
Introduction
- JS7 products The JobScheduler components are easy to install out-of-the-box. However, a number of configuration items have to should be considered when operating the JobScheduler JS7 for a secure environment.
- Secure operation is applied at to the following areas:
- Connection Management
- Network Connections
- Database Connections
- Access Management
- Authentication
- Authorization
- Credentials Management
- Database Credentials
- Job Credentials
- Connection Management
- Secure operation includes users configuring JobScheduler components JS7 products in a compliance-conformant way.
Connection Management
JobScheduler components JS7 products use the following connections:
...
title | article to be reworked |
---|
Network Connections
All network connections are unidirectional, as indicated by the direction of the arrows in the above diagram.
Default Configuration
The following default configuration is implemented by the installer if users do not modify settings during installation:
- All network connections make use of HTTP
- Connections from a user browser to the JOC Cockpit
- Connections from the PowerShell CLI to the JOC Cockpit REST Web Service
- Connections from the JOC Cockpit REST Web Service to the JobScheduler Master
- Connections from the JobScheduler Master to Agents
- Port Usage
- The JOC Cockpit can be accessed at port 4446
- The JOC Cockpit REST Web Service can be accessed at port 4446
- The JobScheduler Master uses the following ports:
- Access to the JobScheduler Master Web Service at port 40444
- Access to the JobScheduler Master via TCP at port 4444
Display feature availability EndingWithRelease 1.12 - Access to the JobScheduler Master via UDP at port 4444
Display feature availability EndingWithRelease 1.12 - The TCP port 4444 and HTTP port 40444 enable access to the "classic" JOC GUI.
Jira server SOS JIRA columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 6dc67751-9d67-34cd-985b-194a8cdc9602 key JOC-304
- The JobScheduler Agent listens to port 4445
- Network Interface Usage
- By default JobScheduler components will listen to the above mentioned ports on all available network interfaces.
- Firewall Settings
- Open ports in your firewall exclusively for the hosts, protocols and ports as specified above. Consider allowing connections only for the directions indicated in the diagram above.
Secure Configuration
The following recommendations should be applied to ensure secure network connections.
- Configure network connections to use HTTPS
- The use of HTTPS includes users providing valid certificates for the hosts that JobScheduler components are operated for. The use of self-signed certificates is a no-go.
- As HTTPS is restricted to secure the connection, in addition authentication is added to the configuration, e.g. when using HTTPS then a JobScheduler Master is configured to authenticate with an Agent in order to guarantee that the Master is what it claims to be and is entitled to access an Agent.
- For detailed instructions on the configuration see:
- JOC Cockpit - HTTPS Authentication explains HTTPS configuration for the JOC Cockpit and connection to the JobScheduler Master.
- JobScheduler Universal Agent - HTTPS Agent and Master Authentication
- Drop the JobScheduler Master TCP / UDP port:
- This port is not required for standard operation with releases starting from 1.11.
- This port is required for previous releases that include the "classic" JOC GUI running in the JobScheduler Master.
- Access to this port can be restricted with the
<allowed_host>
setting in./config/scheduler.xml
- Access to this port can be restricted with the
- This port is required for all releases if a JobScheduler Supervisor is used.
- Restrict use of network interfaces
- Consider restricting JobScheduler components to only listen to specific network interfaces.
- The JobScheduler Master can be configured by use of the
http_port
andhttps_port
attributes in the./config/scheduler.xml
configuration file. - Configure the JobScheduler Universal Agent to use the
SCHEDULER_HTTP_PORT
andSCHEDULER_HTTPS_PORT
environment variables in the JobScheduler Agent instance script.
- Drop the "classic" JOC GUI
- The "classic" JOC GUI ships without authentication and authorization. It is included with release 1.11 for users who stick to this interface. It is available from the above TCP port and HTTP port.
Display feature availability EndingWithRelease 1.12 - To drop the "classic" JOC GUI remove the
SCHEDULER_HOME/operations_gui
folder.
- The "classic" JOC GUI ships without authentication and authorization. It is included with release 1.11 for users who stick to this interface. It is available from the above TCP port and HTTP port.
Database Connections
All database connections are based on JDBC. If JDBC type 4 drivers are used then a DBMS client is not required for operation of JobScheduler components. JobScheduler components use Hibernate as their database access layer.
Default Configuration
- JobScheduler ships with JDBC Drivers that are open source or that are free for bundling with our software.
- The installer allows
- to specify alternative JDBC Drivers that can be downloaded from the relevant vendor's web site.
- to specify individual Hibernate configuration files with security related settings.
- For details see Which Database Management Systems are supported by JobScheduler?
Secure Configuration
- Depending on the DBMS in use it may be preferable to download and to apply the DBMS vendor's current JDBC Driver version:
- For use with MySQL the JDBC Driver is not included with JobScheduler. Instead a MariaDB driver is provided.
- For use with Microsoft SQL Server the JDBC Driver is not included, instead the jTDS Driver is provided. In order to apply integrated security (see below chapter Credentials Management) it is recommended that a current Microsoft JDBC Driver is applied.
- For use with Oracle newer JDBC Driver versions are available from the vendor's web site.
- Vendor-specific JDBC Drivers include support for specific authentication mechanisms, e.g. use of JDBC with Oracle Wallet.
- Consider additional security related settings that apply to your DBMS in the Hibernate configuration files:
- JobScheduler Master
- for access to the reporting database:
./config/reporting.hibernate.cfg.xml
- for access to the JobScheduler database:
./config/hibernate.cfg.xml
- for access to the reporting database:
- JOC Cockpit
- for access to the reporting database:
./resources/joc/reporting.hibernate.cfg.xml
- for access to the JobScheduler database:
./resources/joc/jobscheduler.hibernate.cfg.xml
- optionally different locations of Hibernate configuration files can be set in
./resources/joc/job.properties
for access to additional JobScheduler databases
- for access to the reporting database:
- JobScheduler Master
Access Management
Access to JobScheduler components is centrally secured by the JOC Cockpit REST Web Service.
Default Configuration
- Consider the hints from the JOC Cockpit - Security article
- The JOC Cockpit REST Web Service ships with a default configuration in
./joc/resources/joc/shiro.ini
that includes- using local authentication with accounts and passwords stored in clear text.
Display feature availability EndingWithRelease 1.11.4 - using local authentication with accounts and passwords stored as hash values.
Display feature availability StartingFromRelease 1.11.5 - using local role assignment
- the following default values for accounts, passwords and assigned roles (see JOC Cockpit - Authentication and Authorization for more informatio):
administrator=secret, administrator
application_manager=secret, application_manager
it_operator=secret, it_operator
incident_manager=secret, incident_manager
business_user=secret, business_user
api_user=secret, api_user
root=root, all
- using local authentication with accounts and passwords stored in clear text.
- The JobScheduler Master is assumed not to be accessed by users directly but exclusively via the JOC Cockpit REST Web Service. No default authentication is provided.
- JobScheduler Universal Agents are assumed not to be accessed by users directly but exclusively by a JobScheduler Master. No default authentication is provided.
Secure Configuration
- Do not use the default configuration with local authentication for the JOC Cockpit REST Web Service.
- Instead use LDAP authentication as explained with the JOC Cockpit - Authentication and Authorization section.
- Do not allow any network connections to the JobScheduler Master and Agents except as stated above.
Credentials Management
Database Credentials
Default Configuration
- Database credentials are specified during installation and are added to the following Hibernate configuration files:
- JobScheduler Master
- for access to the reporting database:
./config/reporting.hibernate.cfg.xml
- for access to the JobScheduler database:
./config/hibernate.cfg.xml
- for access to the reporting database:
- JOC Cockpit
- for access to the reporting database:
./resources/joc/reporting.hibernate.cfg.xml
- for access to the JobScheduler database:
./resources/joc/jobscheduler.hibernate.cfg.xml
- optionally different locations of Hibernate configuration files can be set in
./resources/joc/job.properties
for access to additional JobScheduler databases
- for access to the reporting database:
- JobScheduler Master
- No default values are provided by the installer.
Secure Configuration
- Do not use passwords.
- Users frequently ask if JobScheduler can encrypt credentials. The answer is "no" as it makes no sense for an Open Source software component to handle a symmetric key.
- There is one way only how to handle passwords: not to use them.
- Use Integrated Security
- This authentication scheme starts from the fact that the account that a component is operated for is already authenticated and therefore can access a database without specifying user/password credentials.
- This feature is available for a number of DBMS such as
- Microsoft SQL Server, see the How to connect to an SQL Server with a domain account article.
- Oracle that includes support for Oracle Wallet, see How to connect to an Oracle database without using passwords
Job Credentials
Default Configuration
- The Windows Service for the JobScheduler Master and Agent runs in the system account.
- The installer allows to specify a different account and to add credentials for that account.
- By default jobs are executed in the context of the account that the JobScheduler Master or JobScheduler Agent are operated for.
Secure Configuration
The above diagram suggests that the JOC Cockpit is the only JS7 product that is directly exposed to user access.
- This allows to operate JS7 products in different network zones. JOC Cockpit can be located in a deployment zone from which users deploy workflows. Controllers and Agents can be operated in more secure network zones.
- The underlying principle is to allow connections from a less secure deployment zone to more secure zones and to deny connections to go the opposite way.
- If jobs are operated on JS7 Agents that require access to the JS7 REST Web Service API then it is recommended to set up additional JOC Cockpit API Server instances. Such instances do not include the user interface but serve the REST Web Service API only. Any number of API Server instances can be set up & operated in parallel and they can be located close to JS7 Agents.
Network Connections
All network connections are unidirectional, as indicated by the direction of the arrows in the diagram above.
Default Configuration
The following default configuration is implemented by the installer if users do not modify settings during installation:
- All network connections make use of HTTP:
- Connections by users to the JS7 - Browser User Interface
- Connections by the PowerShell CLI or external applications to the JS7 - REST Web Service API
- Connections by the JOC Cockpit to the JS7 Controller using the JS7 REST Web Service API
- Connections by JS7 Controller instances to Agents
- Port Usage
- The JOC Cockpit can be accessed at port 4446
- The JOC Cockpit REST Web Service can be accessed at port 4446
- The JS7 Controller uses port 4444
- The JS7 Agent listens to port 4445
- Network Interface Usage
- By default JS7 products will listen to the above mentioned ports on any available network interfaces.
- Firewall Settings
- Open ports in your firewall exclusively for the hosts, protocols and ports as specified above. Consider allowing connections only for the directions indicated in the diagram above.
Secure Configuration
The following settings are recommend to ensure secure network connections:
- Configure network connections to use HTTPS:
- Use of HTTPS includes providing certificates for the hosts that JS7 products are operated for. Private CA-signed Certificates and Public CA-signed Certificates are both acceptable. For details see JS7 - How to create X.509 SSL TLS Certificates.
- As HTTPS is limited to secure connections, additional authentication is required. In this case, a JS7 Controller instance is configured to authenticate with an Agent in order to guarantee that the Controller instance is in fact, what it claims to be and is entitled to access the Agent.
- The JS7 - Secure Connections article explains the use of the built-in Certificate Authority and the use with external Certificate Authorities.
- For detailed instructions for configuration see:
- JS7 - JOC Cockpit HTTPS Connections, which explains HTTPS configuration for the JOC Cockpit and connection to the JS7 Controller.
- JS7 - Controller HTTPS Connections
- JS7 - Agent HTTPS Connections
- Restrict use of network interfaces:
- Consider restricting JS7 products to only listen to specific network interfaces.
- The JS7 Controller can be configured by use of the
--http-port
and--https-port
command line options to specify network interfaces, see the JS7 - Controller - Command Line Operation article for details. - The JS7 Agent can be configured by use of the
--http-port
and--https-port
options to specify network interfaces, see JS7 - Agent Command Line Operation. - The JOC Cockpit can be similarly configured to only use specific network interfaces, see:
Database Connections
The JOC Cockpit API Service is the only JS7 product that uses a database.
Database connections are based on JDBC. If JDBC type 4 drivers are used then a DBMS client is not required for the operation of the JOC Cockpit. The Hibernate access layer is used for database access.
Consider DBMS vendor instructions how to set up secure connections to the database,
Default Configuration
- JS7 ships with JDBC Drivers that are open source or that are free for distribution with JS7.
- The JOC Cockpit installer allows:
- specification of alternative JDBC Drivers that can be downloaded from the respective vendor's web site.
- specification of individual Hibernate configuration files with security related settings.
- For details see the JS7 - Database article.
Secure Configuration
- Depending on the DBMS version in use it is preferable to download and apply the DBMS vendor's current JDBC Driver version:
- For use with MySQL® the JDBC Driver is not included with JS7. Instead a MariaDB® driver is provided for access to MySQL® databases.
- For use with SQL Server® the JDBC Driver is not included. Instead users have to download a current JDBC Driver from the vendor's site.
- For use with Oracle® the JDBC Driver is included. Newer JDBC Driver versions might be available from the vendor's web site.
- Vendor-specific JDBC Drivers include support for specific authentication mechanisms. For example
- the use of JDBC with Oracle Wallet, see JS7 - How to make JOC Cockpit connect to an Oracle database using Wallet®,
- the use of JDBC with Integrated Security, see JS7 - How to connect to an SQL Server database without using passwords.
- Consider additional security related settings that apply to your DBMS in the Hibernate configuration file. For the location of this file see the JS7 - Database article.
Access Management
Access to JS7 products is centrally secured by the JS7 - REST Web Service API. This interface is used by the JS7 - Browser User Interface and by external applications using the REST API.
Roles and Permissions
Default Configuration
- Refer to the hints provided in the JS7 - JOC Cockpit - Secure Operation article.
- The JOC Cockpit by default ships with the
JOC-INITIAL
Identity Service, see JS7 - Identity Services which includes:- use of the JS7 - JOC Identity Service for authentication with user accounts and passwords stored as hash values in the JS7 - Database.
- use of local role assignment,
- the following default values for user account, password and assigned roles (see JS7 - Manage User Accounts for more information):
- Active User Account:
- user account:
root
- password:
root
- user account:
- Active Role:
all
- Available Roles:
administrator
all
api_user
application_manager
business_user
incident_manager
it_operator
- Active User Account:
- no other accounts are available by default.
- The JS7 Controller is not accessed by users but exclusively by the JOC Cockpit via the JS7 - REST Web Service API.
- Default authentication for the connection from the JOC Cockpit to the Controller is provided by asymmetric passwords available with:
- the JS7 - Settings page in section "joc" with the settings
controller_connection_joc_password
andcontroller_connection_history_password,
- the Controller's
private.conf
file which holds thepassword
setting by default as a hashed value.
- the JS7 - Settings page in section "joc" with the settings
- It is recommended that JS7 - Certificate based Authentication using HTTPS connections with mutual authentication is implemented, see JS7 - Controller HTTPS Connections.
- Default authentication for the connection from the JOC Cockpit to the Controller is provided by asymmetric passwords available with:
- JS7 Agents are not accessed by users but exclusively by a JS7 Controller. Default authentication is not provided.
Secure Configuration
- Using the default
root
user account that ships with the JOC Cockpit is not recommended. The default user account is intended to enable initial login only. - A fine-grained set of permissions is available that can be applied to any operation in the JOC Cockpit and in the JS7 REST Web Service API. Such permissions can freely be grouped to roles, see JS7 - Authorization.
- JS7 - Identity Services offer a number of authentication methods that can be combined for single-factor and multi-factor authentication (MFA).
- The JS7 - LDAP Identity Service can be used to establish role assignment for users based on membership in LDAP Directory Service security groups.
- The JS7 - Certificate Identity Service and JS7 - FIDO Identity Service can be used for MFA.
Identity Services
Default Configuration
- JS7 - Identity Services offer a number of authentication methods such as LDAP, OIDC, FIDO2 etc.
- By default access to the JOC Cockpit is ruled by local authentication management from the JS7 - JOC Identity Service. This Identity Services stores hashed credentials in the database.
- No other Identity Service is active by default.
Secure Configuration
- Users can switch to one of the supported Identity Services such as
- JS7 - LDAP Identity Service,
- LDAP Directory Services can be accessed for authentication and authorization:
- users can connect by specifying their domain account.
- membership in security groups can be optionally mapped to roles managed with JOC Cockpit.
- The use of LDAP allows operation of a JOC Cockpit configuration that contains neither user account data, passwords nor user role assignments.
- This applies to any LDAP compliant product such as Microsoft Active Directory®, OpenLDAP etc.
- LDAP Directory Services can be accessed for authentication and authorization:
- JS7 - OIDC Identity Service
- OIDC offers token based authentication that includes a direct connection between the user and the Identity Provider.
- JOC Cockpit has no access to passwords in this authentication scheme.
- JS7 - Certificate Identity Service
- Client Authentication certificates can act as a replacement for passwords.
- The Identity Service can be used for single-factor authentication and for MFA.
- JS7 - FIDO Identity Service
- Public/private key authentication by use of a secure device eliminates the use of passwords.
- The Identity Service can be used for single-factor authentication and for MFA.
- JS7 - LDAP Identity Service,
- A number of Identity Services can be combined to be optional or required. This allows to authenticate with one Identity Service from a list of available services and it allows to force authentication with all configured Identity Services.
- Users should consider to disable the initial JOC Identity Service when more secure Identity Services are in place.
Credentials Management
Database Credentials
Default Configuration
- Database credentials are specified during installation and are added to the following Hibernate configuration file:
- JOC Cockpit: for access to the reporting database:
JETTY_BASE/resources/joc/hibernate.cfg.xml
- For details see the JS7 - Database article.
- JOC Cockpit: for access to the reporting database:
- 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.
- The installer will store such credentials in its installation response file (Master:
- 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
orsu
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 additionsudo
provides reporting capabilities about (ab)use of commands.
- Your job scripts can switch to a different user context by use of
- 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 Unix environments
- 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
Such credentials apply to use of the YADE file transfer utility that is available from built-in job templates.
Default Configuration
- By default any accounts/passwords that are used for source connections, target connections and proxy connections are stored in clear text.
- Find the YADE - Reference Documentation - Parameter Reference
Secure Configuration
- 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.
----------
Secure Operation
Access Management
- Access Management includes access to JOC Cockpit and to the REST Web Service. This applies to users who access the JOC Cockpit GUI and to scripts and applications that directly access the REST Web Service.
- The JobScheduler Master is assumed not to be accessed by users directly but exclusively via the JOC Cockpit REST Web Service. No default authentication is provided.
- JobScheduler Universal Agents are assumed not to be accessed by users directly but exclusively by a JobScheduler Master. No default authentication is provided.
Roles and Permissions
Default Configuration
- The JOC Cockpit REST Web Service ships with a default configuration in
./joc/resources/joc/shiro.ini
that includes- using local authentication with accounts and passwords stored as hash values,
- using local role assignment,
- the following default values for accounts, passwords and assigned roles (see JOC Cockpit - Authentication and Authorization for more information):
administrator=secret, administrator
application_manager=secret, application_manager
it_operator=secret, it_operator
incident_manager=secret, incident_manager
business_user=secret, business_user
api_user=secret, api_user
root=root, all
Secure Configuration
- It is not recommended to use the default accounts that ship with JOC Cockpit. Default accounts are intended to enable initial login only.
- A fine-grained set of permissions is available that apply to any operation in JOC Cockpit and in the REST Web Service. Such permissions can freely be grouped to roles.
- If possible then LDAP Directory Services should be used to establish role assignment to users based on membership in LDAP security groups.
LDAP Directory Service
Default Configuration
- It is not recommended to use the default configuration with local authentication for the JOC Cockpit REST Web Service.
Secure Configuration
- LDAP Directory Services can be accessed for authentication and authorization:
- users can connect by specifying their domain account.
- optionally membership in security groups can be mapped to JobScheduler roles.
- Using LDAP allows to operate a JOC Cockpit configuration that contains no account data, no passwords and no role assignments to users.
- This applies to any LDAP compliant product such as Microsoft Active Directory, OpenLDAP etc.
Credential Management
Database Credentials
...
- No default values are provided by the installer.
Secure Configuration
- Do not use passwords.
- Users frequently ask if JobScheduler JS7 can encrypt credentials. The answer is "no" as it makes no sense for an Open Source software component to handle a symmetric keyto handle a symmetric key that is in reach of the product that makes use of it. Encrypted passwords correspond to the "key under the mat". They do not provide additional security. However, they perfectly contribute to obfuscation.
- There is one way only how to securely handle passwords: not to use them.
- Use Integrated Security
- This authentication scheme starts from is based on the fact that the account that which a component product is operated for is has already been authenticated and therefore can access a database without specifying user/password credentials.
- This feature is available for a number of DBMS such as:
- Microsoft SQL Server®, see the JS7 - How to connect to an SQL Server with a domain account articledatabase without using passwords article.
- Oracle that includes ® including support for Oracle® Wallet, see see the JS7 - How to make JOC Cockpit connect to an Oracle database without using Wallet® article.
- Encrypt passwords
- For details see JS7 - How to encrypt and decrypt Database Credentials.
Job Credentials
Default Configuration
- The Windows Service for the JobScheduler Master JS7 Controller and Agent runs in the system account.
- The installer allows to specify specification of a different account and to add the addition of credentials for that account. The installer does not store passwords entered during installation.
- By default jobs are executed in the context of the account that the JobScheduler Master or JobScheduler Agent are operated forJS7 Agent is operated with.
Secure Configuration
- Use of Accounts
- It is considered a bad idea to run a
- JS7 Controller 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 for accessing directories and files.
- However,
- users should not grant more permissions to a process than required.
- Use
- 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.
- specific user accounts to run JS7 Controllers and Agents:
- Do not use the system account (Windows) or root account (Unix).
- Create specific service accounts that are limited to the privileges that are required to execute jobs
- 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:
- In Unix environments:
- Job scripts can switch to a different user context by use of
sudo
orsu
commands.sudo
is the preferred option as this is the standard Unix tool
- which allows secure configuration of the
- accounts that are allowed to execute certain commands (
sudoers
file). In additionsudo
provides reporting capabilities about
- Job scripts can switch to a different user context by use of
- the (ab)use of commands.
- Find details from the JS7 - Running Jobs as a different User on Unix article.
- In Windows environments:
- You can use the Windows Credential Manager to safely store the credentials of the user account that a job should be executed for. The
- Agent will then read the credentials and will create a new process to run a job in the target user account's context. This is the preferred solution as it does not store credentials
- in the
- Agent or workflow configuration.
- Find detailed information from
- the JS7 - Running
- In Unix environments:
- 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.
- Jobs as a different User on Windows article.
- For all environments:
- You can run a number of Agents in parallel using different user accounts.
- Use of Credentials
- Do not specify credentials for Windows Service accounts during installation:
- The graphical installer stores such credentials in binary format and forwards them to the Windows Service interface. There is no guarantee that such credentials will be logged by some Windows mechanism.
- Instead, use the Windows Service Panel to manually specify credentials for the service account.
- A credential store can be used for jobs that require credentials, for example to access a database: see the JS7 - Credential Store article for more information
- .
- 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
- JVM jobs, for example JS7 - JITL Database Jobs, JS7 - JITL SSH Jobs etc.
- Use the the feature of JS7 - Encryption and Decryption, for encryption of order variables and job arguments see JS7 - Encryption - Integration with Workflows - Jobs - Orders
- Do not specify credentials for Windows Service accounts during installation:
File Transfer Credentials
Such credentials apply to use of are intended for use with the YADE file transfer utility that , which is available from built-in job templates.
Default Configuration
- By default any accounts/passwords that are used for source connections, target connections and proxy connections are stored in clear text.
- Find See the YADE - Reference Documentation - Parameter Reference for more information.
Secure Configuration
- Use the YADE Credential Store to manage credentials centrally in a store that which is referenced by YADE configuration items, see . See the How to set-up the Credential Store and YADE Parameter Reference - CredentialStoreFragment articles articles for more information.
- Should you use FTP connections then consider to switch switching to use of SFTP.
- SFTP connections can be used with private/public key files , - there is no need to use passwords for such connections.