Category Archives: Security

Oracle Software Appliances and Bash Shellshock

Late September a vulnerability in the bash Shell has been published. The vulnerability also known as shellshock, was classified as extremely critical. Anyway, in the meantime security patch has been released for the different operating systems and bash implementations. A bugfix is also available for Oracle Enterprise Linux, which is used as operating system of the two Oracle software appliances Oracle Audit Vault and Database Firewall and Oracle Key Vault. Oracle has published two My Oracle Support Notes which describe how the patch must be installed on the appliance software. The installation is quite straightforward. Get the patch from the Oracle’s public yum repository and install it on the appliance. 🙂 But be aware, that the two appliance are still runing Oracle Enterprise Linux 5.

Steps to copy, install and verify the bash shell bugfix:

[support@melete ~]$ su -
Password:

[root@melete ~]# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
vulnerable
this is a test

[root@melete ~]# rpm -Uvh /tmp/bash-3.2-33.el5_11.4.x86_64.rpm
warning: /tmp/bash-3.2-33.el5_11.4.x86_64.rpm: Header V3 DSA signature: NOKEY, key ID 1e5e0159
Preparing...                ########################################### [100%]
   1:bash                   ########################################### [100%]

[root@melete ~]# rpm -qa | grep -i bash
bash-3.2-33.el5_11.4

[root@melete ~]# env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
this is a test

References

Some links related to the bash shellshock vulnerability.

Release of Audit Vault and Database Firewall 12.1.2 Bundle Patch 2

End of last week, Oracle has released the second Bundle Patch for Audit Vault and Database Firewall 12.1.2. I’ve missed the release due to public holiday here in Switzerland. 🙂 The patch can be downloaded as usual on Oracle Metalink as Patchset 19190265 for existing installations or on Oracle eDelivery as full installation image for new installations. The installation image is split in two parts which need to be merged before use. A short description on how to merge the image can be found on my blog post about Audit Vault and Database Firewall 12.1.2.

According the readme, the Release 12.1.2 BP2 contains the July 2014 PSU 11.2.0.3.11 for the database as well several bug fix for the base platform. These include security and stability fixes to Java and the underlying Linux operating system. This is more or less similar to thelast bundle patch. What’s new, are the bug fix for the following bugs:

Bug Number Description
18724624 WITH EXCESSIVE VALUE FOR RMEM_MAX, TRAFFIC MONITORING IS SILENTLY DISABLED
18161187 INTEGRATE INTERFACE MASTERS NEW DRIVERS INTO THE PRODUCT
18940816 AVDF SERVER FAILS TO INSTALL ON HP DL380 GEN8 WITH CCISS!C0D0 ERROR
18823169 AFTER UPGRADE, THE DBFW CAN NOT COMMUCIATE WITH THE AVDF SERVER
18112713 ERRORS RELATING TO ILM AND DISK METRICS SEEN IN ALERT LOGS
18442791 NFS ARCHIVE JOB FAILS
18459675 SUPPORT FOR NVARCHAR DATA TYPE IN TABLE EZCOLLECTOR

In particular, I am interested in bug 18940816. I’ve discussed this issues in my post about AVDF installation fails on HP server with Smart Array Disk Controller. To verify if this issue is successfully fixed, I’ll have to reinstall one of the HP BL465c Blades.

References

Some links related to the Audit Vault and Database Firewall:

Secure External Password Store for RMAN

The draft version of this blog post is lying around for some time in my inbox. I’ve never found time to finish it. But due to a task in a project it’s about time to finish my notes on Oracle’s Secure External Password Store. Ludovico, a work colleague has already written a blog post about Removing passwords from Oracle scripts earlier this year. I would like to complement the topic and discuss a few points specifically in connection with RMAN Backup’s and a central RMAN catalog. The goal remains the same, getting rid of passwords with a minimal operational effort. The key element is the Oracle Wallet and the Secure External Password Store functionality.

Oracle Wallet

The Oracle Wallet is a PKCS#12 container used to store different kinds authentication and encryption keys. The wallet can thereby be used to store one or multiple of the following information:

  • Credentials for PKI authentication to the Oracle Database
  • Certificates for network encryption (SSL/TLS)
  • Oracle Advanced Security transparent data encryption (TDE) master encryption keys
  • Passwords for Oracle Database Secure External Password Store

