IBM i5/OS NetServer Security

Resolving The Problem

This document provides information on IBM i5/OS NetServer Security. It also outlines security considerations when administering the IBM i5/OS NetServer. Topics covered in this document include the following:

o	User Login
o	User Profiles Disabled for i5/OS NetServer
o	Guest Support
o	User Profile/Password Considerations
o	i5/OS NetServer Share Authority
o	Debugging Access Denied Messages
o	Hidden Shares
o	Preventing i5/OS NetServer from Being Visible in Microsoft Windows Network Neighborhood
o	Viewing Users and PCs Connected to i5/OS NetServer
o	Kerberos V5 Authentication
o	i5/OS NetServer Informational Messaging
o	User Exit Programs

Proper configuration and authorities help ensure that no security exposures exist when using the i5/OS NetServer.

NetServer follows the operating system security model. Therefore, all user rights and permission that are applicable to the operating system are also applicable to the NetServer. The operating system object authorities should always be implemented as a first step, and this is the preferred method of ensuring adequate security.

Note: *IOSYSCFG special authority is required to configure i5/OS NetServer properties and to create or change NetServer shares. *SECADM special authority is required to configure GUEST profile support.

User Login

Networking functions on the PC (such as the Client for Microsoft Networks) are used to map a network drive or printer to i5/OS NetServer. Windows will attempt to use the Windows network (domain) or the Windows desktop profile and password to log on to NetServer. If the Windows profile matches the IBM i user profile, the passwords will be checked and if the passwords match the connection will be made.

If the profiles do not match, NetServer will prompt the user to enter a user profile and password, unless GUEST support is enabled in the i5/OS NetServer properties. If the profiles do not match, and GUEST support is enabled, then the connection will be made using the profile that is configured as the NetServer GUEST.

Note: See the section GUEST Support below for security implications of enabling GUEST support.

The following table illustrates various log on scenarios that may be encountered:

Profile Exists on Operating System?	Password Correct	Guest Enabled?	Result
Yes	Yes	Yes or No	Access granted using Windows Network Login ID
Yes	No	Yes	Login prompt received for Password and Profile
No	N/A	No	Login prompt received for Password and Profile
No	N/A	Yes	Access granted using Guest

Users can verify the user name/profile they are logged into Windows with by issuing the following from a Microsoft MS-DOS command prompt:

Net Config Workstation or Net Config Server

User Profiles Disabled for i5/OS NetServer

i5/OS NetServer limits the number of sign on attempts based on the system value QMAXSIGN. When accessing NetServer, the Windows Networking Client will make repeated attempts to log on (under the covers) if the initial authorization fails. This can disable the user profile for NetServer access before ever prompting the user for login information. A user profile can be disabled for NetServer use while other functions (such as emulation session sign-on) are not effected. If the profile is displayed (WRKUSRPRF) it will still show as *ENABLED, but still can not be used to log into NetServer. Setting the QMAXSIGN system value to 5 or higher will usually (but not always) prevent a profile from being accidentally disabled for NetServer use.

Note: Changes to the QMAXSIGN system value will not have any effect on the NetServer until after the NetServer has been restarted.

When a user profile is disabled for i5/OS NetServer, QSYSOPR message queue will log message CPIB682 - User profile &1 disabled for IBM i Support for Windows Network Neighborhood access. The message will also contain the IP address of the PC that the request (that caused the disablement) came from. Prior to the application of PTFs that make the change documented in APAR MA42015 , the CHGUSRPRF command could be used on the disabled user profile (no additional parameters required) to re-enable it. That is no longer the case, once the applicable PTF is applied.

The following PTFs for NetServer remove the ability of the CHGUSRPRF command to reset, or re-enable, a user that is disabled for NetServer access. To review APAR MA42015 , click here.

540: MF55657 (not included on any Cumulative PTF Package)
545: MF55658 (not included on any Cumulative PTF Package)
610: MF55659 (on Cumulative PTF Package 2305)
611: MF55660 (on Cumulative PTF Package 2305)
710: MF55661 (on Cumulative PTF Package 2279)

All of the above PTFs became available in May 2012.

After applying one of the PTFs above, individual users can be re-enabled by using System i Navigator or Navigator for i, using the GO NETS menu, or writing a program that makes use of the QZLSCHSI API.

Note: Use of the QZLSCHSI API requires that you have *IOSYSCFG special authority. To use format ZLSS0200 to enable an IBM i NetServer user, you must also have *SECADM special authority and *OBJMGT and *USE authority to the system user profile. The QZLSCHSI API is documented in the V7R1M0 Knowledge Center. Click HERE to go to the Knowledge Center documentation now.

Disabled NetServer profiles can be viewed and enabled from System i Navigator. Open Navigator, expand My Connections, expand the IBM i connection, expand Network, expand Servers, and select TCP/IP. In the list of TCP servers, right-click on i5/OS NetServer and select Disabled User IDs. Use the option to Enable User ID if it has been disabled.

In Navigator for i, expand Network, expand Servers, and select TCP/IP Servers. In the list of TCP servers, right click on IBM i NetServer and select Disabled User IDs. Use the option to Enable User ID if it has been disabled.

The GO NETS menu option to Work with NetServer Users can also be used to re-enable individual profiles that have been disabled for NetServer use. GO NETS is shipped with current i5 OS versions, but is not configured for use. Directions for configuring GO NETS is available online at http://www-03.ibm.com/systems/power/software/i/netserver/gonets.html .

IBM Technote N1010992 CL Program and Command to Re-enable NetServer Users contains a sample 'as-is' CL program that uses the QZLSCHSI API to re-enable NetServer users. It is available in the iGSC (IBM i Global Support Center) Public Knowledgebase.

Notes:

1.	All options that are discussed here, to enable profiles for NetServer, do make use of the QZLSCHSI API, so all requirements in the previous note do apply to use of these options as well.
2.	All profiles are re-enabled for i5/OS NetServer use when NetServer is restarted. This can be done from the System i Navigator screen or by running the ENDTCPSVR *NETSVR command, followed by the STRTCPSVR *NETSVR command. All profiles are also re-enabled for NetServer use when the IBM i system is IPLed.

DSPLOG MSGID(CPIB682) is the operating system command that can be used to obtain a list of profiles that have been disabled for NetServer use. This command returns a list of all profiles that have been disabled during the time frame of the current QHST history file. Message CPIB682 is also posted to the QSYSOPR message queue and can be seen by using the DSPMSG QSYSOPR command; however, it is posted only one time (at the time the profile initially becomes disabled for NetServer). Therefore, it might be difficult to locate the message in QSYSOPR message queue if time has passed since the profile was disabled. This makes DSPLOG MSGID(CPIB682) the preferred command line method.

Notes:

1.	Changes to the system value QMAXSIGN do not take effect for i5/OS NetServer users until the server is started again. It is also recommended that the QMAXSIGN system value not be set to *NOMAX.
2.	Prior to the application of a PTF that makes the changes described in APAR MA42015, any action that updates the last access date on the user profile will cause the NetServer profile to be re-enabled if it has become disabled. CHGUSRPRF is the most commonly recognized action that updates the last access date, but there are other things that update the last access date as well. After application of the PTF, updating the last access date will no longer re-enable the profile for NetServer use.
3.	When a profile is disabled for NetServer use, DSPUSRPRF will still show the profile as being *ENABLED and the profile can be used for signing on to any function other then i5/OS NetServer.
4.	Refer to IBM Technote N1018914 NetServer Disabled User ID List Clarified for additional information about profiles disabled for NetServer use.

GUEST Support

NetServer supports the use of GUEST (or anonymous) profiles. This enables users of Windows workstations who do not have a valid IBM i profile to access the NetServer shares. If GUEST is enabled and the Windows login does not match a valid profile on the IBM i server, NetServer logs the user in as the profile that was configured as the NetServer GUEST.

To use GUEST support with Printer shares, the GUEST profile must have a password. In addition, it is recommended that GUEST profile have the initial menu set to *SIGNOFF to prevent unauthorized access to an operating system command line interface. Also, GUEST profiles are not allowed to have any special authorities.

For additional information on configuring a Guest user profile, refer to IBM Technote N1016971 Configuring AS/400 NetServer to Use a Guest Profile.

Caution: Enabling a guest profile should be carefully considered as it allows any user without a valid operating system profile to access i5/OS NetServer and any unsecured shares.

User Profile/Password Considerations

Normal operating system user profiles and passwords apply to the i5/OS NetServer with some additional considerations:

Profile/Password Length: By default operating system profile and password lengths are limited to 10 characters. A Password Level (QPWDLVL) system value exists, which can be set to enable long password support. See the help text for QPWDLVL for additional details on the available settings. From the IBM i Command line, run DSPSYSVAL QPWDLVL, then (on the resulting screen) put the cursor on the word QPWDLVL and press <F1> to view help text.

With all currently supported OS/400 versions, when using QPWDLVL 0, user names longer than 10 characters are truncated to 10 characters and the resulting version (of the user name) is used if it exists on the IBM i. For example, user Administrator will be truncated to ADMINISTRA and, if a user profile called ADMINISTRA exists on the IBM i, that user profile will be used for the connection. If the truncated version of the user name does not exist on the IBM i, GUEST support will be used if it is enabled.

Current OS/400 versions enable Windows NT challenge/response version 2 (NTLMv2) authentication. NTLMv2 passwords are case sensitive. Windows NT, 2000, XP (and above) clients use NTLMv2. With QPWDLVL 0 or 1, by default, passwords must be entered in all uppercase or all lowercase if using NT, 2000, XP, or above to make a NetServer connection. However, NetServer can be configured to allow the use of LANMAN (Lan Manager) Authentication so long as the Windows Client is capable of also using LANMAN Authentication (every version of Windows prior to Windows 7 and Windows Server 2008 is capable of using LANMAN). Using LANMAN will allow the use of mixed case passwords when using QPWDLVL 0.

Notes:

1.	Windows 7, Windows Server 2008, and above, can not use LANMAN authentication. This is a Windows restriction. As a result, if the IBM i is set to use QPWDLVL 0, then these clients must send an all upper case or all lower case password in able to connect to the IBM i NetServer.
2.	NetServer does not, and never has, accepted a LANMANv2 password. Although Windows 7 can use LANMANv2, this will not enable Windows 7 to map a NetServer network drive using a mixed case password. NetServer provides no support for LANMANv2.

For additional information, refer to IBM Technote N1017262 Mixed-Case Passwords Fail with IBM AS/400 NetServer and IBM iSeries NetServer at QPWDLVL 0,1.

Caution: Before making any changes to the QPWDLVL system value, refer to Chapter 7, Considerations for changing QPWDLVL from 0 or 1 to 2 of the Security Reference manual. To view the V5R4 iSeries Security Reference pdf, go to the following Web site: http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/books/sc415302.pdf or visit the Security Section of the IBM i Knowledge Center at http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp?topic=/rzahg/rzahgsecref.htm To view the V6R1 iSeries Security Reference pdf, go to the following Web site: http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzarl/sc415302.pdf or visit the Security Section of the IBM i Knowledge Center at http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/rzahg/rzahgicsecurity.htm To view the V7R1 iSeries Security Reference pdf, go to the following Web site: http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/rzarl/sc415302.pdf or visit the Security Section of the IBM i Knowledge Center at http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/index.jsp?topic=%2Frzarl%2Frzarlkickoff.htm To view the V7R2 iSeries Security Reference information, visit the Security Reference Section of the IBM i Knowledge Center at http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rzarl/rzarlkickoff.htm?lang=en The system-wide impacts of changing the password level must be considered before making any changes to QPWDLVL. If QPWDLVL 2 or 3 is used, older (unsupported) Client Access Express clients, if still in use, will not be able to connect. It is not possible to provide a complete list of possible impacts. Any program that allows remote sign-ons or remote authentication to occur (using passwords or password substitutes) must be checked to see if it is able to access a system running at QPWDLVL 2 or 3. It is not always obvious that a product includes sign-on/authentication functions. The product may try to make this transparent for ease of use. Older IBM products, non-IBM products, and user-written applications should all be checked. In addition, if multiple IBM i systems must communicate with each other, it is likely that all of these IBM i systems must be using the same QPWDLVL level.

Numeric Passwords: A profile can be created with a numeric password on operating system by specifying Q as the first character (for example, Q12345). The user can then login with 12345 as the password on the sign-on display. This works because the operating system precedes the password with the letter Q. Windows does not precede the password with the letter Q; therefore, a numeric password fails. It is, therefore, recommended that passwords begin with an alphabetic character, although it might be possible to connect with a numeric password by manually preceding it with the letter Q.

i5/OS NetServer Share Authority

i5/OS NetServer share permissions for a user will be the same as the Integrated File System directory authority for the user. Changing the permission on the share changes the Integrated File System authority to the last directory in the share path. To view the permissions on a share, open System i Navigator, expand the IBM i Connection name, expand Network, expand Servers, double-click TCP/IP and, when the list of servers displays, double-click i5/OS NetServer to open it. Expand Shared Objects and right-click on the share name to select Permissions. This will display the permissions of the last level directory in the share path. For example: A share named MYSHARE has a share path of /Home/Some-Department/MYSHARE. Viewing the permissions of the MYSHARE share will display permissions for the MYSHARE directory. It will not display permissions of the Some-Department or Home directories. Permissions on these levels can not be viewed by taking the step to view share permissions.

In addition to permissions, each share will also have a separate read/write access property. By default, NetServer shares are created as read only. Unless the access property for the share is changed to Read/Write, users who try to create or copy a file into the share will receive an Access Denied message. If the user has OS/400 or i5/OS read/write authority to an Integrated File System directory but the share is configured as read only, they will only have read authority to the directory through the NetServer share.

To change the Read/Write property on the NetServer Share, from System i Navigator expand the IBM i family name, expand Network, expand Servers, double-click TCP/IP and, when the list of servers displays, double-click i5/OS NetServer to open it. Expand Shared objects and right-click on the share name, and then select Properties. Change Access to Read/Write. The change will take effect immediately.

Note: For more information on Integrated File System authority, refer to the 710 Knowledge Center documentation on Planning Integrated File System Security.

Debugging 'Access Denied' Messages

For possible causes of Access Denied messages, refer to IBM Technote N1019406 NetServer Debug of Access Denied Messages.

Hidden Shares

Shares may be hidden by placing a $ at the end of the share name. This will prevent them from being visible in Windows Network Neighborhood. Users can still map to hidden shares by specifying the name of the share in the path, including the $. Though these shares are not visible in Network Neighborhood, there are environments where they are visible such as when using the Linux Samba client. They are also visible when viewing the share lists in System i Navigator.

Preventing i5/OS NetServer from Being Visible in Network Neighborhood

i5/OS NetServer may be hidden from Windows Network Neighborhood by setting the browse announcement interval to 0 in the NetServer properties. This prevents it from announcing itself to the network. It is still possible to locate NetServer by name and to map drives using the NetServer name, but it is not shown in Windows Network Neighborhood.

Viewing Users and PCs Connected to i5/OS NetServer

System i Navigator will display all active NetServer sessions along with the name of the PC connected, the user profile connected, and the type of user (USER or GUEST). Open Navigator, expand My Connections, expand the IBM i connection, expand Network, expand Servers, and select TCP/IP. In the list of TCP servers, double-click on i5/OS NetServer. When NetServer opens, expand Sessions and the connection information is displayed on the right. Double-clicking on any session to open it will display the share names that the user is accessing.

Kerberos V5 Authentication

NetServer supports using Kerberos Version 5 for user authentication from Windows 2000/XP (and above) clients. To enable this support, the following products are required: System i Navigator Security option, Network authentication service, Enterprise Identity Mapping (EIM), and the Cryptographic Access Provider (5722-AC2 or AC3). For more information, refer to the 'System i Networking IBM i NetServer' manual, available in PDF format at:

http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzahl/rzahl.pdf

i5/OS NetServer Informational Messaging

i5/OS NetServer can automatically send network informational messages to users in the form of Windows pop-up messages. These messages can alert you to specific connection issues such as:

o	The user profile does not exist
o	The user profile is disabled
o	The user is disabled for i5/OS NetServer access
o	The user has been enabled for i5/OS NetServer access
o	The password is expired
o	The user profile does not have a password
o	The user's password will expire in X days
o	There was a Kerberos authentication failure

To enable i5/OS NetServer Informational Messaging, change the Message logging severity level for the QSYS/QZLSSERVER job description to 20, and restart NetServer. Linux can also be configured to receive these messages.

Directions for disabling i5/OS NetServer Informational Messaging are included in IBM Technote: N1014962 Working with iSeries NetServer Message CPIB691 and Windows Messaging Service When Using i5/OS V5R4.


User Exit Programs

User exit programs can be used to control access to many IBM i servers including the NetServer. These programs can be written in house or purchased from a vendor. The QIBM_QPWFS_FILE_SERV exit point is used for NetServer file share access. For additional information on writing exit programs and for a layout of the QIBM_QPWFS_FILE_SERV exit point, refer to Using Server Exit Programs in the iSeries Knowledge Center. Use the WRKREGINF command to check for any existing exit programs on the QIBM_QPWFS_FILE_SERV exit point. If a user is denied access to NetServer due to an exit program, the QZLSFILE joblog for the user will contain the following message: CPFAD0E - An exit program is preventing the user from accessing the share.

To locate the QZLSFILE job, run the WRKOBJLCK OBJ(user profile) OBJTYPE(*USRPRF) command. Select Option 5=Work with Job and Option 10, Display joblog.

Notes:

1.	When the QZLSFILET (thread capable) NetServer prestart job will be used to access NetServer, then the Exit program must be threadsafe and must be registered as such.
2.	The QSERVER subsystem must be ended and restarted after making a change related to the File Server Exit point (QIBM_QPWFS_FILE_SERV). This includes any change to the exit program or any change to the exit program registration.

Additional Notes - added for searchability:

1.	The name i5/OS NetServer may be used interchangeably with IBM i NetServer, iSeries NetServer, OS/400 NetServer, or (older) AS/400 NetServer or AS400 NetServer.
2.	This document replaces older Knowledgebase document 17714937, IBM iSeries NetServer Security. Document 17714937 contains a lot of historical information related to out-of-support OS/400 and Windows versions. That document has been archived (it is no longer publically available). If historical information is needed, you should contact IBM i Support.