Access Training Linux/Unix Power Broker Access Custom Schema Database Access Customer Training

1. Access TrainingLinux/Unix Power Broker AccessCustom Schema Database AccessCustomer Training Date: 25-JAN-2005

2. 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

3. Password and Access ManagementOverview 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.

4. Password and Access ManagementReason 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.

5. Password and Access ManagementMethod 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.

6. Password and Access ManagementCustomer 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.

7. Password and Access ManagementCustomer 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

8. Password and Access ManagementCustomer 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.

9. Password and Access ManagementoSDM 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

10. 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 Linux-based 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.

11. 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” • 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. • Login to your target server with the named Power Broker account • Once you are logged into your named account use Password-Manager to view custom database passwords (See next slide).

12. 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.

13. View PasswordsEBSO Only • Login to the target customer server with individual user account • 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. • 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)

14. 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. • SSH to the target server • Login to the target customer server with individual user account • Look for SID $ps –ef | grep smon • 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 • Execute the profile $. ./.profile Now you should be able to login to sqlplus and access TOPs variables.

15. 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. • SSH to the target server • Login to the target customer server with individual user account • Type the command ‘passwd’ from the Unix command line $ passwd Changing password for user <username>. Changing password for <username> (current) UNIX password: • Type current password and click Enter • Type New password and Click Enter New password: • Confirm new password and click Enter Retype new password:

16. 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.

17. FTP Access • There will be no change to the current FTP Access Method

18. Downloading patches pbpullpatch command is no longer supported. Direct ftp to updates.oracle.com can be done • SSH to the target server • Login to the target customer server with individual user account • 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 • Cd to the directory where the patch will be downloaded e.g. $ cd $APPL_TOP/patches • 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>

19. Questions? Questions on this process can be addressed by your oSDM