Transcript Customer Kickoff Presentation

Access Training
Linux/Unix Power Broker Access
Custom Schema Database Access
Customer Training
Date: 25-JAN-2005
Training Agenda
 Password and Access Management
–
–
–
–
–
Overview
Reason for Change
Method for Change
Customer Role and Responsibility
oSDM Role and Responsibility
 Linux/Unix Operating System Access
–
–
–
Power Broker Overview
Named Accounts
EBSO and OTO @Oracle Login Steps
 Viewing Custom Schema Passwords
–
EBSO Only
Password and Access Management
Overview
Oracle On Demand adheres to the Password Policy and
password management guidelines documented in the SAS70 II
for Logical Database security.
All On Demand customers’ passwords will be changed by the
lifecycle engineering team initially and during the Periodic
Maintenance schedule as a regular process.
The migration schedule for all customers will begin in April 2004
and will require that customers verify through testing that any
CEMLIS (customizations) are not effected by the password
changes.
Password and Access Management
Reason For Change
Logical Security describes how On Demand will ensure database
and applications security with relation to login procedures and
password management.
This password migration is mandated for all customers. The
SAS70 II for Oracle On Demand allows companies to meet their
internal compliance standards. The use of these security
measures are for the benefit of our customers.
Named accounts will be used to access the OS and from that
access point users will be able to view the database and
application accounts to which they have permission.
Password and Access Management
Method For Change
The change to passwords will be executed using a tool called
Password Manager which will generate passwords that adhere
to the Password Policy. Passwords and configuration files will be
update in an automated fashion. A full health check of the
instance will be completed and the instance will be turned over to
the customer to test the CEMLI code. Once verified the change
will be promoted to Production following the Change
Management Process.
Named Linux/Unix accounts will be needed by any customer
who requires access to the custom database passwords. In
addition, any customer or implementer who requires access will
also need an OS level account to view permitted database
passwords.
Password and Access Management
Customer Responsibility
On Demand will be changing standard database and
application system administrator passwords as well
as the custom schema database passwords.
On Demand will look to customers to be partners in
the initial change to the passwords.
Password and Access Management
Customer Responsibility(Cont)
Customer Role and Responsibility:
 Prior to the scheduled migration date
–
–
–
–
–
Provide a list of users who require OS account access
Identify any CEMLI exceptions that are in place
Identify any Access exceptions that are in place
Identify all CEMLIs that could be effected
Create a plan to address CEMLI code that is effected
 Post Migration
–
–
–
–
Test all CEMLIs for verification
Submit Tar with instructions to correct all CEMLIs that were
improperly coded
Customer is responsible to obtain resources to fix CEMLI code
that is improperly coded
On Demand can assist in identifying the issues but cannot supply
the solution if it is determined to be a coding issue
Password and Access Management
Customer Responsibility(Cont)
CEMLI Coding Standards and Best Practices
 When implementing CEMLI code customers and implementers
were to adhere to the guidelines for On Demand in the EBSO
Reference Guide, Chapters 7- 11.
 A summary of the coding practices that are relevant in this case
is that the CEMLI be owned by the custom schema (bolinf) and
that passwords not be hard-coded into CEMLI objects.
Password and Access Management
oSDM Role
Your oSDM will guide you through this migration process
 Instruct customers and implementers on how to acquire a named
OS level account for all non-oracle employees who need access
to the rac_accnt or bolinf database accounts.
 Instruct Oracle employee implementers how to acquire a named
OS level account
 Provide all documentation related to this process
 Communicate with customer regarding questions and completion
of this process and
 Create a SR for the customer one week prior to scheduled
migration date
 Follow-up with customer regarding test verification and
permission to promote to production
Power Broker
Overview
 Symark PowerBroker® provides UNIX and Linux security and
accountability by enabling system administrators to delegate
administrative privileges and authorization without disclosing the
root password and to grant selective access to UNIX and Linuxbased corporate resources.
 Power Broker Policies have been created that control the level of
access that any named user is provided. Named accounts are
then associated with users.
Example: "customer" policy provides view only access to
instances and the ability to view custom database passwords.
 For more information on Symark and Power Broker see the Key