Depending on the application there is one or more wallet. A wallet for an oracle client, a global wallet on the server, one wallet per database instance, a wallet for a database instance acting as a client or a wallet containing all information at once. It doesn’t really get easier when everyone is talking about Oracle Wallets without specifying what they are used for. For this reason, it is advisable to use different Oracle wallets for the various application cases. But more on that later. Oracle Secure External Password Store uses a client-side Oracle Wallet to store the password credentials.

The Secure External Password Store

Concept

With Secure External Password Store, Oracle stores the database credentials, ie username and password, securely in an Oracle Wallet. When initiating a database connection Oracle accesses the wallet and reads the credentials depending on the connect string. Since auto login is configured, no password is required to open the wallet and read the credentials. A password is only required to add, change, or delete credentials in the wallet.

The connect string is unique in the Wallet. Only one credential can be stored per connect string. Different credentials for the same database must be distinct by a different connect string.

Configuration

Create some directories for the SQLNet configuration and the wallet:

mkdir -p /u00/app/oracle/admin/$ORACLE_SID/network
mkdir -p /u00/app/oracle/admin/$ORACLE_SID/network/admin
mkdir -p /u00/app/oracle/admin/$ORACLE_SID/network/wallet

Define a TNS Alias in tnsnames.ora file for the catalog conection:

vi /u00/app/oracle/admin/$ORACLE_SID/network/admin/tnsnames.ora

CATALOG =
 (DESCRIPTION =
   (ADDRESS = (PROTOCOL = TCP)(HOST = urania1)(PORT = 1521))
     (CONNECT_DATA =
       (SERVER = DEDICATED)
    (SERVICE_NAME = TCAT01)
  )
 )

Create a wallet for Secure External Password Store:

mkstore -wrl /u00/app/oracle/admin/$ORACLE_SID/network/wallet -create
Enter password:         Manager01
Enter password again:   Manager01

Create database connection credentials in the wallet:

mkstore -wrl /u00/app/oracle/admin/$ORACLE_SID/network/wallet -createCredential catalog rman manager
Oracle Secret Store Tool : Version 11.2.0.3.0 - Production
Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:            
   
Create credential oracle.security.client.connect_string1

Modify the sqlnet.ora and add the WALLET_LOCATION and SQLNET.WALLET_OVERRIDE parameter to start using the Secure External Password Store:

vi /u00/app/oracle/admin/$ORACLE_SID/network/admin/sqlnet.ora

WALLET_LOCATION =
   (SOURCE =
      (METHOD = FILE)
      (METHOD_DATA = (DIRECTORY = /u00/app/oracle/admin/$ORACLE_SID/network/wallet))
)
SQLNET.WALLET_OVERRIDE = TRUE

Use

Since we put the tnsnames.ora, sqlnet.ora and the wallet in an alternativ directories we have to set TNS_ADMIN before being able to use it.

export TNS_ADMIN=/u00/app/oracle/admin/$ORACLE_SID/network/admin

oracle@urania:~/ [TDB11] sqlplus /@catalog

SQL*Plus: Release 11.2.0.3.0 Production on Mon Jul 14 22:13:30 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show user
USER is "RMAN"

oracle@urania:~/ [TDB11] rman

Recovery Manager: Release 11.2.0.3.0 - Production on Mon Jul 14 22:13:09 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

RMAN> connect catalog /@catalog

connected to recovery catalog database

RMAN>

Maintenance

The mkstore utility provide a bunch of commands to maintain the credentials within a wallet. Below you find some examples. More are available in MOS Note 340559.1.

Liste the contents of the external password store:

oracle@urania:~/ [TDB11] mkstore -wrl /u00/app/oracle/admin/$ORACLE_SID/network/wallet -listCredential
Oracle Secret Store Tool : Version 11.2.0.3.0 - Production
Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:            

List credential (index: connect_string username)
1: catalog rman

Modifying database login credentials in a wallet :

oracle@urania:~/ [TDB11] mkstore -wrl /u00/app/oracle/admin/$ORACLE_SID/network/wallet -modifyCredential CATALOG rman manager
Oracle Secret Store Tool : Version 11.2.0.3.0 - Production
Copyright (c) 2004, 2011, Oracle and/or its affiliates. All rights reserved.

Enter wallet password:            

Modify credential
Modify 1

A few use and special cases

