Unteradmin für USRPRF ohne *secadm

[cs400_de]

Hallo,

leider kann ein User ein USRPRF nicht ändern, obwohl er die Berechtigung *all auf das Objekt des Profils hat.

Es kommt die Meldung

CPF2292  *SECADM für Erstellung oder Änderung der Benutzerprofile 

Ich will dem User aber kein *secadm geben.
Außerdem will ich kein Programm schreiben, mit adopted rights.
Geht das auch so mit Bordmitteln, einen Unteradmin einzurichten?

Grüße

Carsten Schulz

[kuempi von stein]

Will der User etwas an seinem eigenen Profil ändern?

Dann helfen eventuell so Sachen wie CHGPRF oder CHGPWD.
Alles darüber hinaus, sehe ich nicht wie Du da klarkommen willst ohne entsprechende Berechtigung oder Rechteadoption.

Wäre ja auch noch schöner wenn das so einfach wäre..

kuempi

[Pikachu]

Einige Werte des eigenen Benutzerprofils können mit CHGPRF geändert werden.

[BenderD]

...und wenn es nicht der eigene Benutzer ist, dann musst du ihm halt den Trick (bei Windows nennet man sowas Sicherheitslücke) mit dem SBMJOB oder mit dem ADDJOBSCDE beibringen und wenn er das dann doch nicht soll, dann musst du ihm die Berechtigung an den fremden Profilen eh' entziehen.

D*B

Einige Werte des eigenen Benutzerprofils können mit CHGPRF geändert werden.

[cs400_de]

Der User soll den Status eines anderen USRPRF's ändern.
Wenn ich *secadm vergebe, dann hat er Rechte neue User anzulegen.

CHGUSRPRF USRPRF(PPP) STATUS(*ENABLED) 

In der Hilfe steht:

*SECADM                                                              
    Dem Benutzer wird die Berechtigung des Sicherheitsadministrators 
    erteilt. Er kann Benutzerprofile erstellen, ändern oder löschen, 
    wenn er für die Befehle CRTUSRPRF (Benutzerprofil erstellen),    
     CHGUSRPRF (Benutzerprofil ändern) und DLTUSRPRF (Benutzerprofil      
     löschen) und das Benutzerprofil berechtigt ist. Diese Berechtigung   
     befugt nicht zur Erteilung von Sonderberechtigungen, über die dieses 
     Benutzerprofil nicht selbst verfügt. Um einem anderen Benutzer die   
     Sonderberechtigungen *SECADM erteilen zu können, muss ein Benutzer   
     die Sonderberechtigungen *ALLOBJ und *SECADM haben. 

Da der Befehl CRTUSRPRF nur mit *use für public versehen ist, kann er mit *secadm jetzt User anlegen, was er vorher nicht konnte.

Grüße

Carsten Schulz

[Fuerchau]

Alles was mit Profilverwaltung zu tun hat, geht nur mit *SECADM.
Entweder schreibst du ein kleines eigenes Kommando, dass unter QSECOFR läuft und machst das öffentlich, oder der User muss jemanden anrufen

Bei einem eigenen Kommando kann ggf. auch QSECOFR deaktiviert werden, also wäre ein eigenes Kommando á la ENABLEPRF ausreichend.

[Pikachu]

Bei einem eigenen Kommando kann ggf. auch QSECOFR deaktiviert werden, also wäre ein eigenes Kommando á la ENABLEPRF ausreichend.

Besitzt der QSECOFR nicht auch *ALLOBJ. Damit hat er doch immer Zugriff auf alle Objekte auf dem System? Man könnte natürlich im eigenen Programm gezielt auf den Benutzernamen abfragen.

[Fuerchau]

*ALLOBJ schließt nicht *SECADM ein, das ist eine eigene Berechtigung.
Allerdings geht mit *ALLOBJ ein ADDJOBSCDE ... USRPRF(QSECOFR), was natürlich wieder alle Tore aufreißt.

[KM]

Es gibt da ein kleines Tool bei systeminetwork.com und nennt sich RESETUSER.

System iNetwork (formerly iSeries Network) - Securely Reset User Status and Password

Mittlerweile muß man wohl ProVIP sein, um es zu bekommen. Ich hatte die Sourcen damals noch frei bekommen.

Es handelt sich dabei um ein CL-Programm mit dem Owner QSECOFR. Man kann den Status des Benutzerprofils ändern, das Kennwort und Kennwortstatus. In diesem CL-Programm sind Prüfungen drin, dass bestimmte Benutzerprofile nicht geändert werden dürfen (z.B. bei bestimmten Benutzerprofilnamen, Gruppenprofilen oder Sonderberechtigungen).

Gruß,
KM

[Pikachu]

@Fürchau

Ich meinte, ein Benutzer mit *ALLOBJ läßt sich nicht mittels *EXCLUDE vom Zugriff auf ein Objekt ausschließen.

[Fuerchau]

@Pikachu
Stimmt, noch nicht mal QSECOFR.
*ALLOBJ läßt sich nur ein bisschen einschränken, wenn im USRPRF eingeschränkte Kommandozeile aktiviert ist.
Aber spätestens mit PDM ist das auch vorbei, schließlich hindert mich NICHTS daran, Programme unter QSECOFR auszuführen (ADDJOBSCDE) und mir sämtliche fehlenden Berechtigung nachträglich zu erteilen.
Mit dem Opsnav und ein bisschen SQL kann ich den ADDJOBSCDE auch per CALL QCMDEXC vom Opsnav ausführen.