next Privilegien
up Fundamentals
previous Password Security and Resources
  Contents   Index

Subsections


User


Schema

Ein Schema ist eine benannte Sammlung von Objekten. Wenn ein User erstellt wird, wird auch das gleichnamige Schema erstellt. Das Schema erscheint erst wenn Objekte in dem Schema angelegt werden. Die Begriffe User und Schema werden oft gleichwertig benutzt.


User und Schema erstellen

Welchen Tablespace soll der User haben?
CREATE USER user
  IDENTIFIED {BY passwort | EXTERNALLY}
  [ DEFAULT TABLESPACE tablespace ]
  [ TEMPORARY TABLESPACE tablespace ]
  [ QUOTA {integer [K | M] | UNLIMITED } ON tablespace
  [ QUOTA {integer [K | M] | UNLIMITED } ON tablespace
  ] ... ]
  [ PASSWORT EXPIRE ]
  [ ACCOUNT { LOCK | UNLOCK} ]
  [ PROFILE { profile | DEFAULT } ]
;
BY passwort - Die Authentifizierung erfolgt mittels Passwort.
EXTERNALLY - Die Authentifizierung durch das Betriebssystem.
GLOBALLY AS - Die Authentifizierung erfolgt global (Enterprise Directory Service).
DEFAULT|TEMPORARY TABLESPACE - Definiert den Default bzw. Temporary Tablespace.
QUOTA - Legt den maximal vom User zu belegenden Speicher im Tablespace fest.
PASSWORT EXPIRE - Fordert den User beim ersten Einloggen auf ein neues Passwort einzugeben.
ACCOUNT LOCK|UNLOCK - Der User-Account kann gesperrt oder freigegeben werden.
PROFILE - Weist dem User ein Profil zu.
Beachte: Im CREATE USER-Befehl kann man ein PROFILE aber keine Rolle zuweisen. Einen temporären Tablespace kann man keine Quota für eine User zuweisen.
create user name 
  identified by password
  default tablespace tbs_1 
  default temporary tablespace temp
  quota 10M on tbs_1 qutoa 10M on index_tbs 
  password expire
;


Externe Authentifikation

Das Betriebssystem übernimmt die Authentifizierung. Die folgende Variable sollte man nicht ändern, da manche Anwendungen diese Voreinstellung verwenden.
OS_AUTTHENT_PREFIX =OPS$"
create user "OPS$domain\user" identified externally;
Unix-Shell
sqlplus /

Externe Passwort-Authentifizierung

Eine Möglichkeit der Identifizierung von SYSDBA und SYSOPER (nicht der Benutzer!) ist die der Nutzung einer sogenannten Passwort-Datei. Diese Passwort-Datei ist bereits standardmäßig angelegt und liegt unter $ORACLE_HOME/dbs. Der Name der Datei lautet pwdSID.ora . Bitte löschen Sie diese Datei - auch zu Versuchszwecken - nicht! Wenn Sie die Auswirkungen des Fehlens der Datei testen möchten, verschieben Sie diese an einen anderen Ort.

Um die Nutzung der Passwortdatei einzurichten, ist es notwendig, den Initialisierungsparameter REMOTE_LOGIN_PASSWORDFILE zu ändern. Normalerweise zeigt dieser den Wert NONE an. Für die Nutzung der Passwortdatei muss er den Wert EXCLUSIVE aufweisen. Dieser Parameter ist nicht dynamisch. Ändern Sie den Initialisierungsparameter, indem Sie den Befehl

ALTER SYSTEM SET REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE SCOPE=SPFILE;
eingeben. Starten Sie Ihre Instanz neu.

Melden Sie sich nunmehr mit dem Privileg SYSDBA an. Verschieben Sie Ihre Passwortdatei pwdSID.ora an einen beliebigen anderen Ort (den Sie sich natürlich merken). Melden Sie sich nun von Ihrer Datenbank ab und erneut als SYSDBA an. Ohne Passwortdatei haben Sie nun ein Problem, obwohl Sie über das Privileg SYSDBA verfügen. Eine Meldung, dass Sie nicht über die notwendigen Berechtigungen verfügen verdeutlicht Ihnen die unschöne Situation.

Kopieren Sie die Passwortdatei wieder an Ihren ursprünglichen Ort. Wenn Sie neue Benutzer anlegen und Ihnen das Privileg SYSDBA zuweisen, übernimmt die Passwortdatei die Authentifizierung der Benutzer - aber nur derer, denen das Privileg SYSDBA oder SYSOPER zugewiesen wurde. Gibt es keine Passwortdatei, stehen Ihnen die Privilegien SYSDBA und SYSOPER nicht zur Verfügung und können auch nicht Benutzern zugewiesen werden (unter Privilegien tauchen sie gar nicht auf). Eine Passwortdatei erstellen Sie auf BETRIEBSSYSTEMEBENE - also nicht unter SQL - mit dem Befehl