There are a whole lot of cases where you can not save or share passwords. A few examples:

  • General applications where you want to authenticate “password free”, without setting up a PKI infrastructure.
  • Avoid RMAN Catalog passwords in backup scripts.
  • Avoid SYSDBA / SYSDG account passwords in an Oracle DataGuard environment.
  • Regular DBA batch jobs scheduled by cron. Remove passwords in shell and SQL scripts.
  • Simplify end-user experience. Use Secure External Password Store to save passwords instead of saving them in TOAD or SQL Developer.
  • Configure Application and Web server to use Secure External Password Store rather than save and maintain database credentials in the Application.
  • Application batch jobs scheduled by cron. Remove passwords in shell and SQL scripts.

Multiple RMAN Catalog Schemas

In my example above I did use the user RMAN to connect to the catalog. To be honest this user does only have a CREATE SESSION privilege. There are two RMAN Catalog Schema in my Catalog Database, RMAN11203 for 11.2.0.3.0 respectively RMAN12101 for 12.1.0.1.0.

SQL> SELECT * FROM RMAN11203.RCVER;

VERSION
------------
11.02.00.03

SQL> SELECT * FROM RMAN12101.RCVER;

VERSION
------------
12.01.00.01

Instead of adding each credential for any RMAN Catalog to the wallet one can use the proxy authentication. In this case you just have to grant the appropriate privileges to the user RMAN. Instead of distributing all RMAN catalog credentials in each Oracle Wallet, you need to maintain only one account and additionally a few proxy privileges in the RMAN catalog. This does of course also work for other applications.

SQL> ALTER USER RMAN11203 GRANT CONNECT through RMAN;

USER altered.

SQL> ALTER USER RMAN12101 GRANT CONNECT through RMAN;

USER altered.

As you can see below, it is now possible to specify the user or schema in the connect string. The authentication is done as user RMAN. Credentials are read from the Secure External Password Store.

export TNS_ADMIN=/u00/app/oracle/admin/$ORACLE_SID/network/admin

oracle@urania:~/ [TDB11] sqlplus [RMAN12101]/@catalog

SQL*Plus: Release 11.2.0.3.0 Production on Mon Jul 14 22:13:30 2014

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> show user
USER is "RMAN12101"

SQL> SELECT SYS_CONTEXT ('USERENV','SESSION_USER') FROM DUAL;

SYS_CONTEXT('USERENV','SESSION_USER')
------------------------------------------------
RMAN12101

SQL> SELECT SYS_CONTEXT ('USERENV','PROXY_USER') FROM DUAL;

SYS_CONTEXT('USERENV','PROXY_USER')
-------------------------------------------------
RMAN

oracle@urania:~/ [TDB11] rman

Recovery Manager: Release 11.2.0.3.0 - Production on Mon Jul 14 22:13:09 2014

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

RMAN> connect catalog ¨[RMAN12101]/@catalog

connected to recovery catalog database

RMAN>

Data dictionary view about all proxy connections.

col proxy FOR a6
col client FOR a10
col ROLE FOR a5
SET linesize 120
SELECT * FROM DBA_PROXIES;

PROXY CLIENT    AUT AUTHORIZATION_CONSTRAINT            ROLE PROXY_AUT
----- --------- --- ----------------------------------- ---- ---------
RMAN  RMAN11203 NO  PROXY MAY ACTIVATE ALL CLIENT ROLES      DATABASE
RMAN  RMAN12101 NO  PROXY MAY ACTIVATE ALL CLIENT ROLES      DATABASE

Oracle Transparent Data Encryption

Oracle Transparent Data Encryption use as well an Oracle Wallet to store the TDE master keys. Unlike the Oracle wallet used for SSL for encryption or Secure External Password Store, this wallet is defined in the sqlnet.ora with the parameters ENCRYPTION_WALLET_LOCATION. But if the parameter ENCRYPTION_WALLET_LOCATION is not set Oracle will use WALLET_LOCATION to locate the wallet used for TDE. If both parameter are omitted Oracle will fallback to the default location. If the $ORACLE_BASE is set, this is “$ORACLE_BASE/admin/DB_UNIQUE_NAME/wallet”, otherwise it is “$ORACLE_HOME/admin/DB_UNIQUE_NAME/wallet”. In general it is a good practice to set both parameters in sqlnet.ora.

ENCRYPTION_WALLET_LOCATION =
   (SOURCE =
      (METHOD = FILE)
      (METHOD_DATA = (DIRECTORY = /u00/app/oracle/admin/$ORACLE_SID/wallet))
)

WALLET_LOCATION =
   (SOURCE =
      (METHOD = FILE)
      (METHOD_DATA = (DIRECTORY = /u00/app/oracle/local/tvdbackup/network/wallet))
)
SQLNET.WALLET_OVERRIDE = TRUE

