Herunterladen Diese Seite drucken

Siemens SIMATIC NET RUGGEDCOM RX5000 Konfigurationshandbuch Seite 1380

Ruggedcom rox ii v2.15 weboberfläche
Vorschau ausblenden Andere Handbücher für SIMATIC NET RUGGEDCOM RX5000:

Werbung

Objekt
usmUserOwnAuthKeyChange
usmUserPrivProtocol
RUGGEDCOM ROX II v2.15 Weboberfläche
Konfigurationshandbuch, 05/2022, C79000-G8900-1534-02
Beim Anlegen eines neuen Benutzers ist dies ein Fehler 'inconsistentName'
für einen SET-Vorgang mit Verweis auf dieses Objekt, sofern es nicht zuvor
oder gleichzeitig mit einem SET-Vorgang an der entsprechenden Instanz
von usmUserCloneFrom initialisiert wurde. Wenn das entsprechende
usmUserAuthProtocol den Wert usmNoAuthProtocol hat, ist das Setzen
erfolgreich, aber effektiv ein Nulloperationsbefehl. Wenn dieses
Objekt gelesen wird, wird ein leerer String zurückgegeben. Um einen
Schlüssel zu ändern, wird folgende Vorgehensweise empfohlen: 1)
GET(usmUserSpinLock.0) und in sValue speichern. 2) Den Wert keyChange
anhand des alten (vorhandenen) Schlüssels und des neuen Schlüssels
generieren, zum Beispiel als kcValue. Wenn die Änderung des Schlüssels für
einen anderen Benutzer ausgeführt wird: 3) SET(usmUserSpinLock.0=sValue,
usmUserAuthKeyChange=kcValue usmUserPublic=randomValue) Wenn Sie
den Schlüssel für sich selbst ändern: 4) SET(usmUserSpinLock.0=sValue,
usmUserOwnAuthKeyChange=kcValue usmUserPublic=randomValue)
Wird eine Antwort mit Fehlerstatus noError erhalten, war der SET-Vorgang
erfolgreich und der neue Schlüssel ist aktiv. Wird keine Antwort empfangen,
kann ein GET(usmUserPublic) veranlasst und geprüft werden, ob der
Wert gleich dem in SET gesendeten randomValue ist. Trifft dies zu,
wurde der Schlüssel erfolgreich geändert und der neue Schlüssel ist aktiv
(wahrscheinlich ist die Antwort verloren gegangen). Trifft dies nicht zu, hat
die SET-Anfrage wahrscheinlich nie das Ziel erreicht und Sie können obige
Prozedur erneut ausführen.
Syntax: String
Zugriff: Nur Lesezugriff
OID: 1.3.6.1.6.3.15.1.2.2.1.7
Beschreibung: Verhält sich genau wie usmUserAuthKeyChange, mit einem
bedeutsamen Unterschied: Damit der SET-Vorgang erfolgreich ist, muss
usmUserName für den Anforderer des Vorgangs mit dem usmUserName
übereinstimmen, der die Zeile, die Ziel dieses Vorgangs ist, indexiert.
Außerdem muss für diesen Vorgang das USM-Sicherheitsmodell verwendet
werden. Der Gedanke dahinter ist, dass diese Spalte öffentlich sein
kann, weil sie einem Benutzer nur erlaubt, seinen eigenen geheimen
Authentifizierungsschlüssel (authKey) zu ändern. Dies kann nur erfolgen,
wenn die Zeile aktiv ist. Wird ein SET-Vorgang empfangen und der
usmUserName des Anforderers stimmt nicht mit dem umsUserName
überein, der die Zielzeile dieses Vorgangs indexiert, muss ein Fehler
'noAccess' zurückgegeben werden. Wird ein SET-Vorgang empfangen
und ein anderes Sicherheitsmodell als USM verwendet, muss ein Fehler
'noAccess' zurückgegeben werden.
Syntax: OID
Zugriff: Nur Lesezugriff
OID: 1.3.6.1.6.3.15.1.2.2.1.8
Beschreibung: Angabe, ob die für diesen Benutzer an die/von der mit
usmUserEngineID bezeichnete(n) SNMP-Engine gesendeten Nachrichten
gegen eine Preisgabe geschützt werden können und wenn ja, der Typ
des verwendeten Verschlüsselungsprotokolls. Eine Instanz dieses Objekts
wird gleichzeitig mit der Erstellung einer anderen Objektinstanz für den
gleichen Benutzer erstellt (d.h. im Rahmen der Verarbeitung des SET-
Vorgangs, mit dem die erste Objektinstanz in der gleichen Conceptual Row
erstellt wird). Wenn ein erstmaliger SET-Vorgang (d.h. beim Anlegen der
Zeile) versucht, einen Wert für ein unbekanntes oder nicht unterstütztes
Protokoll einzustellen, muss ein Fehler 'wrongValue' zurückgegeben
werden. Der Wert wird überschrieben/gesetzt, wenn ein SET-Vorgang an
der entsprechenden Instanz von usmUserCloneFrom ausgeführt wird. Nach
19.1 Unterstützte MIBs
Beschreibung
Referenz
1335

Werbung

loading