Credential Management Strategies · Option 5: Remote PL/SQL call SQL> conn / as sysdba SQL> create...

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.


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.


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.


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.


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



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> select sysdate from dual@ftex_primary;

SYSDATE

---------

10-FEB-18



SYSDATE

---------

10-FEB-18


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


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



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



SQL> alter user pwd identified by secret;

SQL> exec pwd.call_do_ddl('alter user pwd identified by secret');


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



SQL> grant alter user to pwd;

SQL> conn pwd/secret@ftexstby



Fails because pwd does not have alter user privilege

Reset pwd password so db link works again

Success



Connected.


Connected.



SQL> sho user

USER is "TEST1"

SQL> select instance_name from v$instance;

INSTANCE_NAME

----------------

FTEXSTBY


Connected.

SQL> sho user

USER is "TEST1"

Can user TEST1 reset their own password from the standby?

Success


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/


SQL> exec pwd.call_change_pwd('secret3','secret2');


SQL> connect pwd/secret3

Connected.


Connected.

SQL> exec pwd.call_change_pwd('password4','password3');



Connected.

SQL> select instance_name from v$instance;

INSTANCE_NAME

----------------

FTEXSTBY



TEST1 can reset their OWN password.

There is NO way for TEST1 to reset any

other password.



Connected.


Connected.


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


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.




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








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


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

[email protected]

Credential Management Strategies · Option 5: Remote PL/SQL call SQL> conn / as sysdba SQL> create...

Documents

Transcript of Credential Management Strategies · Option 5: Remote PL/SQL call SQL> conn / as sysdba SQL> create...