Unicenter AutoSys Job Management Integration ... - SupportConnect
Unicenter AutoSys Job Management Integration ... - SupportConnect
Unicenter AutoSys Job Management Integration ... - SupportConnect
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong><br />
<strong>Integration</strong> with eTrust Access Control User<br />
Guide<br />
X00000-1E
This documentation and related computer software program (hereinafter referred to as the “Documentation”) is for<br />
the end user’s informational purposes only and is subject to change or withdrawal by Computer Associates<br />
International, Inc. (“CA”) at any time.<br />
This documentation may not be copied, transferred, reproduced, disclosed or duplicated, in whole or in part, without<br />
the prior written consent of CA. This documentation is proprietary information of CA and protected by the copyright<br />
laws of the United States and international treaties.<br />
Notwithstanding the foregoing, licensed users may print a reasonable number of copies of this documentation for<br />
their own internal use, provided that all CA copyright notices and legends are affixed to each reproduced copy. Only<br />
authorized employees, consultants, or agents of the user who are bound by the confidentiality provisions of the<br />
license for the software are permitted to have access to such copies.<br />
This right to print copies is limited to the period during which the license for the product remains in full force and<br />
effect. Should the license terminate for any reason, it shall be the user’s responsibility to return to CA the reproduced<br />
copies or to certify to CA that same have been destroyed.<br />
To the extent permitted by applicable law, CA provides this documentation “as is” without warranty of any kind,<br />
including without limitation, any implied warranties of merchantability, fitness for a particular purpose or<br />
noninfringement. In no event will CA be liable to the end user or any third party for any loss or damage, direct or<br />
indirect, from the use of this documentation, including without limitation, lost profits, business interruption,<br />
goodwill, or lost data, even if CA is expressly advised of such loss or damage.<br />
The use of any product referenced in this documentation and this documentation is governed by the end user’s<br />
applicable license agreement.<br />
The manufacturer of this documentation is Computer Associates International, Inc.<br />
Provided with “Restricted Rights” as set forth in 48 C.F.R. Section 12.212, 48 C.F.R. Sections 52.227-19(c)(1) and (2) or<br />
DFARS Section 252.227-7013(c)(1)(ii) or applicable successor provisions.<br />
© 2004 Computer Associates International, Inc.<br />
All trademarks, trade names, service marks, and logos referenced herein belong to their respective companies.
Contents<br />
Chapter 1: Working with eTrust Access Control and <strong>Unicenter</strong><br />
<strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong><br />
Architecture...................................................................................................................................................... 1-1<br />
Integrating eTrust Access Control Model with <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>......................... 1-2<br />
Chapter 2: Real World Situations<br />
Scenario 1: Defining Naming Standards ........................................................................................................ 2-1<br />
Defining the eTrust Rule........................................................................................................................... 2-2<br />
Administrator Role ................................................................................................................................... 2-2<br />
Scenario 2: Securing Machines ........................................................................................................................ 2-4<br />
Navigating the Policy Manager................................................................................................................ 2-4<br />
Scenario 3: Stopping the event_demon........................................................................................................... 2-7<br />
Scenario 4: <strong>Job</strong> Ownership............................................................................................................................... 2-8<br />
Conclusion........................................................................................................................................................ 2-9<br />
Appendix A: <strong>Job</strong> Naming Conventions<br />
Naming Conventions...................................................................................................................................... A-1<br />
Appendix B: Troubleshooting<br />
General Issues and Resolutions.......................................................................................................................B-1<br />
HP Issue............................................................................................................................................................B-3<br />
Web Interface Problem ....................................................................................................................................B-3<br />
Contents<br />
iii
Chapter<br />
1<br />
Working with eTrust Access<br />
Control and <strong>Unicenter</strong> <strong>AutoSys</strong><br />
<strong>Job</strong> <strong>Management</strong><br />
With the arrival of <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> 4.5, an external security<br />
methodology is now provided through eTrust Access Control (eTrust AC). By<br />
utilizing eTrust AC, job scheduling administrators are able to provide a more<br />
granular level of control towards defining job attributes and administer<br />
application level control to ensure security and enforce standards. The purpose<br />
of this guide is to describe the integration between eTrust AC and <strong>Unicenter</strong><br />
<strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> as well as provide examples you can possibly find in<br />
the real world. This document can be used in providing a quick start in<br />
implementing an <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> environment secured<br />
through eTrust AC.<br />
Architecture<br />
eTrust AC as a standalone solution provides security to servers through a<br />
client/server subscription model. Within an enterprise, an administrator installs<br />
an eTrust server master database, otherwise referred to as a Policy Model<br />
Database (PMDB). This eTrust server acts as the parent server for which eTrust<br />
clients could subscribe to receive policy rules. eTrust clients store policy rules in<br />
a local database, known as a seosdb. After an eTrust client is subscribed to an<br />
eTrust Server, the PMDB pushes out all access control rules to the eTrust client<br />
database (seosdb). The benefit of having such an architecture is that the security<br />
administrator only needs to update the PMDB, and after doing so, the newly<br />
created policy will be pushed out to all subscribed clients.<br />
Working with eTrust Access Control and <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> 1–1
Architecture<br />
Integrating eTrust Access Control Model with <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong><br />
With policy rule databases now implemented throughout your environment, you<br />
want to be able to tie these rules in with <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong><br />
scheduling clients to secure the more granular aspects of job scheduling,<br />
including job definitions, web interface access, listing jobs, and controlling the<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> environment (e.g. stopping the event<br />
processor).<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> references the eTrust AC before allowing<br />
any changes to be submitted. By checking first with the eTrust client database on<br />
your <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> client machines, <strong>Unicenter</strong> <strong>AutoSys</strong><br />
<strong>Job</strong> <strong>Management</strong> can allow or deny changes to the <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong> environment. To gain a fuller understanding, let us take a look at<br />
the following diagram and follow the <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> logic<br />
for an eTrust AC environment. For more detailed information on this integration,<br />
please refer to the <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> User Guide.<br />
1–2 <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Integration</strong> with eTrust Access Control User Guide
Architecture<br />
1. Create policy rules in the PMDB. These rules will be pushed out to the<br />
eTrust client machines.<br />
2. When a command is issued from <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong><br />
(e.g. sendevent, jil, autorep), <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> queries<br />
the eTrust client database to determine if there are any access<br />
restrictions.<br />
3. The eTrust database returns an allow or deny message based on the<br />
actions you are trying to take with <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>.<br />
4. If access is granted, <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> then proceeds<br />
to access the database to change or access the information you require. If<br />
you are denied access, a message appears indicating the resource<br />
requirements you failed to fulfill.<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> Defined Classes in eTrust Access Control<br />
When installed with <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>, eTrust AC contains<br />
several user-defined classes which allow you to secure the <strong>Unicenter</strong> <strong>AutoSys</strong><br />
<strong>Job</strong> <strong>Management</strong> environment. These classes are<br />
• as-job<br />
• as-calendar<br />
• as-owner<br />
• as-gvar<br />
• as-machine<br />
• as-control<br />
• as-view<br />
Working with eTrust Access Control and <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> 1–3
Architecture<br />
• as-list.<br />
For a description of each of these classes, please refer to the <strong>Unicenter</strong> <strong>Unicenter</strong><br />
<strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Job</strong> <strong>Management</strong> User Guide.<br />
By now, you should have a general overview of the integration between<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> and eTrust AC. The next section goes into<br />
actual implementation of rules with common scenarios a <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong> administrator may run into and the steps they can take to ensure<br />
that security is enforced.<br />
1–4 <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Integration</strong> with eTrust Access Control User Guide
Chapter<br />
2<br />
Real World Situations<br />
Your company has recently moved to <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> 4.5<br />
and needs additional security for job definitions. You have recently consolidated<br />
your disparate <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> instances, so they will need<br />
to maintain security between these jobs. By using the as-classes in eTrust,<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> 4.5 can help your company in securing your<br />
environment while allowing it to expand.<br />
The job scheduling group for your company consists of four groups with distinct<br />
roles:<br />
• Administrators - define the rules<br />
• Developers - create the jobs and define them to the <strong>Unicenter</strong> <strong>AutoSys</strong><br />
<strong>Job</strong> <strong>Management</strong> database<br />
• Scheduling operators - monitor their particular job flows and take action<br />
on failed jobs by resubmitting them<br />
• Casual users<br />
Scenario 1: Defining Naming Standards<br />
Your company has attempted to enforce naming conventions for jobs so that they<br />
can be easily identified by the scheduling operators. However, at times, these<br />
naming conventions are not adhered to by some developers who forget the<br />
syntax of this nomenclature. Your scheduling administrator does not want any<br />
jobs to be created within the database that do not follow this naming standard.<br />
eTrust AC functions optimally when naming conventions are followed. It would<br />
be much easier to define rules when job names, global variables, and calendars<br />
follow a standard. As a job name standard, CA recommends that you define your<br />
job names with something similar to the following:<br />
applicationIdentifier_boxname_jobname<br />
Real World Situations 2–1
Scenario 1: Defining Naming Standards<br />
Defining the eTrust Rule<br />
Let’s say, for example, following this schema, the <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong> administrator in your company wants Developer1 to be able to<br />
create and edit jobs for the finance application and Developer2 to create and edit<br />
jobs for the payroll application and all of the jobs must follow the naming<br />
convention. The naming conventions for these jobs are:<br />
FIN_*<br />
PAY_*<br />
To create and edit rules within eTrust, you can use the GUI-based Policy<br />
Manager provided on Windows, or the selang command prompt utility provided<br />
on both UNIX and Windows platform (under the eTrustAccessControl\bin<br />
directory). This guide will provide information from a command line<br />
perspective.<br />
1. At the command prompt, type selang to run the selang utility.<br />
2. When the selang command prompt appears it is connected to the local<br />
seosdb. To connect to the PMDB, enter<br />
Example:<br />
hosts autosys@hostname<br />
where the localhost is also the eTrust server machine.<br />
Target host: localhost<br />
eTrust selang v5.2.1173 - eTrust command line interpreter<br />
Copyright 2003 Computer Associates International, Inc.<br />
eTrust>hosts autosys@localhost<br />
(autosys@localhost)<br />
Successfully connected<br />
INFO: Target host's version is 5.2.1173<br />
OS info: Windows NT Version:5.1, Service Pack 1<br />
30 Jan 2004 15:31:21 Eastern Standard Time<br />
eTrust><br />
Administrator Role<br />
Now the administrator needs to do two things:<br />
• Ensure that jobs being entered either begin with “FIN_” and “PAY_”.<br />
• Restrict Developer1 to only create the FIN_ jobs and Developer2 to create<br />
the PAY_ jobs.<br />
2–2 <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Integration</strong> with eTrust Access Control User Guide
Scenario 1: Defining Naming Standards<br />
Change the default permissions for job creation for all users<br />
We will focus with the as-job class. Currently this class allows for default<br />
permissions for all users to create, edit, delete, execute, read, and write for all<br />
jobs.<br />
eTrust> showres as-job _default<br />
(autosys@localhost)<br />
Data for as-job '_default'<br />
-----------------------------------------------------------<br />
Defaccess<br />
: R, W, X, Cre, Del<br />
Note: The syntax of our selang command consists generally of three parts:<br />
. It is helpful to remember this syntax when<br />
referring to resources.<br />
Now you need to change the default access for all jobs created in <strong>Unicenter</strong><br />
<strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> so that no one can write to the database unless<br />
authorized. You can do this through the editres command.<br />
eTrust> editres as-job _default defaccess(none)<br />
(autosys@localhost)<br />
Successfully updated as-job _default<br />
You can see the results of this change by the same showres command.<br />
eTrust> showres as-job _default<br />
(autosys@localhost)<br />
Data for as-job '_default'<br />
-----------------------------------------------------------<br />
Defaccess : None<br />
Update time : 30-Jan-2004 15:42<br />
Updated by : Administrator<br />
Create a new resource for FIN_* jobs and allow only creation and editing of these jobs by<br />
Developer1.<br />
Now that you have essentially denied access for creating and editing of jobs for<br />
all users, you can start defining new eTrust resources based on the job names you<br />
want to allow to be created as well as the users that will create and edit them.<br />
Let’s start with the FIN_* jobs.<br />
Real World Situations 2–3
Scenario 2: Securing Machines<br />
To create a resource, issue the newres command.<br />
eTrust> newres as-job FIN_*.ACE<br />
(autosys@localhost)<br />
Successfully created as-job FIN_*.ACE<br />
Each resource has standard syntax of<br />
name.<br />
The instance extension allows you to have multiple <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong> clients for different instances on the same machine and reference<br />
the same eTrust client database. In this case, you only specify the rule for<br />
instance ACE. If you wanted the rule to span all instances, you could just omit<br />
the instance identifier, e.g. newres as-job FIN_*.<br />
Now you want to authorize Developer1 to create and edit the jobs. Assuming<br />
that Developer1 is in the eTrust database, you can use the authorize command.<br />
eTrust> authorize as-job FIN_*.ACE uid(developer1) access(create, write)<br />
(autosys@localhost)<br />
Successfully added developer1 to FIN_*.ACE's ACL<br />
You have just ensured that the only user allowed to create jobs is Developer1.<br />
More importantly, Developer1 is only allowed to create and edit jobs that start<br />
with “FIN_”.<br />
Scenario 2: Securing Machines<br />
Your company has a wide range of machines within its environment, however,<br />
you want to differentiate between your production instance (PRD) and your<br />
development instance (DEV) such that PRD can only schedule jobs on<br />
production machines specified by PRD_* and DEV can only schedule to<br />
development machines specified by DEV_*. By doing so, you can ensure that a<br />
developer who is creating a job flow does not mistakenly run on a production<br />
machine, or that jobs that should run on production do not run on a<br />
development machine. In addition, it will limit the machines that jobs can be<br />
scheduled to so there can be no rogue remote agent machines.<br />
Let’s approach this from a user interface perspective on the Windows platform.<br />
Navigating the Policy Manager<br />
To launch the eTrust Policy manager, in the Start Menu, select Programs, CA,<br />
eTrust, AC, Policy Manager. As described in scenario 1, you will need to connect<br />
to your PMDB by clicking and selecting the PMDB to connect to.<br />
2–4 <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Integration</strong> with eTrust Access Control User Guide
Scenario 2: Securing Machines<br />
Once you have connected, you should be able to view the User Defined Resource<br />
classes for use with <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>. Click in the left<br />
hand pane.<br />
Similar to the selang command line utility, you should see the <strong>Unicenter</strong> <strong>AutoSys</strong><br />
<strong>Job</strong> <strong>Management</strong> user defined classes as specified.<br />
Note: In this scenario, the class that we will focus on will be as-machine. Select<br />
the default policy for the as-machine class and click Set Default Access.<br />
Referring back to the scenario, you want to be able to secure machines <strong>Unicenter</strong><br />
<strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> jobs can be scheduled to.<br />
Real World Situations 2–5
Scenario 2: Securing Machines<br />
Prevent users from being able to define jobs that can be scheduled to any machine<br />
1. Set the default access to None. As a result of this, no user will be able to<br />
create a job with any machine name.<br />
Allow users in the DEV group to only create jobs with machines that start with DEV_*.<br />
1. Right-click in the right hand pane under the default policy and select<br />
New for a new resource.<br />
2. Enter the resource Name DEV_*.DEV.<br />
2–6 <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Integration</strong> with eTrust Access Control User Guide
Scenario 3: Stopping the event_demon<br />
3. Click Authorize. Select a new group to have full permission on machines<br />
starting with DEV_* in the DEV instance. Click OK.<br />
Allow users in the PRD group to only create jobs with machines that start with PRD_*.<br />
1. Right-click in the right hand pane under the default policy and select<br />
New for a new resource.<br />
2. Enter the resource Name PRD_*.PRD.<br />
3. Click Authorize. Select a new group to have full permission on machines<br />
starting with PRD_* in the PRD instance. Click OK.<br />
Scenario 3: Stopping the event_demon<br />
Your company needs to control who can stop the event_demon. This was once<br />
controlled by the <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> exec super user. However,<br />
now that an external security provider (eTrust) has been integrated with<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>, once eTrust is enabled, the <strong>Unicenter</strong><br />
<strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> super user concept is overridden. You can control<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> administration via the as-control class. The<br />
next steps will explain how you will authorize certain users to be able to stop the<br />
event_demon while revoking these rights for others.<br />
By default, after eTrust AC has been turned on, the default permission to stop the<br />
event_demon is execute for all users. This will be one of the first items you will<br />
need to address before deciding to enable eTrust AC.<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> administrative access controls are stored in<br />
the as-control class. When querying the STOP_DEMON* resource through<br />
selang, we can see the default access permissions for this resource.<br />
eTrust> sr as-control STOP_DEMON*<br />
Real World Situations 2–7
Scenario 4: <strong>Job</strong> Ownership<br />
(autosys@localhost)<br />
Data for as-control 'STOP_DEMON*'<br />
-----------------------------------------------------------<br />
Defaccess : X<br />
Audit mode : Failure<br />
Owner : Administrator (USER)<br />
Create time : 29-Oct-2003 11:11<br />
Update time : 29-Oct-2003 11:11<br />
Updated by : Administrator<br />
Comment : Controls who can stop the <strong>Unicenter</strong> <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong> JM Event Processor<br />
Once again, you need to disable the default access permissions and authorize a<br />
select group of users to be able to stop the event_demon. As a reinforcement of<br />
the walkthroughs given above, you will need to perform the following steps to<br />
secure the STOP_DEMON* resource.<br />
1. Disable the default access to the resource.<br />
editres as-control STOP_DEMON* owner(nobody) defaccess(none)<br />
2. Authorize the specific user (root) to be able to issue a STOP_DEMON.<br />
auth as-control STOP_DEMON* uid(root) access(X)<br />
Now, only the root user should be able to issue the STOP_DEMON command<br />
and have it succeed. All other users will not be allowed to stop the event<br />
processor.<br />
Scenario 4: <strong>Job</strong> Ownership<br />
Your company wants to further secure their environment by restricting user<br />
access to run jobs as the root user. In order to do this, you need to create a policy<br />
where a job cannot be owned by the root user, thus disabling any possibility of a<br />
job being defined that is owned by the root user. By doing this, you will be better<br />
able to audit what particular users do without having to worry about people<br />
running jobs under the root user.<br />
The particular class you are interested in is as-owner. This class controls who can<br />
own job (based on the owner attribute of a job definition). Here you will deny all<br />
users the ability to create a job owned by the root user. As in the above examples,<br />
you will check the current default permissions on the “_default” resource under<br />
the as-owner class.<br />
1. Check the default permissions under the as-owner class through selang.<br />
2–8 <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Integration</strong> with eTrust Access Control User Guide
Conclusion<br />
eTrust> showres as-owner _default<br />
(localhost)<br />
Data for as-owner '_default'<br />
-----------------------------------------------------------<br />
Defaccess<br />
: X<br />
Update time : 25-Nov-2003 11:24<br />
Updated by<br />
: root<br />
As you can see, all users are able to be defined as the owner, and the<br />
owner will be able to run this job. Let’s create a new specific resource<br />
which will deny the root user from owning a job, thereby, controlling<br />
root from ever executing a process on the remote agent machine.<br />
2. Define a new resource for the root user under the as-owner class, and<br />
deny this user execute permissions.<br />
eTrust> newres as-owner root* owner(nobody) defaccess(none)<br />
(localhost)<br />
Successfully created as-owner root*<br />
Conclusion<br />
Hopefully, by now you should have a basic understanding to how eTrust AC<br />
integrates with <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>. As you can see, there are<br />
many additional <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> user-defined classes to<br />
eTrust AC which will help you in securing additional items like calendars and<br />
global variables. Security does not only encompass access rights to these<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> elements, you can also use it to enforce<br />
naming conventions for jobs as well as limit how and where a job stream will<br />
flow.<br />
This quick start guide is meant to be used in conjunction with the security<br />
module in the current <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> document.<br />
Real World Situations 2–9
Appendix<br />
A<br />
<strong>Job</strong> Naming Conventions<br />
Naming Conventions<br />
All names start with a three letter application identifier. Underscore will be used to<br />
delimit name levels. If the job is in a box, the box name follows the application name. The<br />
job name comes after the box name. The “fw” extension must be added if the job is a file<br />
watcher job. Example job name: TRD_REPORTS_EOD223.<br />
The name TRD_REPORTS_EOD223 indicates that this job is from the TRD application, it<br />
is in the box REPORTS, and its name is EOD223.<br />
A file watcher job that is not in a box could be named like this: TRD_STRTAPP_FW. This<br />
job is also from the TRD application, it is not in a box, its name is STRTAPP and it is a file<br />
watcher job.<br />
<strong>Job</strong> Naming Conventions 1–1
Appendix<br />
B Troubleshooting<br />
The following section outlines some of the most common issues that occur while<br />
working with eTrust Access Control and <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong><br />
together.<br />
General Issues and Resolutions<br />
Installation<br />
If you install eTrust AC, always make sure the client uses absolute the root or<br />
administrator account. Any form of “su” to root on UNIX or using a user that<br />
belongs to Administrator group will cause problems in eTrust. It is really hard to<br />
pinpoint exactly what problem it will cause because the symptom varies. This<br />
should be the very first thing support needs to verify on any eTrust related issue.<br />
Error: “You are not authorized to do…” in <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>_secure. You are<br />
completely locked out of <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>_secure.<br />
Cause<br />
The security word in the eTrust PMDB is out of sync with the one in <strong>Unicenter</strong><br />
<strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> DB.<br />
Resolution<br />
On <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> side, delete the security word from the<br />
keymaster table.<br />
Command on the Autosys DB server:<br />
Delete from keymaster where keymaster.hostname = ‘SecurityWord’<br />
Command on the eTrust server :<br />
rr as-control _ON.<br />
rr as-control _OFF.<br />
After that, reset the security word in <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>_secure<br />
Troubleshooting B–1
General Issues and Resolutions<br />
Remarks<br />
This error is caused by a synchronization error between the eTrust client and<br />
PMDB server. This can be manifested by viewing the as-control class in both<br />
client and server eTrust databases and checking to see if they are both there. If<br />
not, then instructions to resubscribe the client to the server should be provided<br />
before manipulating eTrust content that state “Please do not modify this<br />
content”. This brings up the issue of severity levels, solutions that you should try<br />
first and then ultimately to resolve an issue. We’ll run into this especially when<br />
clients have separate administrators for say job scheduling and security. If the<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> admin knows that by deleting and running<br />
things here and there from the <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong><br />
database/command line, they can essentially override any security that the<br />
security administrators are trying to enforce.<br />
Error: The Windows machine is locked down from login after installation of Web Interface<br />
Cause and Resolution<br />
For <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> and WI, if you choose to install eTrust,<br />
absolute root/administrator user account must be used. If you belong to the<br />
Administrator group on Windows or “su” and “sudo” to root on UNIX this error<br />
will occur.<br />
Error: "<strong>Job</strong> Access Denied.<br />
<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>/eTrust subscriber authentication error:<br />
the phACEE parameter is a null pointer<br />
Class: Resource: User: Access:"<br />
Cause<br />
The lookaside DB in eTrust in eTrust is not up-to-date.<br />
Resolution<br />
Execute ./sebuildla –a to rebuild the lookaside DB. Then recycle eTrust.<br />
Remarks<br />
eTrust support team suggests that you run “sebuildla –a” regularly to avoid this<br />
problem from happening.<br />
B–2 <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Integration</strong> with eTrust Access Control User Guide
HP Issue<br />
HP Issue<br />
Core dump after entering multiple EDIT/EXEC superusers. Fix T346100 does not<br />
fix the problem completely. The core dump is gone but we still see the following<br />
problem.<br />
After entering multiple EDIT/EXEC superusers in the <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong>_secure, superuser got locked out of the <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong>_secure option 1-4. You can still see option 5-8.<br />
Workaround<br />
1. Logon to the Oracle DB from weather<br />
#zql –U<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> –P<strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong><br />
<strong>Management</strong> –Sautodev<br />
2. Reset 2 values<br />
zql>update alamode set int_val=0 where type=’EVT’<br />
zql>/<br />
zql> update alamode set int_val=0 where type=’JOB’<br />
zql>/<br />
3. CONTROL-D key to get out of zql<br />
4. Restart <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong>_secure and the problem<br />
should be resolved.<br />
Web Interface Problem<br />
Issue<br />
Special characters (i.e. “!”) in the user ID prevent Web Interface from installing.<br />
Cause<br />
This is an InstallShield problem. InstallShield unpacks the JVM to %TEMP%, and<br />
starts the install wizard with that java. For some reason the ‘!’ in the path was<br />
preventing java from loading some properties files which are required for xalan<br />
so we got an exception doing an xsl transform.<br />
Troubleshooting B–3
Web Interface Problem<br />
Workaround<br />
The problem with the '!' seems not to be a bug in ISMP, but more a limitation of<br />
the xml parser. The '!' character acts as a comment character and so having that<br />
character in the classpath for java causes problems for the parser. The reason the<br />
'!' is part of the path to the jvm is because when you use a bundled jvm, the<br />
bundle is extracted to a temp location which is a subfolder of your home<br />
directory. Because of the '!' in your user ID, the path has the '!' as well. The work<br />
around to this is to specify the -is:tempdir switch to use a different temp location.<br />
This will allow you to specify a directory which does NOT have the '!' in the<br />
path.<br />
For example<br />
setupwin32.exe -is:tempdir C:\temp<br />
Will extract the bundled jvm to the C:\temp directory, and the install will be<br />
successful.<br />
B–4 <strong>Unicenter</strong> <strong>AutoSys</strong> <strong>Job</strong> <strong>Management</strong> <strong>Integration</strong> with eTrust Access Control User Guide