There are the following combinations depending on how you use TDE together with the External Password Store.:

  • If TDE is not used you only have to set WALLET_LOCATION in sqlnet.ora used by RMAN.
  • If TDE is used for tablespace or column encryption, you have to set at least ENCRYPTION_WALLET_LOCATION in sqlnet.ora used by the database. The parameter WALLET_LOCATION is only required in sqlnet.ora used by RMAN. But if RMAN is used to open the database (eg. offline backup, restore etc), it will also require a correct ENCRYPTION_WALLET_LOCATION parameter. Otherwise the database respectively the encrypted tablespaces cannot be opened.
  • If TDE is used for transparent backup encryption, you will need in any case a correct setting of ENCRYPTION_WALLET_LOCATION and WALLET_LOCATION in sqlnet.ora used by RMAN.

See also MOS Note 1228046.1 Master Note For Transparent Data Encryption ( TDE ) and 1504783.1 Setting ENCRYPTION_WALLET_LOCATION For Wallets Of Multiple Instances Sharing The Same Oracle Home

Oracle SSL Authentication

A further special case is when an application uses SSL for encryption. Setting the sqlnet.ora parameter, SQLNET.AUTHENTICATION_SERVICES, specifies SSL and an SSL wallet is created. If this application wants to use secret store credentials to authenticate to databases (instead of the SSL certificate), then those credentials must be stored in the SSL wallet. After SSL authentication, if SQLNET.WALLET_OVERRIDE = TRUE, then the user names and passwords from the wallet are used to authenticate. If SQLNET.WALLET_OVERRIDE = FALSE the SSL certificate is used.

Possible solutions or workarounds:

  • Store the credentials in the SSL wallet and set SQLNET.WALLET_OVERRIDE accordingly.
  • Define a separate TNS_ADMIN and a sqlnet.ora for the user, application respectively OS environment, which wants to use secret store credentials.

See also MOS Note 340559.1 Using The Secure External Password Store.

Oracle Instant Client

Although the Oracle Instant Client does not contain tools to create or modify Oracle Wallets, it is able to access the wallet and read the required credentials. The wallet can be prepared on the database server and copied to the instant client. Thus no credential have to be stored in an application. But be aware, anybody who can access the wallet can also log into the database. The access to the wallet must be limited with the corresponding OS access privileges. See as well MOS Note 1441745.1 Using a Secure External Password Store with the JDBC Thin Driver.

Wallet deploy option

Depending on the use of the Oracle wallets, there are different ways to deploy them. In general it is a good practice to define a wallet for each database, regardless of whether TDE is used or not. The wallet location is defined with the sqlnet.ora parameter ENCRYPTION_WALLET_LOCATION. In addition, a generic wallet can be defined for Secure External Password Store with sqlnet.ora parameter WALLET_LOCATION. Alternatively you can create a specific wallet, which is only used by RMAN to lookup database credentials. This specific wallet is part of the RMAN backup scripts and will be activeted by setting an alternative TNS_ADMIN when executing the backup scripts. Such a wallet could be distributed with the backup scripts on all servers. Various RMAN catalog schema can easily be accessed by using proxy privileges.

A possible scenario with Trivadis TVD-Backup™:

  1. Configure default sqlnet.ora. eg. set ENCRYPTION_WALLET_LOCATION to /u00/app/oracle/admin/$ORACLE_SID/wallet and WALLET_LOCATION to /u00/app/oracle/network/wallet
  2. Use the instance specific wallet in /u00/app/oracle/admin/$ORACLE_SID/wallet for TDE
  3. Use the generic wallet in /u00/app/oracle/network/wallet for SSL, Password Store etc
  4. Configure your backup scripts eg. TVDBACKUP_BASE=/u00/app/oracle/local/tvdbackup
  5. Create a dedicated network and wallet directory for your backup tool eg. $TVDBACKUP_BASE/network/admin respectively $TVDBACKUP_BASE/network/wallet
  6. Set RMAN specific TNS_ADMIN before executing the backup script eg. export TNS_ADMIN=$TVDBACKUP_BASE/network; rman_exec.ksh -t TDB11 -s bck_inc0
  7. Deploy your backup script.

Licensing

