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 
Abbonieren Sie den RSS Feed