Features at http://www.symark.com/powerbroker.htm.
Power Broker
Login
•
Customers will have named accounts to access the servers
and view custom database passwords.
•
Each account will be attached to the policy called “customer”
1. SSH to your target server
Note: If you don’t have SSH software, you may download Putty
[http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html]
PuTTY is a free implementation of Telnet and SSH for Win32 and
Unix platforms.
2. Login to your target server with the named Power Broker
account
3. Once you are logged into your named account use
Password-Manager to view custom database passwords
(See next slide).
Power Broker
Login as applmgr
•
Only IMPDBA policy can switch to the applmgr account of
non-production instances by using the following command:
/usr/local/bin/pbrun <policy> -u [target user]
[target user]: ap<sid>
e.g. /usr/local/bin/pbrun impdba -u aptesti
•
From ap<sid> account, impdba users can perform tasks like
applying patches or restarting Middle Tier services.
•
Impanalyst, impoto and customer policies don’t have any
target users to switch to.
Note: There’s an exception for certain customers for the impoto policy. Check Final
Access List.xls for details on the customers and users affected. Users of this
exception can run “pbrun impoto -x <ia_SID>” to switch to the iAS username.
View Passwords
EBSO Only
1. Login to the target customer server with individual user account
2. Run the following command to view all passwords
/usr/local/bin/pbrun <policy> password-manager <instance>
Example: /usr/local/bin/pbrun customer password-manager ttesti
This command will give you all the passwords for TTESTI instance
visible to the user. This option does not work with impdba policy.
Users of impdba need to provide <type> parameter.
3. Run the following command to view only one password
/usr/local/bin/pbrun <policy> password-manager <instance> <type>
Example: /usr/local/bin/pbrun impdba password-manager ttesti bolinf
This command will give you the ‘bolinf’ password for TTESTI instance
Important Note: pbrun command is case sensitive and all parameters
must be provided in lower case (including the instance name)
How to set the Environment
Users of impdba policy will have the environment set up once they switch
to the target user. Impanalyst and customer policies however don’t
have target users. Following steps can be executed to enable
SQL*Plus access and cd to the TOP directories.
1.
SSH to the target server
2.
Login to the target customer server with individual user account
3.
Look for SID
$ps –ef | grep smon
4.
Cd to applmgr HOME directory
$cd /<sid>/applmgr
If this can’t be found (e.g. for a database server) cd to oracle HOME directory:
$cd /<sid>/oracle
5.
Execute the profile
$. ./.profile
Now you should be able to login to sqlplus and access TOPs variables.
How Power Broker users can change their
passwords
If needed, power broker users can change their named account’s
password from Unix. For example, customers and implementers can
follow these steps to change their password after SDM has provided
login details for the first time.
1.
SSH to the target server
2.
Login to the target customer server with individual user account
3.
Type the command ‘passwd’ from the Unix command line
$ passwd
Changing password for user <username>.
Changing password for <username>
(current) UNIX password:
4.
Type current password and click Enter
5.
Type New password and Click Enter
New password:
6.
Confirm new password and click Enter
Retype new password:
SQL*Plus Access
 Customers will have SQL*Plus access to ‘bolinf’ and ‘rac_accnt’
users for all instances
 Current passwords can be viewed from Power Broker
 SQL*Plus can be achieved from the SQL*Plus windows client.
FTP Access
 There will be no change to the current FTP
Access Method
Downloading patches
pbpullpatch command is no longer supported. Direct ftp to
updates.oracle.com can be done
1.
SSH to the target server
2.
Login to the target customer server with individual user account
3.
Run the pbrun command to "su" to the applmgr user if applicable
/usr/local/bin/pbrun <policy> -u ap<sid>
e.g. /usr/local/bin/pbrun impdba –u appmpti
4.
Cd to the directory where the patch will be downloaded
e.g. $ cd $APPL_TOP/patches
5.
ftp updates.oracle.com
•
login with your personal metalink account (i.e. <uid_us>)
•
cd <patch number>
•
bin
•
ls (to get the list of files on the patch directory)
•
get <patch number specific per o/s>
Questions?
Questions on this process can be
addressed by your oSDM