The licensing of Oracle Secure External Password Store is at first sight somewhat obscure. Depending on which version of Oracle Documentation or Metalink Notes you’re reading, different kind of information are available. According to old documentation or Metalink Notes like 465460.1, 1084132.1 or 1628809.1 Oracle Secure External Password Store is limited to Oracle Enterprise Edition. This limitation has been removed from all available online Oracle documentation. Secure External Password Store can be used on all production editions. Therefore do not hesitate to use it. 🙂

Quote from MOS Note 340559.1 Using The Secure External Password Store:

The feature Secure External Password Store can be used without any restriction in all product editions, you do not require a license for the Advanced Security Option (ASO).

Conclusion

Oracle Secure External Password Store is a simple and secure solution to increase database security and to avoid clear text password in any kind of scripts or applications. Although Secure External Password Store is available for several Oracle releases, it is actually far too little used. The biggest challenge in connection with Oracle Secure external password store is the uniform distribution and configuration of sqlnet.ora. This blog post should give some ideas how Oracle Secure External Password Store could be used in conjunction with RMAN. Whether on the database server, application server or Oracle client, saving passwords is a thing of the past.

References

Although I haven’t seen many customers using Oracle Secure External Password Store, there are a lot of information, white papers and Metalink notes on this topic available.

Oracle CPU / PSU Pre-Release Announcement July 2014

Oracle has published the Pre-Release Announcement for the July 2014 Critical Patch Update. It looks like that the next Critical Patch Update is somewhat more extensive from the database point of view. It does contain six bug fix for some major security issues. Some of the vulnerabilities may be remotely exploitable without authentication. The security bug fixes are for the Oracle Database Server as well for client-only installations.

The highest CVSS Base Score of vulnerabilities affecting Oracle Database Server is 9.0. The following components are affected:

  • Network Layer
  • RDBMS Core
  • XML Parser

We will see all the details next Tuesday when Oracle is officially releasing official Critical Patch Update for April 2014. Next week I’ll have a closer look and do some test installations.

More details about the patch will follow soon on the Oracle Security Pages.

Release of Audit Vault and Database Firewall 12.1.2 Bundle Patch 1

Earlier today, Oracle has released the first Bundle Patch for Audit Vault and Database Firewall 12.1.2. The patch can be downloaded on Oracle Metalink as Patchset 18728905 for existing installations or on Oracle eDelivery as full installation image for new installations. The installation image is split in two parts which need to be merged before use. A short description on how to merge the image can be found on my blog post about Audit Vault and Database Firewall 12.1.2.

According the readme, the Release 12.1.2 BP1 contains the April 2014 PSU 11.2.0.3.10 for the database as well several bug fix for the base platform. These include security and stability fixes to Java and the underlying Linux operating system.

Before installing the bundle patch it is absolutely recommended, that you create a backup of the AVDF Installation and ensure that there is free space in the following Audit Vault Server partitions.

  • 5 GB in /var/lib/oracle
  • 5 GB in /var/tmp
  • 4.5 GB in /root

The upgrade will fail, if the partitions does not have enough free space. The bundle patch readme describes the different upgrade scenarios. I’ll upgrade my AVDF 12.1.2 Test VM once the download of the 3GB bundle patch is finished.

References

Some links related to the Audit Vault and Database Firewall:

Oracle passwords and special characters

As commonly known passwords should have a certain complexity. Thereby it is common to use special characters, numbers, lower and uppercase characters. Depending on the type of special characters Oracle require that the password is enclosed in double quotation marks. Oracle does provide a guideline for Securing Passwords in the Oracle® Database Security Guide. So far so well, depending on the applications or Oracle clients the enclosing doesn’t really work as expected. Some Special characters like a $ or % are used to indicate an environment variable, other special characters like /, [] or @ are used to build the connect string. But a really nasty special character is the backslash respectively the \. The backslash is in general used as escape character to change subsequent literal characters into metacharacters and vice versa. The use of the backslash in an Oracle password has some very interesting side effects :-).

Ok, lets create a test user with a complex password and a backslash \ somewhere in the password.

SQL> conn / AS sysdba
Connected.
SQL> CREATE USER smith IDENTIFIED BY "KT20\dft";

USER created.

SQL> GRANT CREATE SESSION TO smith;

GRANT succeeded.

SQL> conn smith/KT20\dft
Connected.

SQL> SHOW USER
USER IS "SMITH"

SQL> conn smith/"KT20\dft"
Connected.

SQL> SHOW USER;
USER IS "SMITH"

SQL> conn smith/"KT20\dft"@TDB11
Connected.

SQL> SHOW USER;
USER IS "SMITH"

