View Full Version : Passwort aus Windows-Programm ändern ( CHGPWD )
Hallo,
wir verwenden bei uns die i5 als Datenbanksystem, unsere Anwendung ist allerdings eine Windows-Applikation.
Damit ein Benutzer bisher sein Passwort ändern konnte, hatten wir eine Funktion geschrieben die ein GUI erzeugt und so im Hintergrund das Passwort ändert. Gibt es eine Möglichkeit CHGPWD im Greenscreen mit Parametern aufzurufen um das Passwort zu ändern? Dann genauso kann ich den Befehl aus meinem Windows-Programm verwenden.
Danke für eure Hilfe.
Mit dem API QSYCHGPW könnte das gehen. V4R5 (http://publib.boulder.ibm.com/html/as400/v4r5/ic2924/info/apis/QSYCHGPW.htm) | V5R2 (http://publib.boulder.ibm.com/iseries/v5r2/ic2924/info/apis/QSYCHGPW.htm)
Sven Schneider
07-11-06, 18:11
Ist aber aus Sicherheitsgründen ein schlechtes Anwendungsdesign.
Da sich so jeder Anwender mit seinem Profil auch manuell (per ODBC, JDBC, FTP etc.) in der Datenbank bewegen kann, d.h. z.B. an der Anwendung vorbei updates ausführen.
Besser :
Ein I5 Anwendungsprofil, mit dem sich die Anwendung gegenüber der Datenbank authorisiert. Das Passowrt hierzu ist nur dem Admin bekannt.
Für die einzelnen Anwender legst du eine eigene Tabelle mit den registrierten Anwendungsbenutzern und deren Passwörtern an.
Hier hast du dann alles selbst in der Hand.
Kannst die Passwörter ändern, verschlüsseln ggf. eigene Anwendungsberechtigungen vergeben etc.
holgerscherer
07-11-06, 19:37
Ist aber aus Sicherheitsgründen ein schlechtes Anwendungsdesign.
Sven... meine persönliche Meinung: Deine Variante ist auch nicht besser. Wie kriegt man da jemals raus, wer in der Applikation rumgefummelt hat? Man hebelt damit die gesamten (nachvollziehbaren) Vorteile des System-Audits aus.
-h
Hier sei noch ergänzt, dass man zusätzlich nach der Verbindung noch das API QSYSETPH aufrufen kann um dann auf den anderen User umzuschalten.
Die Kennworte läßt man generieren, kann sie mit jedem Aufruf ändern (CHGPWD-API kann unter QSECOFR ja Jeder) und schon läufts wieder mit den Journalen.
Eine eigene Anmeldung bekommt man ja nicht hin, da sich das temporäre User-Password ja nicht mal die Anwendung merken muss.
holgerscherer
07-11-06, 20:55
Hier sei noch ergänzt, dass man zusätzlich nach der Verbindung noch das API QSYSETPH aufrufen kann um dann auf den anderen User umzuschalten.
Was haben wir denn dann gewonnen, wenn wir 2 Userprofile verwenden, einmal zum Anmelden und zum Zutritt, und einmal zur Rechteumschaltung und korrekten Auditierung?
Dann habe ich ja noch eine Baustelle mehr, bei der ich mich um ernsthafte Sicherheit kümmern muss; ein PC kann ja ein sehr unsicheres Werkzeug sein.
-h
Genau das ist doch das große Sicherheitsproblem:
Benötigt ein Benutzer mit seiner persönlichen Anmeldung die Datenrechte so stehen diese automatisch für ODBC zur Verfügung.
Bei klassischen 5250-Anwendungen konnte man sich noch mit einem APP-User und Owner-Berechtigung des Startprogrammes behelfen. Dies klappte auch für journalisierte Anwendungen.
ODBC-Zugriffe konnten somit verhindert werden.
Bei Client-Server-Anwendungen und Zugriffen über ODBC/JDBC/DRDA usw. ist es aus mit geerbter Berechtigung.
Die Anmeldung mit einem APP-User scheidet aus o.a. Gründen im Wesentlichen aus.
Was bleibt ?
Genau:
Eigene User-Verwaltung (ggf. mit verschlüsseltem Kennwort)
ODBC-Anmeldung mit APP-User, aufruf einer Prozedur mit User/Kennwort zur eigentlichen Anmeldung und Umschaltung auf das tatsächliche Profil (das nun eben kein bekanntes Kennwort hat).
Gut, dieses geht tatsächlich nur, wenn man keine 5250-Zugriffe mehr benötigt.
holgerscherer
08-11-06, 08:48
Genau das ist doch das große Sicherheitsproblem:
...
Was bleibt ?
Eigene User-Verwaltung (ggf. mit verschlüsseltem Kennwort)
ODBC-Anmeldung mit APP-User, aufruf einer Prozedur mit User/Kennwort zur eigentlichen Anmeldung und Umschaltung auf das tatsächliche Profil (das nun eben kein bekanntes Kennwort hat).
Gut, dieses geht tatsächlich nur, wenn man keine 5250-Zugriffe mehr benötigt.
Na, dann brauche ich auch keinen sicheren Server mehr - der Client ists ja auch nicht. Ich kenne diverse Existenzen dieser Art von Implementierung - bisher war da nicht nur ein Sicherheitsloch (der Server), sondern hunderte (die Clients). Da bin ich doch manchmal froh um den großen Anteil meiner Kunden, die mich schlagen würden, wenn ich denen den 5250 wegnehme.
-h
@Furchau
bei uns gibt es seit Monaten genau diese Anforderung und die scheidet an "meinem" Widerstand. Gestern sollte bewiesen werden, dass ich unrecht habe. Aufbau: Anwender meldet sich mit seinem Benutzer an und ruft ein Programm auf, dass den Benutzer "umschießt". Anschließend sollte den Anwender sich die Daten ohne Benutzung einer Anwendung herunterladen (also SQL). Und siehe da .. er konnte (wie zu erwarten war .. oder ??).
Was will ich damit sagen, auch wenn für die eigentliche Verarbeitung ein anderer Benutzer verwendet wird, dass der Anwender nicht kennt. Sobald das zum "umschießen" benötigte Programm (Prozedur) bekannt ist, "brechen alle Dämme".
Irgendwie ist mir das zu hoch, auf der eine Seite soll die iSeries zur uneinnehmbaren Festung umgewandelt werden und gleichzeit sollen alle Anwender auf alle Daten lesend/schreibend (wg. der schönen graphischen Browseroberfläche) zugreifen können.
Gruß
DVE
Selbst wenn die Prozedur bekannt ist sollten die dazu benötigten Parameter eben nicht bekannt sein.
Die Prozedur muss die Sicherheit leisten dass Sie eben nicht einfach so aufgerufen werden kann.
Andererseits darf es auch kein Benutzerprofil geben, dass eine 5250-lose Anmeldung erlaubt (also ODBC).
So auf die Schnelle fällt mir hierzu nichts ein, es muss aber gehen. Schließlich haben auch andere Datenbanken (SQL-Server, Oracle o.ä.) die selben Probleme wenn es um freie ODBC-Zugriffe geht.
Andere DB's noch um so mehr als dass dort ein Umschiessen des Users nicht möglich ist.
Die Anwendung meldet sich mit eine APP-User an. Dieses Kennwort hierzu muss verschlüsselt abgelegt oder programmiert werden so dass eine normale Anmeldung ausserhalb der Anwendung mit diesem Userprofil unmöglich gemacht wird.
Dann klappt auch das Umschiessen des Users mit einem temporären internen Kennwort dass ausschließlich der Anwendung bekannt ist.
Die dazu nötigen Profile sind selbst wiederum nicht anmeldefähig.
Man kann sogar mal probieren ob QSYGETPH/QSYSETPH mit disabled Profilen möglich ist.
Vielleicht hat ja mal jemand Zeit dies zu probieren.