| TechTip: Change the User Profile for the Currently Running Job |
 |
 |
 |
| Tips & Techniques - Security | |||||||||||||||
| Written by Thomas Snyder | |||||||||||||||
| Thursday, 15 January 2009 19:00 | |||||||||||||||
|
With the Get Profile Handle (QSYGETPH) and Set Profile Handle (QWTSETP) APIs, this task is easy.
One common issue to deal with when accessing network drives from the IBM i is authority. When you access a network drive from the IBM i, as discussed in previous TechTips, the user profile that is assigned to the job is the user that is being authenticated on the Windows server. One way to resolve this is to synchronize the passwords between the IBM i and Windows, but this will reduce your password protection to the level of the Windows server, because once someone cracks the Windows password protection, they now have the IBM i user name and password.
In this TechTip, I will show you how to change the active user profile for the currently running job. This technique will allow you to set up one user profile--with minimal access to the IBM i--that maintains a synchronized user ID and password with the Windows server. Then you can simply switch over to the specially designated Windows liaison to execute the Windows operations. After you're done with the Windows operations, you can switch back to the original user profile.
I have created a user profile named IBMUSER as my Windows liaison. This will make it easy for the Windows administrators to identify the account on the network. I set up this account to have minimal access to the IBM i; that way, if the Windows passwords are compromised, the potential security exposure on the IBM i is minimized.
To change the user associated with a job, you can use a combination of the Get Profile Handle (QSYGETPH) and Set Profile Handle (QWTSETP) APIs.
The QSYGETPH API validates a user name and password and generates a 12-character handle. This handle is a randomly generated value that is valid only for the currently running job.
The QWTSETP API changes the current thread to run under the user profile specified by the handle. Note that I said "thread" not "job." But you cannot have multiple threads in RPG yet, so if you're only using CL and RPG programs, then you can think of it as being for the job. Once you set the profile handle to be a user profile other than the original user profile, it will remain active until the job ends or until you change it to another profile handle.
QWTSETP doesn't change the user association with the job, so after you execute the command, you would expect WRKACTJOB to show the new user profile name on the workstation, but it does not. And it does not even change the "Current User Profile" or the "Job User Identity" when you display the job status attributes.
During my initial test run, I was stepping through the program in the debugger to the QWTSETP program execution, finding that there were no errors, and performing a system request, expecting the user value to change, but it did not. So I was driving myself crazy trying to get this to work, and I didn't even realize that it was already working! Let me help you avoid that frustration with a simple code sample and a clear explanation of the changes that occur when the program is executed. The CodeHere is the code to change the user profile.
D********************************************************************** D* CHANGE THE CURRENT USER PROFILE D* USING HARD CODED USERNAME D********************************************************************** D NEWUSER S 10A D NEWPASSWORD S 10A D NEWHANDLE S 12A D* QUSEC IS THE COMMON ERROR CODE PARAMETER PROVIDED BY IBM D* THAT YOU CAN FIND IN QSYSINC/QRPGLESRC,QUSEC D* OUTERROR WAS ADDED TO RECEIVE EXCEPTION DATA D QUSEC DS D QUSBPRV 1 4B 0 D QUSBAVL 5 8B 0 D QUSEI 9 15 D QUSERVED 16 16 D OUTERROR 17 1040 D* C/EJECT C* FOR SECURITY LEVEL 10 SYSTEMS, THE PASSWORD IS NOT REQUIRED. C EVAL NEWUSER = 'IBMUSER' C EVAL NEWPASSWORD = '*NOPWD ' C EVAL QUSBPRV = 1040 C* C CALL 'QSYGETPH' C PARM NEWUSER C PARM NEWPASSWORD C PARM NEWHANDLE C PARM QUSEC C* C IF QUSBAVL > 0 C* ERROR C ELSE C CALL 'QWTSETP' C PARM NEWHANDLE C PARM QUSEC C IF QUSBAVL > 0 C* ERROR C ELSE C* SUCCESSFULLY CHANGED PROFILE HANDLE C ENDIF C ENDIF C* C EVAL *INLR = *ON
If you were to run this code and verify that no errors were found, you may not initially see that anything changed. Now, go ahead and execute the WRKSPLF command with no parameters. You will see all of the spool files listed for IBMUSER, not the user that you signed on as. Or call a program that generates a spool file and you will see IBMUSER specified as the user. Or copy a file in the IFS and you will see the new object owner is IBMUSER.
You may not be familiar with the QSYSINC/QRPGLESRC,QUSEC in the copy statement. This is not something that you have to install yourself; it's already there with i5/OS. This IBM-provided code contains the standard error code parameter. This error code parameter information is populated and returned when the QSYGETPH and QWTSETP commands are executed.
The QUSBAVL value is contained in QUSEC and is used to determine if the command was successful. A good way to troubleshoot failures is by checking the QUSEI value from the QUSEC error code parameter. The hypertext links above for QSYGETPH and QWTSETP provide a list of potential QUSEI values.
The OUTERROR field is an additional field that was added to the data structure that is defined in the QSYSINC/QRPGLESRC,QUSEC file to receive exception data. The QUSBPRV field should be initialized to the length of the QUSEC data structure, including the OUTERROR field. If this size is not set, you could end up receiving a large amount of data in the error code parameter and produce undesired results. Restoring the Original User ProfileOnce you set the profile handle to a different user profile, this user profile will remain active until the job is completed. This is undesirable; otherwise, you would have just signed on as that user profile in the first place. So you will most likely want to set the user profile back to the original user profile after you are done with the task for the profile change.
For the previous code sample, I passed the special password value of *NOPWD, which is acceptable for security level 10 systems. But for systems not using security level 10, you will have to specify the password. As of V5R3, if you specify the password, you must also provide the password length and CCSID. Prior to V5R3, the password length and CCSID were optional. You must remember to put the correct value in the password length field; otherwise, the QSYGETPH call will fail.
The following code example will...
D********************************************************************** D* SAVE CURRENT PROFILE HANDLE D* SET NEW PROFILE HANDLE D* ACCESS A SERVER WITH THE NEW PROFILE D* RESTORE THE ORIGINAL PROFILE D********************************************************************** D CURUSER S 10A &nbs | |||||||||||||||
View all articles by this author
|
|||||||||||||||
You must be logged in to view or make comments on this article