Need to prevent user from creating more than one client access Workstation icon on a PC.

1,160 pts.
Tags:
AS/400
Client Access
iSeries AS/400
vb macros
workstation
Is it possible to prevent a user from installing more than once client access workstation session on a pc.

The need has risen from our need to prevent users from using VB macros, while we are able to prevent user from running macros from an existing workstation session, we are unable to prevent him from creating a fresh client access workstation session, which when created enables to user to run VB macros.



Software/Hardware used:
os400, client access, iseries access for windows
ASKED: May 14, 2010  10:18 AM
UPDATED: June 17, 2010  8:36 PM

Answer Wiki

Thanks. We'll let you know when a new response is added.

What about using the user profile to control how maney times they can sign.
If you do CHGUSRPRFand change Limit device sessions . . . . . . . . . . : *YES.
will this help.

NO Missing a lot of information about your security model but …

Can you limit concurrent sessions per machine by IP or MAC address?

The other option I can think of is restricting CL access to help circumvent the second session.

Discuss This Question: 17  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    If you need to stop iSeries Access workstation sessions, do you also need to stop Windows telnet sessions? What can be done with VB macros under iSeries Access that can't be done (by different VB functions) against other kinds of clients? Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Tom, I need only to stop creation of additional iseries Access workstation sessions on the client on which already one valid session has been created. No issues related to windows telnet session. Iam currently looking only at iseries access clients.
    1,160 pointsBadges:
    report
  • JohnsonMumbai
    Tom, Also need to know if this can be controlled centrally on Iseries server, ie running of VB macros on iseries access client.
    1,160 pointsBadges:
    report
  • hafwhit
    I am no expert in security but it sounds like you need to make some changes to your system values. It also sounds like you need to control the user profiles and reduce the authority each user has. I am sure that someone with more knowledge in that area could assist you.
    1,145 pointsBadges:
    report
  • TomLiotta
    Also need to know if this can be controlled centrally on Iseries server, ie running of VB macros on iseries access client. I see how this could be controlled effectively from the iSeries. The iSeries has no knowledge of VB macros nor anything else about VB. From the iSeries, you could most easily simply restrict users to having a single active interactive session. That would simply be a routing program in your interactive subsystem that listed the current jobs for the user to see if an interactive job already existed. You could have the routing program check a file to see which users are allowed to start more than one session. Doing it that way, it wouldn't matter what emulator was used nor if VB macros were involved or not. And the iSeries would be in control. No need to do anything to any user's PC. Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    Correction -- "I don't see how this could be controlled effectively from the iSeries." Tom
    125,585 pointsBadges:
    report
  • slateken
    System value QAUTOCFG may help you control this. Being careful of course that this method will not adversely affect anything else in your organization.... : System value QAUTOCFG is ALWAYS OFF (0). The security officer will temporarily turn on autoconfig when the network guru is creating a new session for a user. The techie names this session, for example, "WS131". When the session is saved and an icon is added to their desktop, the session is now ready to use. It will always run as WS131. Next, Mr. Security Officer sets off QAUTOCFG. Mr. Pesky Conniving User can now TRY to create a new client access session, but alas, will not be able to connect ...
    230 pointsBadges:
    report
  • TomLiotta
    Mr. Pesky Conniving User can now TRY to create a new client access session, but alas, will not be able to connect … Unless, of course, they connect to WS130 or WS129 or any of the other devices that already exist. Not only do system values such as QAUTOCFG need to be disabled, but a security structure needs to be implemented and managed to assign and control authorities for all of the various *DEVDs (and device *MSGQs) that probably already exist so that each user can use only appropriate devices. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    Hi Tom, The objective is to prevent users from creating another workstation on his pc as earlier workstation parameters are saved and we do not want user to have fresh set of workstation with default parameters as parameters such as within API section to be would get modified. Hope you have understood. Johnson
    1,160 pointsBadges:
    report
  • TomLiotta
    ...fresh set of workstation with default parameters... Can you describe the parameters that you need to control? There are two general possible directions. First, you can try to prevent the creation of new workstation sessions on the PC. I don't have a good idea how that might be done. But second, you might be able to control whether or not a new workstation session can be used on your AS/400. The example from Slateken about QAUTOCFG is one potential idea along that line, but there might be other thoughts that are more useful and more precise. It's possible that the parameters you want to protect will give a clue. Even if new sessions are created, maybe they can't be used. That might be a sufficient resolution to your problem. Different parameters might cause a different workstation type -- you might be able to reject those when they try to connect. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    1,160 pointsBadges:
    report
  • djac
    How are these additional session file being created? If it is through the 'Start -> Programs -> IBM iSeries Access for Windows' method, then remove that menu option and rename the programs that run behind the 'Emulator -> Multiple sessions' and 'Emulator -> Start or Configure Sessions' options. The users should still have access to data transfer etc. through the buttons on theClient Access menu bar....
    900 pointsBadges:
    report
  • TomLiotta
    ...remove that menu option and rename the programs that run behind the ‘Emulator -> Multiple sessions’ and ‘Emulator -> Start or Configure Sessions’ options. That prevents them from running menu options. It doesn't prevent them from simply using copy/paste for a .WS file and making any changes they want to the copy. Notepad is all that's needed. However -- "Defense in depth." It might be worthwhile just to increase the obstacles by an extra layer. In a sense, the problem becomes one of having the clever user digging deeper to learn more. It's not unheard of to have users be more knowledgeable than AS/400 administrators about Windows. Tom
    125,585 pointsBadges:
    report
  • JohnsonMumbai
    The workstations are being created using pcsws.exe file which is called the windows Start and Run commands. Johnson
    1,160 pointsBadges:
    report
  • djac
    Given the various loopholes that have pointed out, I am wondering if the only way to try an resolve this is to make it a disciplinary issue? Get it formally agreed that it is policy that ALL access to the system is ONLY via the provided desktop icon. Any staff not complying can be subjected to your company's normal disciplinary procedure - informal warning - written formal warning - sanctions including dismissal, however it goes. Sounds a bit harsh? maybe, but it would focus the users' minds!
    900 pointsBadges:
    report
  • Bigmac46
    Assign the user a specific wrkstation name like WS101 . create a CLLE and have the user profile changed to have this as initial program for user. In it check workstation and IP address . iF NOT AS EXPECTED DO NOT ALLOW TO SIGNON. IF OK continue to what would have been the initial signon program before. IF user has more than 1 signon do same for all..
    1,000 pointsBadges:
    report
  • TomLiotta
    Assign the user a specific wrkstation name like WS101 . This is an example of where I was going with the suggestion that new sessions (*DEVDs) might be restricted from use on the AS/400. It might not matter if new .WS files are created if the they result in *DEVDs that can't be used. Note, however, that restricting a user to a particular *DEVD has no effect on whether the associated .WS might allow VB macros, which was the point of the question. You can have any number of .WS files that all attach to the same *DEVD. Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following