$orapwd file=$ORACLE_HOME/dbs/orapwDB01 password=orapass entries=5
Die Passwortdatei muss immer im Verzeichnis $ORACLE_HOME/dbs liegen, um genutzt werden zu können. Der Name ist festgelegt auf pwdSID.ora - also pwdtestdb.ora.

Der Parameter password = gibt das Kennwort an, das in der Datei gespeichert wird. Die Wahl des Kennwortes ist beliebig (also z.B. password=geheim). Dieses Passswort wird nicht bei der Anmeldung eingegeben. Es wird nur intern verwendet. Der Parameter entries = legt fest, wie viele Passworteinträge in diese Datei vorgenommen werden können. In unserem Beispiel liegt die Obergrenze bei 20. Mehr SYSDBAs oder SYSOPERs darf es also nicht geben.

Bitte planen Sie Ihre Passwortdatei so, dass alle Benutzer hineinpassen, die als SYSDBA oder SYSOPER fungieren sollen. Eine Erweiterung der Passwortdatei um weitere Einträge ist nämlich nicht möglich. Sollten die möglichen Einträge (entries) nicht ausreichen, müssen Sie eine neue Datei erstellen! Bitte beachten Sie auch, dass dann alle SYSDBA und SYSOPER-Privilegien neu zugewiesen werden müssen. Die bereits bestehenden Privilegien verlieren ihre Gültigkeit. Problematisch stellt sich auch immer die Änderung der Privilegien für den Benutzer SYS dar.

Folgende Reihenfolge ist bei Erstellung einer Passwortdatei zwingend:

  1. Erstellen Sie die Passwortdatei
  2. Setzen Sie das Initialisierungsparameter
  3. Weisen Sie den Benutzern entsprechende Privilegien als SYSDBA bzw. als SYSOPER zu

Einloggen ohne Passwort


SQLPLUS - Unix

Der administrative Datenbankbenutzer, der auf Unix-Ebene Eigentümer aller datanbankrelevanten Dateien ist, darf sich ohne Passwort anmelden.
sqlplus "/as sysdba"
Diese Berechtigung wird primär über die Zugehörigkeit zur Unix-Gruppe der DBAs geregelt. Der Name dieser Gruppe ist in den meisten Fällen dba. Im Zweifel sieht man sich die Zugehörigkeit der Dateien unterhalb von $ORACLE_HOME an, der Besitzer der Dateien ist fast sicher der administrative Datenbankbenutzer. Die genaue Bezeichnung der DBA-Gruppe findet sich in
$ORACLE_HOME/rdbms/lib/config.c unter der Sektion ss_dbs_grp.
/*  SS_DBA_GRP defines the UNIX group ID for adminstrative access.  */
/*  Refer to the Installation and User's Guide for further information.  */

#define SS_DBA_GRP "dba"
#define SS_OPER_GRP "dba"

char *ss_dba_grp[] = {SS_DBA_GRP, SS_OPER_GRP};


OEM Console - Windows

Wenn Sie Oracle unter Windows betreiben müssen, dann haben Sie (wahrscheinlich nicht nur) ein Sicherheitsproblem. Man kann sich als Windows-Administrator in die OEM Console ohne gültiges Passwort einloggen. Eine Trennung zwischen den Verantwortlichkeiten der System- und Datenbank-Administration ist so kaum möglich.

Lösungsvarianten

  1. Windows durch ein ordentliches Server-Betriebssystem ersetzen.
  2. Löschen der Windows-Gruppe ORA_DBA
Die erste Variante ist sicherlich der beste Weg. Müssen Sie Windows verwenden, dann bleibt Ihnen nur die Löschung der Windows-Gruppe Oracle_DBA.
Active Directory
  Domain
    Users
      ORA_DBA -- hau weg


Quotas

Default = 0

Deshalb sollten, ausser auf Undo- und Temporary-Tablespace, Quotas immer angeben werden.

Quota ändern

alter user anna quota 0 on tbs_1;
Wenn Quota verkleinert wird, werden Daten aber nicht gelöscht.


User löschen

Wenn ein Mitarbeiter die Firma verläßt, nicht den entsprechenden User löschen! Besser: Entziehen Sie dem User das Privileg eine Session zu öffnen.
drop user anna cascade;
cascade - Alle Objekte des Schemas werden auch gelöscht.


Informationen über User

DBA_USERS
describe dba_users;
select username,default_tablespace from dba_users;
DBA_TS_QUOTAS
select * from DBA_TS_QUOTAS where username ='anna';

next Privilegien
up Fundamentals
previous Password Security and Resources
  Contents   Index


Stefan Hietel dama.go GmbH, Robert Warnke http://rowa.giso.de