Der Zugriff auf ein Exemplar oder eine Datenbank erfordert zunächst, daß der Benutzer auf seine Identität überprüft wird. Die Authentifizierungsart für das jeweilige Exemplar bestimmt, wie und wo der Benutzer überprüft wird. Die Authentifizierungsart wird in der Konfigurationsdatei des Datenbankmanagers auf dem Server gespeichert. Sie wird erstmalig bei der Erstellung des Exemplars definiert. Weitere Informationen zu diesem Datenbankmanager-Konfigurationsparameter finden Sie in Kapitel 32, Konfigurieren von DB2. Es gibt eine Authentifizierungsart pro Exemplar, die für den Zugriff auf den zugehörigen Datenbank-Server und alle Datenbanken unter seiner Steuerung gilt.
Wenn Sie auf Datenquellen von einer zusammengeschlossenen Datenbank aus zugreifen wollen, müssen Sie die Authentifizierungsverarbeitung der Datenquellen und die Definitionen für die Authentifizierungsarten zusammengeschlossener Datenbanken beachten. Weitere Informationen finden Sie in Authentifizierungsverarbeitung in zusammengeschlossenen Datenbanken.
Die folgenden Authentifizierungsarten stehen zur Verfügung:
Anmerkung: | Der Server-Code erkennt, ob eine Verbindung lokal oder fern ist. Für lokale Verbindungen sind bei der Authentifizierungsart SERVER keine Benutzer-ID und kein Kennwort zur erfolgreichen Authentifizierung erforderlich. |
Wenn für das ferne Exemplar die Authentifizierungsart SERVER definiert ist, müssen eine Benutzer-ID und ein Kennwort vom Benutzer bereitgestellt oder von DB2 abgerufen werden und an den Server zur Gültigkeitsprüfung gesendet werden, auch wenn der Benutzer sich bereits an der lokalen Maschine oder der Domäne angemeldet hat.
Wenn als Client-Authentifizierung DCS oder SERVER angegeben ist, wird der Client überprüft, indem die Benutzer-ID und das Kennwort an den Server übergeben werden. Wenn die Client-Authentifizierung DCS_ENCRYPT oder SERVER_ENCRYPT lautet, wird der Client überprüft, indem eine Benutzer-ID und ein verschlüsseltes Kennwort übergeben werden.
Wenn auf dem Client SERVER_ENCRYPT und auf dem Server SERVER angegeben ist, wird ein Fehler zurückgegeben, da die Authentifizierungsebenen voneinander abweichen.
Wenn der Benutzer eine lokale Anmeldung bzw. Anmeldung auf dem Client vornimmt, ist der Benutzer nur dieser lokalen Client-Workstation bekannt.
Wenn für das ferne Exemplar die Authentifizierungsart CLIENT definiert ist, bestimmen zwei weitere Parameter die endgültige Authentifizierungsart: trust_allclnts und trust_clntauth.
Sicherheit auf CLIENT-Ebene nur für gesicherte Clients (TRUSTED):
Gesicherte Clients sind Clients, die über ein zuverlässiges lokales Sicherheitssystem verfügen. Insbesondere sind alle Clients mit Ausnahme der Windows 95- und Windows 98-Clients gesicherte Clients.
Wenn die Authentifizierungsart CLIENT ausgewählt wurde, kann eine zusätzliche Option zum Schutz vor Clients ausgewählt werden, deren Betriebsumgebung keine eigenen Sicherheitssysteme hat.
Zum Schutz gegen ungesicherte Clients kann der Administrator die Authentifizierung für gesicherte Clients auswählen, indem er den Parameter trust_allclnts auf den Wert NO setzt. Dies impliziert, daß alle gesicherten Plattformen den Benutzer anstelle des Servers überprüfen können. Nichtgesicherte Clients werden auf dem Server überprüft und müssen daher eine Benutzer-ID und ein Kennwort bereitstellen. Der Konfigurationsparameter trust_allclnts wird verwendet, um anzugeben, ob Sie den Clients "vertrauen" (Trust). Der Standardwert für diesen Parameter ist YES.
Anmerkung: | Es ist möglich, allen Clients zu "vertrauen" (in dem Sie trust_allclnts auf YES setzen), auch wenn Sie einige solcher Clients haben, die über kein eigenes Sicherheitssystem zur Authentifizierung verfügen. |
Vielleicht erscheint es Ihnen auch wünschenswert, die Authentifizierung auch für gesicherte Clients auf dem Server durchzuführen. Zur Festlegung, wo gesicherte Clients überprüft werden sollen, verwenden Sie den Konfigurationsparameter trust_clntauth. Der Standardwert für diesen Parameter ist CLIENT. Weitere Informationen zu diesem Parameter finden Sie in Kapitel 32, Konfigurieren von DB2.
Anmerkung: | Wenn bei gesicherten Clients beim Versuch mit CONNECT oder ATTACH eine Verbindung herzustellen, keine Benutzer-ID oder Kennwort angegeben werden, findet die Gültigkeitsprüfung auf dem Client statt. Der Parameter trust_clntauth wird nur dazu verwendet, festzulegen, wo die Informationen, die in den Klauseln USER/USING angegeben werden, zu überprüfen sind. |
Wenn Sie den Parameter trust_allclnts auf DRDAONLY setzen, definieren Sie einen Schutz gegen alle Clients mit Ausnahme von DRDA-Clients von DB2 für MVS und OS/390, DB2 für VM und VSE und DB2 für OS/400. Nur diese Clients dürfen die Authentifizierung auf der Client-Seite ausführen. Alle anderen Clients müssen eine Benutzer-ID und ein Kennwort bereitstellen, deren Gültigkeit vom Server überprüft wird.
Der Parameter trust_clntauth wird verwendet, um zu bestimmen, wo die oben genannten Clients authentifiziert werden: Wenn trust_clntauth auf "client" gesetzt ist, findet die Authentifizierung auf dem Client statt. Wenn trust_clntauth auf "server" gesetzt ist, wird die Authentifizierung auf dem Client ausgeführt, sofern kein Kennwort angegeben ist, und auf dem Server, sofern ein Kennwort angegeben ist.
TRUST_ALLCLNTS | TRUST_CLNTAUTH | Ungesicherte Nicht-DRDA-Client-Authentifizierung ohne Kennwort | Ungesicherte Nicht-DRDA-Client-Authentifizierung mit Kennwort | Gesicherte Nicht-DRDA-Client-Authentifizierung ohne Kennwort | Gesicherte Nicht-DRDA-Client-Authentifizierung mit Kennwort | DRDA-Client-Authentifizierung ohne Kennwort | DRDA-Client-Authentifizierung mit Kennwort |
---|---|---|---|---|---|---|---|
YES | CLIENT | CLIENT | CLIENT | CLIENT | CLIENT | CLIENT | CLIENT |
YES | SERVER | CLIENT | SERVER | CLIENT | SERVER | CLIENT | SERVER |
NO | CLIENT | SERVER | SERVER | CLIENT | CLIENT | CLIENT | CLIENT |
NO | SERVER | SERVER | SERVER | CLIENT | SERVER | CLIENT | SERVER |
DRDAONLY | CLIENT | SERVER | SERVER | SERVER | SERVER | CLIENT | CLIENT |
DRDAONLY | SERVER | SERVER | SERVER | SERVER | SERVER | CLIENT | SERVER |
Wenn als Client-Authentifizierung DCS oder SERVER angegeben ist, wird der Client überprüft, indem die Benutzer-ID und das Kennwort an DB2 Connect übergeben werden. Wenn die Client-Authentifizierung DCS_ENCRYPT oder SERVER_ENCRYPT lautet, wird der Client überprüft, indem eine Benutzer-ID und ein verschlüsseltes Kennwort übergeben werden.
Wenn auf dem Client DCS_ENCRYPT und auf dem Server DCS angegeben ist, wird ein Fehler zurückgegeben, da die Authentifizierungsebenen voneinander abweichen.
Wenn als Client-Authentifizierung SERVER oder DCS angegeben ist, wird der Client überprüft, indem die Benutzer-ID und das Kennwort an den Server übergeben werden. Wenn die Client-Authentifizierung SERVER_ENCRYPT oder DCS_ENCRYPT lautet, wird der Client überprüft, indem eine Benutzer-ID und ein verschlüsseltes Kennwort übergeben werden. Als Authentifizierungsart des Clients kann nicht DCE_SERVER_ENCRYPT angegeben werden. Wenn als Authentifizierungsart eines Exemplars DCE_SERVER_ENCRYPT angegeben wird, verwenden alle lokalen Anwendungen DCE als Authentifizierungsschema. Dies gilt auch für Dienstprogrammbefehle, die keine Datenbankverbindung oder Exemplarverbindung erfordern.
Mit der Authentifizierungsart DCE_SERVER_ENCRYPT können nicht nur die Authentifizierungsarten DCE und SERVER_ENCRYPT kombiniert werden, sondern es werden damit auch die Einschränkungen für die Verwendung von Gruppen innerhalb von DCE verringert. Wenn die Authentifizierungsart auf DCE_SERVER_ENCRYPT gesetzt ist, wird angenommen, daß die Gruppenliste, die außerhalb der Authentifizierungszeit angefordert wird, vom Basisbetriebssystem und nicht von DCE gesendet wird. Sie können jedoch als Administrator auf dem Server einen Benutzer definieren, der dem kurzen DCE-Namen entspricht, damit die Gruppenliste außerhalb der Authentifizierungszeit unterstützt wird.
Anmerkung: | Die Kerberos-Authentifizierungsarten werden nur auf Clients und Servern unterstützt, die unter Windows 2000 ausgeführt werden. |
Anmerkungen:
* kennzeichnet die beiden wichtigsten Parameter, die am ehesten Probleme verursachen könnten.
Es gibt einige Maßnahmen, um dies zu verhindern: Wenn Sie sich versehentlich aus dem DB2-System aussperren, gibt es auf allen Plattformen eine Sicherheitsoption, die Ihnen ermöglicht, die normalen DB2-Sicherheitsprüfungen außer Kraft zu setzen, um die Konfigurationsdatei des Datenbankmanagers mit Hilfe eines Sicherheitsbenutzers des lokalen Betriebssystems mit hohen Zugriffsrechten zu aktualisieren. Dieser Benutzer hat immer das Zugriffsrecht zur Aktualisierung der Konfigurationsdatei des Datenbankmanagers und kann daher das Problem beheben. Diese Umgehung der Sicherheit ist jedoch auf eine lokale Aktualisierung der Konfigurationsdatei des Datenbankmanagers beschränkt. Sie können einen Sicherheitsbenutzer nicht fern oder für irgendeinen anderen DB2-Befehl verwenden. Dieser Benutzer mit Sonderberechtigung wird folgendermaßen identifiziert: