Admin Alert: Of Course, Everything I Know About NetServer Could Change
Published: June 13, 2012
by Joe Hertvik
In my last column, I explained why people lose IBM i NetServer access, discussing some common ways to restore NetServer access to a user profile. Little did I realize that I had barely scratched the surface of this topic. Thanks to alert reader Tony Cusack, I learned some new NetServer tricks I didn’t even know existed. Here’s what Tony taught me and how it can help you better manage your NetServer configuration.
In Our Last Episode. . .
Last time, I provided the following information on managing IBM i NetServer user profile access.
- A user’s NetServer access can be disabled the same way their IBM i user profile can be disabled: by entering more invalid sign-on attempts than are allowed in the Maximum Sign-on Attempts Allowed (QMAXSIGN) system value.
- You can restore NetServer access for a user in one of three ways: 1) Stopping and restarting the TCP/IP NetServer server; 2) Re-enabling a NetServer User ID through IBM i Navigator/System i Navigator/iSeries Access Navigator (collectively and lovingly referred to as OpsNav); and 3) Using the Change User Profile (CHGUSRPRF) command.
All of these techniques can be found in last week’s tip. But there’s a lot more to this story, including the fact that one of these techniques will be soon be obsoleted and that there’s a green-screen NetServer configuration menu that you may not know about. Here’s what I learned.
Bye, Bye, CHGUSRPRF For NetServer Re-Enablement
No sooner had I documented the time honored way of re-enabling NetServer access by using the CHGUSRPRF command to change any parameter on the user profile, when Tony Cusack wrote in to tell me that IBM is taking this capability away. Here’s the story as I know it.
In the current IBM i NetServer design, anything that changes the last modified date for a user profile will re-enable IBM i NetServer access for that profile. This is why after you change almost anything on a user profile, that user’s NetServer access will be reset, even if it was disabled. But there’s a problem with this technique, as IBM astutely noted the following in APAR MA42015:
The method of using the Change User Profile (CHGUSRPRF) command to re-enable IBM i NetServer users does not provide a well-controlled interface for ensuring that NetServer users are only re-enabled by a systems administrator.
And Big Blue has a point here. Notwithstanding that IBM i administrators have been using this technique for NetServer re-enablement since NetServer was first introduced, using CHGUSRPRF to re-enable NetServer access is a pretty insecure and weak way to reset access.
Because of this, IBM recently took away the CHGUSRPRF option for NetServer re-enablement. It is doing this by releasing the following PTFs for each supported operating system.
- i5/OS V5R4M0: MF55657
- i5/OS V5R4M5: MF55658
- i 6.1.0: MF55659
- i 6.1.1: MF55660
- i 7.1.0: MF55661
Installing any of these PTFs on your system will remove the ability to use CHGUSRPRF to re-enable a user for NetServer access. The projected release date for these PTFs was May 25, 2012, which means they are available right now. So the next time you load up a cumulative PTF package, you may be inadvertently preventing the Change User Profile command from re-enabling NetServer access for a particular user.
You can read more about these PTFs and IBM’s RSTNETUSRP command for re-enabling NetServer access by reading IBM Software Technical Document 633149683, CL Program and Command to Re-Enable NetServer Users.
So How Do I Replace CHGUSRPRF For NetServer Re-Enablement?
To provide a native green-screen interface for working with IBM i NetServer, IBM delivers the GO NETS menu in i5/OS V5R4M5, as well as in the i 6.1 and i 7.1 operating systems. The NETS menu provides green-screen options for working with and configuring the NetServer server; adding, changing, and removing file and printer shares, and for re-enabling user profile access to NetServer.
IBM delivers the NetServer menu (GO NETS) inside the QUSRTOOL library, where it can be installed into the NETSRVCMD library where it resides. You can check and see if the NETS menu is installed on your system by using the following command.
If NETS is present on your system, you’ll see a NETS menu object (*MENU) and a NETS message file object (*MSGF) installed on the system. If they aren’t present, you’ll have to install the NETSRVCMD library from QUSRTOOL before you can use the NETS menu. IBM provides installation instructions for creating the NETSRVCMD library and for installing the GO NETS command and other green-screen NetServer utilities on the IBM i NetServer GO NETS command screen tool website. After using the commands on this website, the NETS menu will be installed and ready to use. Simply add the NETSRVCMD library to your library list and run the following Go to Menu (GO) command.
As shown here, the NETS menu contains 15 different options for working with the NetServer server and its file and print shares, sessions, and for re-enabling NetServer users.
(Click graphic to enlarge.)
Option 12, Work with NetServer Users, provides a green-screen interface for re-enabling users for NetServer access. Its menu screen looks like this:
(Click graphic to enlarge.)
From here, all you have to do to re-enable a user for NetServer access is place a “7=Enable” in front of the user profile you want to re-enable for NetServer access and press Enter. This is a lot easier to use and understand than using the CHGUSRPRF command to make changes to a disabled NetServer user profile.
Again, thanks to Tony Cusack for cluing me in to IBM eliminating the CHGUSRPRF option and for showing me how and where to find the GO NETS menu.
Other NetServer Access Solutions
Another reader also wrote in to ask me about using NetServer to create file shares to the Document Library Services (QDLS) file system on the IBM i. Specifically, the reader was having two problems with creating QDLS NetServer shares pointing to QDLS folders.
- In order to map a NetServer file share to a QDLS folder, the user had to be registered in the IBM i System Distribution Directory (SDD). Users can be registered in the SDD by using the Work with Directory Entries (WRKDIRE) command.
- The reader was having problems trying to map multiple shares, where one share pointed to a QDLS folder and another share pointer to a folder that resided off the root directory (‘/’) of the IFS. According to this reader, IBM does not allow you to map a QDLS folder NetServer share and any other IFS-based NetServer share at the same time.
To help my reader solve his IBM i NetServer technical issue, I referred him to IBM Software Technical Document 25851028, IBM i5 NetServer Debug Checklist for ‘Access Denied Errors’. This document answered the reader’s question about whether the user needed to be enrolled in the Systems Distribution Directory (SDD) to map a NetServer QDLS-based file share (yes, he does). It also contains 10 other tricks for diagnosing and solving NetServer problems, so I’d recommend reading it if you’re experiencing problems with your NetServer connection.
However, as of press time, I couldn’t find any references to IBM not allowing you to map multiple file shares to QDLS and other IFS folders. If anyone has any more information on this limitation, please email me and I may use that information in a future column.
Follow Me At My Blog, On Twitter, And On LinkedIn
Come check out my blog at joehertvik.com, where he focuses on computer administration and news (especially IBM i); vendor, marketing, and tech writing news and materials; and whatever else he come across.
Joe Hertvik is the owner of Hertvik Business Services, a service company that provides written marketing content and presentation services for the computer industry, including white papers, case studies, and other marketing material. Email Joe for a free quote for any upcoming projects. He also runs a data center for two companies outside Chicago. Joe is a contributing editor for IT Jungle and has written the Admin Alert column since 2002.