SQL> conn smith/KT20\dft@TDB11
Connected.

To create the user I’ve used the double quotation marks to enclose the password. As you can see, the attempts to log on to the database have worked in any case. In contrast to the login, alter the password definitely requires some quotation as you can see below.

SQL> ALTER USER smith IDENTIFIED BY KT20\dft;
ALTER USER smith IDENTIFIED BY KT20\dft
                                   *
ERROR at line 1:
ORA-00911: invalid CHARACTER

Ok, lets put the backslash at the end of the password and try to login again.

SQL> ALTER USER smith IDENTIFIED BY "KT20dft\";

User altered.

SQL> conn smith/KT20dft\
Connected.

SQL> show user
USER is "
SMITH"

SQL> conn smith/"
KT20dft\"
SP2-0306: Invalid option.
Usage: CONN[ECT] [{logon|/|proxy} [AS {SYSDBA|SYSOPER|SYSASM}] [edition=value]]
where <logon> ::= <username>[/<password>][@<connect_identifier>]
      <proxy> ::= <proxyuser>[<username>][/<password>][@<connect_identifier>]

SQL> conn smith/"
KT20dft\"@TDB11
SP2-0306: Invalid option.
Usage: CONN[ECT] [{logon|/|proxy} [AS {SYSDBA|SYSOPER|SYSASM}] [edition=value]]
where <logon> ::= <username>[/<password>][@<connect_identifier>]
      <proxy> ::= <proxyuser>[<username>][/<password>][@<connect_identifier>]

SQL> conn smith@TDB11
Enter password: ********
Connected.
SQL> show user
USER is "
SMITH"

SQL> conn smith/KT20dft\@TDB11
ERROR:
ORA-01017: invalid username/password; logon denied


Warning: You are no longer connected to ORACLE.

As you can see above, the Login no longer works so smoothly. Using the username and password without any quotation does work. Any other combination with quotation or the connect identifier does not work any more. In these cases the backslash does behave as a escape character. Mmh, in this case it should be possible to escape the backslash with a second backslash isn’t it?

SQL> conn smith/"KT20dft\\"
ERROR:
ORA-01017: invalid username/password; logon denied

No, doesn’t work. So far I have found no way to use the backslash at the end of a password, unless the password is entered interactively. For an administration tool like SQLPlus, SQL Developer etc which is anyway used interactively it isn’t a problem. But if you would like to setup batch jobs, RMAN backup’s etc it does not work.

Recovery Manager: Release 11.2.0.3.0 - Production ON Tue Jun 12 08:33:43 2014

Copyright (c) 1982, 2011, Oracle AND/OR its affiliates.  ALL rights reserved.

RMAN>
RMAN>
RMAN> CONNECT target *
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-10000: error parsing target DATABASE CONNECT string "sys/"KT20dft\"@TDB11"

RMAN> run
2> {
3>
4> allocate channel ch1 TYPE disk;
5> backup CURRENT control file;
6> }
USING target DATABASE control file instead OF recovery catalog
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure OF allocate command at 06/12/2014 08:33:43
RMAN-06171: NOT connected TO target DATABASE

Conclusion

It is still highly recommended to use complex passwords. Although Oracle supports all types of multi-byte characters, it is useful to test some special characters before these are used in passwords. Not everything always works as you expect.

Update: AVDF installation fails on HP server with Smart Array

A couple of days ago I’ve wrote about some problems when installing Oracle Audit Vault and Database Firewall 12.1.2 on HP server with Smart Array Disk Controller. The problem is still not resolved, but in the meantime Oracle has open a Bug and added some Metalink Notes related to this issue.

  • AVDF 12.1.1 Installation Fails On HP server with Smart Array Disk Controller [1587742.1]
  • Unable To Install AVDF Server With HP Smart Array [1680134.1]
  • AVDF installation ISO [1680961.1]
  • Bug 18940816 AVDF SERVER FAILS TO INSTALL ON HP DL380 GEN8 WITH CCISS!C0D0 ERROR

The contents of MOS note 1680134.1 and 1680961.1 are certainly known to the regular readers of OraDBA. The workaround and procedure are the same as I’ve posted a couple of days ago. Oracle created MOS notes based on my blog post AVDF installation fails on HP server with Smart Array Disk Controller and AVDF installation ISO. In this case, my posts are somehow useful. 🙂 The Bug mentioned above is unfortunately not publicly available. I’ll provide more information as soon as it is available.