You must define users to allow using each Systemwalker Operation Manager function. The users who have been registered in the OS can use the Systemwalker Operation Manager functions.
For UNIX version, the users who have been registered in the Extended User Management function can use the Systemwalker Operation Manager functions. When you use the Extended User Management function, define users by seeing "2.5.3 Defining Users (When using Extended User Management Function) [UNIX]".
Also, using a Systemwalker authentication repository makes it possible to centralize user management for Systemwalker products that are associated with the Systemwalker authentication repository. When using a Systemwalker authentication repository, define users by referring to "2.5.4 Defining Users (When Using a Systemwalker Authentication Repository)".
This section describes how to define users when the users who have been registered in the OS use the Systemwalker Operation Manager functions.
Outline
The following outlines how to define users.
Consider the users required for Systemwalker Operation Manager operation you use.
Determine the users by referring to "2.5.2.1 User Control in Systemwalker Operation Manager" and "2.5.2.2 Job Execution Privileges"
Register users.
Register users who can schedule, execute, and operate jobs. Use the OS functions to register those users.
Point
To allow general users to use projects when Systemwalker Operation Manager is operating, the system administrator should set up access rights for general users by referring to "Setting Access Rights for Projects" in the Systemwalker Operation Manager User's Guide.
Note
If a general user logs in to the monitoring server from a multi-server monitoring client, the authentication processing for the monitored server will be performed using the user ID and password for the user that logged in to the monitoring server. Accordingly, to obtain information from the monitored server, register the same user ID and password on the monitored server (as was used to log in to the monitoring server).
In multi-server monitoring, when some monitored servers are running an old version of Operation Manager, there may be some servers where the Extended User Management function or the user management function using a Systemwalker authentication repository is enabled and other servers where these functions are disabled. Even in such cases, servers can be monitored by setting up the same user ID and password (as for the user that logs in to the monitoring server) on each of the monitored servers.
The Systemwalker Operation Manager Web Console performs authentication processing with monitored hosts by using the user ID and password that were used to log in to the Web Console. Accordingly, register users on the monitored hosts with the same user ID and password as the user that logs in to the Web Console.
On the Systemwalker Operation Manager Web Console, when some monitored hosts are running an old version of Operation Manager, there may be some servers where the Extended User Management function or the user management function using a Systemwalker authentication repository is enabled and other servers where these functions are disabled. Even in such cases, hosts can be monitored by setting up the same user ID and password (as for the user that logs in to the Web Console) on each of the monitored hosts.
The following explains how to control users in Systemwalker Operation Manager.
Perform the installation procedure as either a user belonging to the Administrators group (for the Windows) or a user with superuser privileges (for the UNIX).
Only the system administrator (the user belonging to the Administrators group in the Windows system or the superuser in the UNIX system) can register and delete projects.
Only the system administrator (the user belonging to the Administrators group in the Windows system or the superuser in the UNIX system) can change the project's owner.
Only the system administrator (the user belonging to the Administrators group in the Windows system or the superuser in the UNIX system) can register the users who can access to projects. The users must be assigned the following access privileges.
Select the group and user names from the domain or the list registered in the computer.
Select the group and user names from the list registered in the computer.
Refer to "Setting up Access Permissions for Projects" in the Systemwalker Operation Manager User's Guide for details.
The system administrator (the user belonging to the Administrators group in the Windows system or the superuser in the UNIX system) and the users who have been assigned the access privileges to a project can monitor and operate job nets, jobs or groups of the project.
The system administrator, the project owner, or users having the update right and change right of a project can register and change job nets and groups of the project.
Only the user registered in the swadmin group can start on-demand jobs, start job nets having Job Execution Control attributes, and execute Jobscheduler commands. For details, see "2.5.5 Define User Restrictions".
The user who has logged in the Systemwalker Operation Manager server can issue and execute Operation Manager's commands and API which operate on this server.
Note
Notes on Solaris 10 or later
Solaris 10 or later provides the function to authorize job execution of each process separately. If you have limited the job execution in units of processes, even the user having the root privileges may be limited in his/her job execution.
For example, if you specify to suppress the process startup for files to be read when the shell is started, any operation from the shell is suppressed. In such case, the process is suppressed to start up even when a command provided by the Systemwalker Operation Manager is executed. Therefore, no user can execute jobs regardless of his/her command execution privileges.
The following explains the user privileges required to execute jobs in Systemwalker Operation Manager.
User privileges for job execution
The users having the following privileges can execute jobs in Systemwalker Operation Manager.
If the Execute job under the respective job owner's authority option is specified in the Windows system or if UNIX system is used:
Job type | Execution method | Specification of execution user | Privileges |
|---|---|---|---|
Scheduled jobs | Started when job net startup conditions are satisfied or when operated. | Specified | Job execution user |
Scheduled jobs | Started when job net startup conditions are satisfied or when operated. | Not specified | Project owner |
On-demand jobs | Executed by the qsub command (Note 1) | Specified by "-cu" option | The user specified by "-cu" option |
On-demand jobs | Executed by the qsub command (Note 1) | Not specified | The user who has logged in the Operation Manager server |
On-demand jobs | Submitted from Edit/Submit Job Data window | Cannot be specified. | The user who has logged in the Operation Manager server |
Note 1) Also effective if the job submission API is used.
If the Execute job under the respective job owner's authority option is NOT specified in the Windows system:
Job type | Execution method | Specification of execution user | Privileges |
|---|---|---|---|
Scheduled jobs | Started when job net startup conditions are satisfied or when operated. | Privileges for job execution are not changed even if specified. | Logon account of Job Execution Control services |
On-demand jobs | Executed by the qsub command (Note 1) | Privileges for job execution are not changed even if specified. | Logon account of Job Execution Control services |
On-demand jobs | Submitted from Edit/Submit Job Data window | Cannot be specified. | Logon account of Job Execution Control services |
Note 1) Also effective if the job submission API is used.
User privileges required for network jobs and Distributed Execution function
The account of network jobs and Distributed Execution function is inherited from the job submitting server to the destination server as follows.
Jobs are executed by the user having the privileges explained in "User privileges for job execution". Ensure that the following settings are the same on the server that submits the job and the server that receives the job, according to the operating system for the server that receives the job.
[If the server that receives the job is running the Windows version]
Account and password
[If the server that receives the job is running the UNIX version]
Account
Jobs are executed by the logon account of Job Execution Control services.
The account of the executing user or project owner at the job submitting server needs to be registered in the destination server.
If the job submitting server runs in the Windows system, the Job Execution Control service logon account of the job submitting server and the job execution service logon account of the destination server must be the same.
When both of the following conditions are met, the submitted jobs are executed by the user having the system administrator (superuser) privileges.
The job submitting server runs in the UNIX system.
The executing user or project owner at the job submitting server belongs to the Windows Administrators group.
If the job submission server runs in the UNIX system, jobs are executed by the user having the privileges explained in "User privileges for job execution". The account must match between the job submitting server and the destination server.
If the destination server runs in the Windows system, jobs are executed by the Job Execution Control service logon account. The account must match between the job submitting server and the destination server. Also, you must NOT specify the Execute job under the respective job owner's authority option. If it is specified, jobs are terminated abnormally.
Note
If the job submitting server is running in a UNIX system and the destination server is running in a Windows system, do not specify the Execute jobs under the respective job owner's authority option in the Options sheet of the Define Operating Information window. Otherwise, the job will terminate abnormally.
Point
If you specify an execution user to execute a job when using network jobs with the Distributed Execution function, the job will only be executed if the specified user has been registered in both the job submitting server and the execution server.
Network jobs [UNIX]
Job execution server | |||
|---|---|---|---|
User is registered | User is not registered | ||
Job submitting server | User is registered | Y | N |
User is not registered | (Note) | N | |
Y: The job is executed normally. N: The job is NOT executed because an error occurs when the job execution request is processed. Note: The job is NOT executed (as indicated by "N") if the job submitting server or the job execution server is running on V10.1 or earlier.
Network jobs [Windows] with the Distributed Execution function
Job execution server | |||
|---|---|---|---|
User is registered | User is not registered | ||
Job submitting server | User is registered | Y | N |
User is not registered | N | N | |
Y: The job is executed normally. N: The job is NOT executed because an error occurs when the job execution request is processed.
