Oracle 11g Kennwörter

von Robert Marz (Kommentare: 0)

Vor kurzem habe ich über meine Probleme mit den neuen Einstellungen für das Default-Profil berichtet.

Der dort gezeigte Trick - das Profil anpassen - funktioniert leider nur für Konten, deren Kennwörter noch nicht abgelaufen (expired) sind.

Der einzige mir bekannte Weg, Konten mit abgelaufenem Kennwort wieder zu aktivieren, ist das Kennwort tatsächlich zu ändern.

Also zum altbekannten Hack gegriffen:

declare
  pwdval   varchar2(30);
  stmt     varchar2(32000);
begin
  select password
    into pwdval
    from dba_users
  where username ='TESTACC';
  stmt := 'alter user TESTACC identified by values '''||pwdval||''' ';
  dbms_output.put_line(stmt);
  execute immediate stmt;
end;

Das scheitert leider, weil ab 11g das Feld Password in dba_users nur noch 3 Ausprägungen annimmt ('GLOBAL', EXTERNAL', NULL) und nicht mehr, wie noch unter 10gR2 den Kennwort-Hash enthält.

Also dba_users durch sys.user$ und username durch name ersetzt und das Konto wieder aktiviert und dank der Profiländerung läuft es jetzt auch nicht mehr ab.

Ich war einen kurzen Moment glücklich, bis ich über ein Phänomen gestolpert bin: Auf einmal ist nur für dieses Konto die Groß- Kleinschreibung der Kennwörter wieder egal.

Wie konnte das passieren?

Also, ein Testcase muß her:

 SQL> select value from v$parameter where name = 'sec_case_sensitive_logon';
VALUE
--------------------------------------------------------------------------------
TRUE

SQL> grant connect to testacc identified by TestAcc; Grant succeeded. SQL> connect testacc/TestAcc Connected. SQL> connect testacc/testacc ERROR: ORA-01017: invalid username/password; logon denied Warning: You are no longer connected to ORACLE. SQL> connect / as sysdba Connected. SQL> select name, password from user$ where name='TESTACC';

NAME PASSWORD ------------------------------ ------------------------------ TESTACC 74437186882FE56E

SQL> alter user TESTACC identified by values '74437186882FE56E';

User altered.

SQL> connect testacc/testacc Connected.

SQL> select value from v$parameter where name = 'sec_case_sensitive_logon'; VALUE -------------------------------------------------------------------------------- TRUE

Nach den Erfahrungen von oben war das zu erwarten.

Lassen wir die Datenbank doch mal selbst berichten, wie sie das Konto anlegen würde:

SQL> drop user testacc cascade;
User dropped.
SQL> grant connect to testacc identified by TestAcc;
Grant succeeded.
SQL> connect testacc/testacc
ERROR:
ORA-01017: invalid username/password; logon denied
Warning: You are no longer connected to ORACLE.
SQL> connect / as sysdba
SQL>select dbms_metadata.get_ddl('USER','TESTACC') from dual
DBMS_METADATA.GET_DDL('USER','TESTACC')
--------------------------------------------------------------------------------
 CREATE USER "TESTACC" IDENTIFIED BY VALUES
'S:BD70207D2CA75B0C0A4759A8F7FF2C39CA03126C8FB6AA499A789E4A9C7E;74437186882FE56E'
      DEFAULT TABLESPACE "USERS"
      TEMPORARY TABLESPACE "TEMP"

Wow, das ist mal ein Langer Hash, der offensichtlich aus zwei Teilen besteht: der zweite, durch den Semikolon abgetrennte Hash ist der Sting aus sys.user$.password. Nur, wo kommt der Rest her? Ein bisschen gesucht, et voilà:

SQL>select name, password, spare4 from sys.user$ where name='TESTACC'
NAME                           PASSWORD
------------------------------ ------------------------------
SPARE4
--------------------------------------------------------------------------------
TESTACC                        74437186882FE56E
S:BD70207D2CA75B0C0A4759A8F7FF2C39CA03126C8FB6AA499A789E4A9C7E

Der neue Hash versteckt sich also im Feld SPARE4 der sys.user$ - Dieses Feld ist wohl nicht mehr aufgespart ;-)

Zurück

Einen Kommentar schreiben