Post on 20-Mar-2020
Credential Management Strategies
in an Oracle Active Data Guard Environment
Roopesh RamklassThursday, February 22
Session 10, 9:45 am - 10:45 am
Roopesh Ramklass
OCP 9i/10g/11g, OCM
Author of 4 Oracle Press books
Lecturer, Oracle University
Founder, Oracle Consultancy
Principal Consultant, Pythian
Senior Data Architect, Eclipsys
Conference Speaker At
• Problem Description: Case Study
• Various attempts to solve problem
• Preferred solution
• Q&A throughout
• Summary
Agenda
4
Problem Description: Case Study
2-node RAC 12c OLTP system in Atlanta
2-node RAC 12c Active Data Guard (ADG) standby in Chicago
Services are used to direct OLTP users to ATL DB and BI/DW/Reports
users to ADG to balance the load.
Problem Description: Case Study
Some R/O users ignore the
management directive and
connect to the primary DB and
negatively impact production OLTP
load when running huge queries.
Over time these users have been
warned and threatened with
disciplinary action if they connect to
the primary service.
Problem Description: Case Study
PCI Compliance* demands all users MUST
change their password every 90 days
(* Payment Card Industry Data Security Standards (PCI DSS)
Users CAN change their passwords when
connected to the PRIMARY DB
Read Only users CANNOT change their
passwords when connected to the ADG
STANDBY
DGMGRL> create configuration dg_ftex as primary database is ftex connect identifier is ftex;
Configuration "dg_ftex" created with primary database "ftex“
DGMGRL> add database ftexstby as connect identifier is ftexstby maintained as physical;
Database "ftexstby" added
DGMGRL> enable configuration;
Enabled.
DGMGRL> show configuration;
Configuration - dg_ftex Protection Mode: MaxPerformance
Databases: ftex - Primary database
ftexstby - Physical standby database
Fast-Start Failover: DISABLED
Configuration Status:SUCCESS
DGMGRL> show database ftex
Database - ftex Role: PRIMARY Intended State: TRANSPORT-ON
Instance(s): FTEX Database Status:SUCCESS
DGMGRL> show database ftexstby
Database - ftexstby Role: PHYSICAL STANDBY Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 1 second ago) Apply Lag: 0 seconds (computed 1 second ago) Apply
Rate: 0 Byte/s Real Time Query: OFF Instance(s): FTEXSTBY
Database Status:SUCCESS
LAB Setup
Test1attempts password change on ADG
SQL> select database_role, name from v$database;
DATABASE_ROLE NAME
---------------- ---------
PRIMARY FTEX
SQL> create user test1 identified by password1;
User created.
SQL> grant create session to test1;
Grant succeeded.
SQL> connect test1/password1@ftexstby
Connected.
SQL> select database_role, name from v$database;
DATABASE_ROLE NAME
---------------- ---------
PHYSICAL STANDBY FTEX
SQL> alter user test1 identified by password2;
alter user test1 identified by password2
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-16000: database open for read-only access
User TEST1 connects to ADG Standby
Test1attempts password change on ADG
ORA-16000
Option 1: Custom App
13
Often done in APEX or as remotely triggered scripts
PROS:
• Solves problem
• User managed
CONS:
• Extra system to build and maintain
• Adds complexity – More moving parts
• Increases skills and computing requirements
Option 1: Custom App
14
Develop Custom App specifically for user self-
service for password management
Option 2: Auto Password reset
15
Often done using DBMS_SCHEDULER
PROS:
• Solves problem automatically
CONS:
• Depends on JOB scheduling infrastructure
• Users cannot choose their own password
• Password transmission must be secure
Option 2: Auto Password reset
16
Develop scheduled jobs either internal or
external to the database to autogenerate
passwords, reset accounts and notify users
SQL> conn test1/password5@ftexstby
ORA-28032: Your password has expired and the database is set to read-only
Option 3: Kerberos/AD Authentication
17
PROS:
• Solves problem and fewer passwords for user
• Implement corporate security standards
• No longer part of Advanced Security Option
CONS:
• Requires KDC infrastructure / AD
• More moving parts -> Increase in complexity for setup and troubleshooting
• Demands co-operation between domain admins and DBAs
Option 3: Kerberos/AD Authentication
18
External Kerberos based authentication is
typically implemented with Active Directory
https://docs.oracle.com/database/121/NTQ
RF/active_dir.htm#NTQRF270
Option 4: Logon trigger
19
Only allow R/O user to connect to
Primary to reset their password.
Logon trigger script
CREATE OR REPLACE TRIGGER CHANGE_PWD_ON_LOGON AFTER logon ON DATABASE
DECLARE
p_session_user varchar2(64);
p_account_status varchar2(64);
p_role varchar2(64);
BEGIN
SELECT UPPER(SYS_CONTEXT('USERENV', 'SESSION_USER')) INTO p_session_user FROM DUAL;
SELECT UPPER(ACCOUNT_STATUS) INTO p_account_status
FROM DBA_USERS WHERE USERNAME=p_session_user;
SELECT SYS_CONTEXT('USERENV','DATABASE_ROLE') into p_role FROM DUAL;
IF (p_session_user like 'TEST%'
AND p_account_status NOT IN ('EXPIRED')
AND p_role='PRIMARY')
THEN
DBMS_SESSION.SET_IDENTIFIER('about to raise app_error..');
RAISE_APPLICATION_ERROR(-20003,'You are not allowed to connect to the database');
END IF;
END; /
Logon trigger test
SQL> conn test3/password2
ERROR:
ORA-00604: error occurred at recursive SQL level 1…
Warning: You are no longer connected to ORACLE.
SQL> conn test3/password2@ftexstby
Connected.
SQL> conn / as sysdba
Connected.
SQL> alter user test3 password expire;
User altered.
SQL> connect test3/password2
ERROR: ORA-28001: the password has expired
Changing password for test3
New password:
Retype new password:
ERROR:
ORA-00604: error occurred at recursive SQL level 1
ORA-20003: You are not allowed to connect to the database
ORA-06512: at line 12
Password unchanged
Warning: You are no longer connected to ORACLE.
SQL> conn test3/password3@ftexstby
Connected.
PROS:
• Solves problem
• Use policies to expire passwords as required.
CONS:
• Confusing message -> Password is changed, but message is “Password unchanged”
• Logon triggers can negatively impact logon performance
• I generally dislike triggers and have locked users out of DB. Must be carefully tested.
Option 4: Logon trigger
22
LOGON TRIGGER denies access to non-EXPIRED users connecting to PRIMARY
Option 5: Remote PL/SQL call
23
R/O user connects to ADG Standby
and calls a procedure over a DB link
Remote procedure runs on primary
and resets their password. Updated
password gets propagated through
DG log shipping mechanism
Option 5: Remote PL/SQL call
SQL> conn / as sysdba
SQL> create user pwd identified by secret;
SQL> grant dba to pwd;
SQL> grant connect, resource to pwd;
SQL> create public database link ftex_primary connect to pwd identified by secret using 'ftex';
Database link created.
SQL> conn test1/password1
SQL> select sysdate from dual@ftex_primary;
SYSDATE
---------
10-FEB-18
SQL> conn test1/password1@ftexstby
SQL> select sysdate from dual@ftex_primary;
SYSDATE
---------
10-FEB-18
Option 5: Remote PL/SQL call
SQL> conn pwd/secret
SQL> CREATE OR REPLACE PROCEDURE do_ddl(STRING IN varchar2) AS
2 BEGIN
3 execute immediate string;
4* END;
Procedure created.
SQL> CREATE OR REPLACE PROCEDURE call_do_ddl(STRING IN varchar2) AS
2 begin
3 do_ddl@ftex_primary(string);
4 end;
Procedure created.
SQL> grant execute on do_ddl, call_do_ddl to test1;
SQL> exec pwd.call_do_ddl('alter user pwd identified by secret1');
PL/SQL procedure successfully completed.
SQL> conn pwd/secret1
Connected.
SQL> conn pwd/secret1@ftexstby
Connected.
Adapted from the 12c MAA whitepaper for active data guard: http://www.oracle.com/technetwork/database/availability/maa-wp-11gr1-activedataguard-1-128199.pdf
Option 5: Remote PL/SQL call
SQL> conn pwd/secret1@ftexstby
Connected.
SQL> exec pwd.call_do_ddl('alter user pwd identified by secret2');
BEGIN pwd.call_do_ddl('alter user pwd identified by secret2'); END;
*
ERROR at line 1:
ORA-01017: invalid username/password; logon denied
ORA-06512: at "PWD.CALL_DO_DDL", line 3
ORA-06512: at line 1
SQL> select sysdate from dual@ftex_primary;
select sysdate from dual@ftex_primary
*
ERROR at line 1:
ORA-01017: invalid username/password; logon denied
ORA-02063: preceding line from FTEX_PRIMARY
Fails because the db link is using the old password for pwd
Option 5: Remote PL/SQL call
SQL> conn pwd/secret1
SQL> alter user pwd identified by secret;
SQL> exec pwd.call_do_ddl('alter user pwd identified by secret');
PL/SQL procedure successfully completed.
SQL> conn pwd/secret@ftexstby
SQL> exec pwd.call_do_ddl('alter user test1 identified by password2');
BEGIN pwd.call_do_ddl('alter user test1 identified by password2'); END;
ERROR at line 1:
ORA-01031: insufficient privileges
ORA-06512: at "PWD.DO_DDL", line 3
ORA-06512: at "PWD.CALL_DO_DDL", line 3
ORA-06512: at line 1
SQL> conn / as sysdba
SQL> grant alter user to pwd;
SQL> conn pwd/secret@ftexstby
SQL> exec pwd.call_do_ddl('alter user test1 identified by password2');
PL/SQL procedure successfully completed.
Fails because pwd does not have alter user privilege
Reset pwd password so db link works again
Success
Option 5: Remote PL/SQL call
SQL> conn test1/password2
Connected.
SQL> conn test1/password2@ftexstby
Connected.
SQL> exec pwd.call_do_ddl('alter user test1 identified by password3');
PL/SQL procedure successfully completed.
SQL> sho user
USER is "TEST1"
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
FTEXSTBY
SQL> conn test1/password3
Connected.
SQL> sho user
USER is "TEST1"
Can user TEST1 reset their own password from the standby?
Success
Option 5: Remote PL/SQL call
SQL> drop public database link ftex_primary;
Database link dropped.
SQL> create public database link ftex_primary using 'ftex';
Database link created.
create or replace procedure change_pwd(i_new_pwd in varchar2,i_old_pwd in varchar2)
authid current_user is
begin
execute immediate 'alter user '||user||' identified by '||CHR(34)||i_new_pwd||CHR(34)||' replace
'||CHR(34)||i_old_pwd||CHR(34);
end;
create or replace procedure call_change_pwd (i_new_pwd in varchar2,i_old_pwd in varchar2) as
begin
change_pwd@ftex_primary(i_new_pwd,i_old_pwd);
end;
Locking things down
Simple DB link
Procedure change_pwd adapted from: https://mikesmithers.wordpress.com/2015/01/11/create-user-and-alter-user-changing-passwords-and-a-new-years-resolution/
Option 5: Remote PL/SQL call
SQL> exec pwd.call_change_pwd('secret3','secret2');
PL/SQL procedure successfully completed.
SQL> connect pwd/secret3
Connected.
SQL> connect test1/password3
Connected.
SQL> exec pwd.call_change_pwd('password4','password3');
PL/SQL procedure successfully completed.
SQL> conn test1/password4@ftexstby
Connected.
SQL> select instance_name from v$instance;
INSTANCE_NAME
----------------
FTEXSTBY
SQL> exec pwd.call_change_pwd('password5','password4');
PL/SQL procedure successfully completed.
TEST1 can reset their OWN password.
There is NO way for TEST1 to reset any
other password.
Option 5: Remote PL/SQL call
SQL> connect test2/password2
Connected.
SQL> connect test2/password2@ftexstby
Connected.
SQL> exec pwd.call_change_pwd('password3','password2');
BEGIN pwd.call_change_pwd('password3','password2'); END;
*
ERROR at line 1:
ORA-06550: line 1, column 7:
PLS-00201: identifier 'PWD.CALL_CHANGE_PWD' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
SQL> conn pwd/secret3
Connected.
SQL> grant execute on call_change_pwd, change_pwd to test2;
Grant succeeded.
TEST2 needs EXECUTE privileges on
pwd.call_change_pwd andpwd.change_pwd procedures.
Option 5: Remote PL/SQL call
SQL> connect test2/password2@ftexstby
SQL> exec pwd.call_change_pwd('password3','password2');
BEGIN pwd.call_change_pwd('password3','password2'); END;
*
ERROR at line 1:
ORA-04045: errors during recompilation/revalidation of PWD.CALL_CHANGE_PWD
ORA-16000: database open for read-only access
SQL> connect test2/password2
SQL> exec pwd.call_change_pwd('password3','password2');
PL/SQL procedure successfully completed.
SQL> connect test2/password3@ftexstby
SQL> exec pwd.call_change_pwd('password4','password3');
PL/SQL procedure successfully completed.
SQL> conn test2/password4@ftexstby
Connected.
It worked the
second time
Run on primary
Fails on standby
PROS:
• Solves problem elegantly and simply
• No need for apps, triggers, scheduled jobs
• Users manage their own passwords
CONS:
• Remote procedure must be carefully constructed to prevent SQL injection or security holes
• Users must be educated on how to change their own passwords
Option 5: Remote PL/SQL call
33
User connects to ADG Standby and calls a remote procedure over a DB link
that runs on primary and resets their password.
1. Custom App
2. Automatic Job to reset password
3. External authentication through
LDAP/Kerberos
4. Logon triggers
5. Remote PL/SQL call
Summary
34
roopesh.ramklass@eclipsys.ca