Sign on restriction? - IBM AS400

This is a discussion on Sign on restriction? - IBM AS400 ; Hello. We have a userprofile that can reset the users Password. I need that this usersprofile, its only possible to sign on locally not over WAN OR from specifically local -WS. Is this possible?? and How? Thanks....

+ Reply to Thread
Results 1 to 6 of 6

Thread: Sign on restriction?

  1. Sign on restriction?

    Hello.

    We have a userprofile that can reset the users Password.

    I need that this usersprofile, its only possible to sign on locally
    not over WAN

    OR from specifically local -WS.

    Is this possible?? and How?

    Thanks.


  2. Re: Sign on restriction?

    il 22/06/2007 8.54, Scrive marsias 36721672:
    > Hello.
    >
    > We have a userprofile that can reset the users Password.
    >
    > I need that this usersprofile, its only possible to sign on locally
    > not over WAN
    >
    > OR from specifically local -WS.
    >
    > Is this possible?? and How?

    If the user-profile has *SERVICE or *ALLOBJ special authorities and
    sysval QLMTSECOFR is set to '1', then he can logon only by the device
    you find in QCONSOLE sysval and devices that he has been explicitly
    authorized to with GRTOBJAUT OBJTYPE(*DEVD) AUT(*USE) command.

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  3. Re: Sign on restriction?


    > If the user-profile has *SERVICE or *ALLOBJ special authorities and
    > sysval QLMTSECOFR is set to '1', then he can logon only by the device
    > you find in QCONSOLE sysval and devices that he has been explicitly
    > authorized to with GRTOBJAUT OBJTYPE(*DEVD) AUT(*USE) command.


    Status are:

    The user-profile has *allobj and user-class are *secadm
    QLMTSECOFR is set to 0
    QCONSOLE =DSP01

    BUT i dont wont to restrict the QSECOFR access, ONLY this userprofile
    "BIGUSER".

    BIGUSER must have the ability to reset the Users-pass and enable any
    userprofiles.

    Devices-names (locally and WAN) are randomly generate by system and
    not defined by me.

    thanks.


  4. Re: Sign on restriction?

    On Jun 22, 11:00 am, marsias wrote:
    > > If the user-profile has *SERVICE or *ALLOBJ special authorities and
    > > sysval QLMTSECOFR is set to '1', then he can logon only by the device
    > > you find in QCONSOLE sysval and devices that he has been explicitly
    > > authorized to with GRTOBJAUT OBJTYPE(*DEVD) AUT(*USE) command.

    >
    > Status are:
    >
    > The user-profile has *allobj and user-class are *secadm
    > QLMTSECOFR is set to 0
    > QCONSOLE =DSP01
    >
    > BUT i dont wont to restrict the QSECOFR access, ONLY this userprofile
    > "BIGUSER".
    >
    > BIGUSER must have the ability to reset the Users-pass and enable any
    > userprofiles.
    >
    > Devices-names (locally and WAN) are randomly generate by system and
    > not defined by me.
    >
    > thanks.


    If your user cannot change the initial program on the signon screen
    then you can setup an initial program for them. Search this group for
    QDCRDEVD, there is a program posted in 2004 which will give you the
    from ip address. If this isnt like eg '172.16.' then its from the
    internet & you can do logoff. It could be your firewall transformed
    the from ip address, you have to check.
    If the user can change the initial program then you can investigate
    telnet exit programs. I'm sure this group has some good examples.

    Jonathan


  5. Re: Sign on restriction?

    il 22/06/2007 12.00, Scrive marsias 36721672:
    >> If the user-profile has *SERVICE or *ALLOBJ special authorities and
    >> sysval QLMTSECOFR is set to '1', then he can logon only by the device
    >> you find in QCONSOLE sysval and devices that he has been explicitly
    >> authorized to with GRTOBJAUT OBJTYPE(*DEVD) AUT(*USE) command.

    >
    > Status are:
    >
    > The user-profile has *allobj and user-class are *secadm
    > QLMTSECOFR is set to 0
    > QCONSOLE =DSP01
    >
    > BUT i dont wont to restrict the QSECOFR access, ONLY this userprofile
    > "BIGUSER".
    >
    > BIGUSER must have the ability to reset the Users-pass and enable any
    > userprofiles.
    >
    > Devices-names (locally and WAN) are randomly generate by system and
    > not defined by me.

    Grant the authority of all devices to QSECOFR, set QLMTSECOFR to '1'
    limit BIGUSER to use only granted devices.
    You can also put a logon-exit program for telnet to check if the user is
    BIGUSER, but it will run anly for telnet virtual devices not for local ws.
    You can put an initial program to BIGUSER that test the device name, but
    it is easly overridden.

    --
    Dr.Ugo Gagliardelli,Modena,ItalyCertifiedUindoscrasherAñe joAlcoolInside
    Spaccamaroni andate a cagare/Spammers not welcome/Spammers vão à merda
    Spamers iros a la mierda/Spamers allez vous faire foutre/Spammers loop
    schijten/Spammers macht Euch vom Acker/Spamerzy wypierdalac'

  6. Re: Sign on restriction?

    If the device names are not explicitly controlled, then it is
    pointless to try to use device names in any decision making. It must be
    assumed that any client can get any device name.
    As was mentioned already, similarly if there is no control over the
    user being able to specify an initial program, then INLPGM is not an
    option.
    Subsystem routing programs resolve the concern for INLPGM. Any
    subsystem into which an interactive device can be allocated, can have a
    routing program that precedes any initial program for a profile. The
    user can be directed according to the device name and/or type and its
    allocation by the expected subsystem. The device name and/or type can
    be associated with specific subsystems. The user can have a job
    description which identifies the RTGDTA [routing data] which identifies
    the routing program.
    However unless such a user is also directed only into a specific
    application by the routing program, that user can subvert any setup.
    ADDWSE identifies the devices and/or types [optional]
    ADDRTGE identifies the routing program and comparison data
    CRTJOBD / CHGJOBD identifies the routing data for the user
    CHGUSRPRF to the specific user to name the created job description
    The routing program can have all of the necessary logic, and simply
    TFRCTL to QCMD when the user signing on is not the

    ADDRTGE SBSD(QINTER) SEQNBR(44) CMPVAL(LMTDEVICE 1)
    PGM(QGPL/LMTUSER) CLS(QGPL/QINTER)
    CRTJOBD JOBD(LMTJOBD) TEXT('restricted devices')
    RTGDTA(LMTDEVICE) RQSDTA(SIGNOFF)
    CHGUSRPRF BIGUSER JOBD(LMTJOBD)

    The SIGNOFF command in the request data ensures that if the limit
    routing is not activated, that if some other routing does not intercept,
    then the user will be signed off; to notify better of the signoff to the
    affected user, it could instead be RQSDTA('?SIGNOFF *LIST')

    marsias wrote:
    >> If the user-profile has *SERVICE or *ALLOBJ special authorities and
    >> sysval QLMTSECOFR is set to '1', then he can logon only by the device
    >> you find in QCONSOLE sysval and devices that he has been explicitly
    >> authorized to with GRTOBJAUT OBJTYPE(*DEVD) AUT(*USE) command.

    >
    > Status are:
    >
    > The user-profile has *allobj and user-class are *secadm
    > QLMTSECOFR is set to 0
    > QCONSOLE =DSP01
    >
    > BUT i dont wont to restrict the QSECOFR access, ONLY this userprofile
    > "BIGUSER".
    >
    > BIGUSER must have the ability to reset the Users-pass and enable any
    > userprofiles.
    >
    > Devices-names (locally and WAN) are randomly generate by system and
    > not defined by me.
    >
    > thanks.


+ Reply to Thread