This document includes recommended best practices for managing NetServer connections from Microsoft Windows.
Resolving The Problem
IBM i NetServer Support Information
IBM i NetServer is the TCP/IP Application Server on the IBM i that receives and responds to SMB/CIFS protocol requests to provide access to the IFS (Integrated File System) on the IBM i. It is part of the IBM i Operating System. Windows clients do not need to install any additional software in order to access IBM i NetServer. No IBM-provided client software is needed and IBM does not support Windows drive mapping usage problems, Windows security policy configuration, network configuration issues, nor defects in the client software.
The IBM i should be current on the Cumulative PTF package and recommended NetServer fixes applied before requesting defect support. See IBM i Support: Recommended fixes. The Recommended Fixes lists are updated every three weeks (if new PTFs are available or when existing PTFs have been included in a new Cumulative PTF package).
IBM i NetServer Share Access with Password Authentication
QPWDLVL System Value
If password authentication is used, consider changing the QPWDLVL system value from 0 or 1 to 3, if it appears possible in your network, after thoroughly investigating the implications. The case-insensitive passwords used with QPWDLVL 0 or 1 are not as secure as the complex passwords used with QPWDLVL 2 and 3, and they are not compatible with the mixed case passwords used with current versions of Windows. See Password Level and (QPWDLVL)Considerations for changing QPWDLVL from 0 to 3
Changing password levels should be planned carefully. Operations with other systems might fail or users might not be able to sign on to the system if the password level change hasn't been planned adequately.
Credentials in the form of domain\user
Because the IBM i user profile is not a Microsoft domain account, the user ID should be qualified with a domain that is not recognized by the Microsoft network. This bypasses domain controller validation and additional domain security checks that are intended for Microsoft domain accounts. When prompted for credentials or when setting the credentials for a mapped drive, use the form of <domain>\<user>.
Mixed case passwords
Mixed case passwords might fail to authenticate with default settings. If the IBM i system value QPWDLVL is set to 0, only LM (LANMAN) authentication will allow a mixed case password and only because the Windows client sends the password as upper case when the LM hash is generated. LM authentication is only supported on versions of Windows prior to Windows 7 and only if the LM compatibility security policy allows it. NetServer does not default to using LM authentication, but It can be enabled using the NetServer properties configuration screen in System i Navigator. To make this change, expand 'My Connections' | Your connection name | Network | Servers and then select TCP/IP. When the list of TCP/IP servers appears, right click on 'i5/OS NetServer' and select Properties from the drop down menu. Go to the Security Tab, click the [Next Start] button, and check the option to 'Allow authentication using LAN Manager password hash'.
Typically, the easiest solution, if LM authentication is not configured (or allowed, by either client or server), is to have users type their password in all lower case or all upper case, not in mixed case. In this situation, when users manually pass a single case password, NetServer will authenticate it with the default settings, even if the user's NETWORK password is mixed case. As mentioned earlier, ensure that the user ID is qualified with a domain not recognized by the Microsoft network.
Case-sensitive NTLM (NT LAN Manager), NTLMv2 (NT LAN Manager version 2), and NTLMSSP (NT LAN Manager Security Support Provider) hashes, with mixed case passwords, are supported and will authenticate with QPWDLVL set to 2 or 3.
Why do only single case work with QPWDLVL set to 0 or 1?
At this password level, NetServer passwords are converted to a case-insensitive hash. With NTLM, NTLMv2, or NTLMSSP authentication, the hash that NetServer uses to compare for authentication matches only the single case version of the password hash that Windows sends, and the Windows hashes of mixed case passwords will not match.
NET USE using Windows Command Prompt
One way to troubleshoot password authentication problems is to use NET USE from the Windows command prompt. There are three valid reasons for doing this:
1. NET USE helps avoid mistakes because it is visible and repeatable (use the up arrow key or the <F3> function key in the command prompt to repeat the previous command).
2. NET USE is a very basic older utility that is simpler than its GUI counterparts and has been known to work when other methods of connecting fail, even when all other variables remain the same.
3. NET USE returns an error code (on failure) that can often help in determining the cause of a failure.
Test authentication without a drive and share first to avoid share and authority issues:
NET USE \\192.168.1.100 /USER:192.168.1.100\IBMiUSRPRF IBMiPWD
To map a share to a drive letter use :
NET USE z: \\192.168.1.100\home /USER:192.168.1.100\IBMiUSRPRF IBMiPWD
Users Disabled for NetServer Use
Note: This is separate from the user profile's status of enabled or disabled. The user ID can be disabled for IBM i NetServer but enabled for character-based interface sign on. User profiles become disabled for IBM i NetServer when NetServer sign on attempts fail the amount of times specified in the system value QMAXSIGN.
The QMAXSIGN system value is read by IBM i NetServer when it is started.
See Options to Display User Profiles That Are Disabled for IBM i NetServer Use
Restarting NetServer or an IPL of the IBM i re-enable all profiles for NetServer use.
In some cases, the profile is disabled for NetServer use every time the Windows system is stopped and restarted. This is because Windows will often send the password multiple times (under the covers) before prompting the user. This can be a problem for persistent mapped drives when the default user ID that Windows attempts to connect with matches an IBM i profile, but the password stored by Windows is incorrect. Some ways to manually store credentials, in order to bypass this, follow:
|1.||Avoid persistent connections by not checking the property to reconnect at login. Then to map the drive at startup and store the domain\userid, place the NET USE statement as described above into a Windows batch script. Omit the password, and Windows will prompt before attempting to authenticate as long as there is no credential stored somewhere else (on Windows or on the network) that matches the domain\userid combination in the NET USE command.|
|2.||Some versions of Windows provide an option for storing credentials for each system on the network Windows XP Professional has an option called Manage my network passwords and Windows 7, and above, have a Credential Manager. Persistent mapped drives will usually authenticate automatically at reboot using these methods, although there is no guarantee that this will always work. In some cases, this works only when the system name being mapped to matches the domain specified in the credential. For example, store 192.168.1.100\qsecofr if mapping to \\192.168.1.100 with qsecofr. Use lower case for the password unless QPWDLVL is 2 or 3. Refer to Microsoft documentation for more information (try doing a Windows 'Help' on 'Manage Passwords' or 'Credential Manager' or search Microsoft's web site).|
Use Network Authentication Instead
Problems with password authentication to NetServer from Windows are very common. Setting up single sign-on with Kerberos authentication does require a substantial initial investment in time, however, it bypasses issues with password authentication and it is virtually maintenance free once it is configured. Refer to How to configure EIM and NAS using IBM Navigator for i
If QDLS access is required, consider disabling the QZLSFILET prestart job, because the QDLS file system is not thread safe and therefore access will be denied for requests to access QDLS using a threaded QZLSFILET session. Refer to document Disabling and Re-Enabling the Use of the Threaded QZLSFILET NetServer Job
Problems with QDLS access can be also be avoided without disabling the QZLFILET job by ensuring that a connection to a share with a path pointing directly to QDLS is established before any QZLSFILET sessions are created.
QDLS access requires the user be listed in the Distribution Directory. Use WRKDIRE/ADDDIRE to list/add users needing QDLS access.
QDLS does not support long names, mixed case, nor embedded blanks in file names. QDLS Supports an 8.3 naming convention only.
Windows Explorer may show incorrect "Created:" date/time property for objects in QDLS. The QDLS physical file system does not store a creation time in the QDLS "directory", which is the *FLR object. A server application that was using the Qp0lReaddir() API to read entries from a QDLS folder would also not see meaningful data in the d_create_time field of a returned directory entry. An alternate code path that does return a meaningful creation time can be forced on the Windows client by creating registry key :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\DirectoryCacheLifetime ...and setting a value of 0.
Opportunistic locking lets clients lock files and locally cache information without the risk of another user changing the file. Although this can provide a performance benefit in some cases, it can decrease performance in others. It has also been known to cause long delays and hangs. Unless there is a clear need to have this set on, consider turning it off in the NetServer properties. See the screen shot below, in the IBM i NetServer Configuration section of this document.
Line Description Settings
Ethernet line description settings for Line Speed and Duplex may limit NetServer performance severely if configured improperly. The Line Speed parameter for a virtual Ethernet adapter can be set to 1G, 100M, or 10M. The Duplex parameter can be set to *AUTO, *FULL, and *HALF. Ensure that the line speed matches the capacity of the card, and that the DUPLEX setting matches that of the switch or router. Typically a DUPLEX setting of *HALF will have a severe negative impact on performance.
Windows WebClient Service
Performance issues have been observed in Windows 7 with a service named WebClient . Users have found improved performance after either toggling the startup between manual and automatic or disabling the service all together. At least one user has reported that if the WebClient is not disabled, it must be active (started) to avoid a negative impact. Refer to Microsoft documentation for more information.
Windows File Indexing
Windows file indexing creates an index for each file pointed to by a share when Windows maps to it. This can be very time-consuming, especially if mapping to a share that points to the root of the IFS. If Windows tries to index root it will parse through all the files on the system including QSYS.LIB and QNTC. Refer to Microsoft documentation for how to disable indexing if mapping to file shares with a large number of files within it.
IBM i NetServer Configuration
NetServer can be configured in the Network component of IBM i Navigator or by using the 5250 Emulation screen GO NETS menu. See Manage IBM i NetServer without Navigator - GO NETS
Recommended NetServer properties settings
Turn guest support off by leaving the guest profile blank unless there is a requirement to give access to users on the network who do not have access to an IBM i user profile and password.
Set authentication method to Passwords/Network Authentication (*PASSKERB) unless there is a need to limit the authentication method to either Kerberos only or to passwords only.
Consider turning opportunistic locking off unless there is a clear need for it.
NetServer supports connection request signing. This provides for more secure communications between the client and server. Signing requests provides improved protection from the following types of attacks: connection hijacking, downgrade attack, rogue server and spoofing by counterfeit servers, active message modification, and replay attacks. Set signing to optional unless the intention is to deny requests from clients that require digital signing. This allows the Windows administrator or domain administrator to set the clients to request signing.
File Sharing Recommendations
There is an inherent danger in sharing the file system root (/) of any system. By doing so, you are relying on every file system permission to be set correctly. What might be prevented by a command restriction on the green screen may not be restricted through NetServer. A client might be able to change or delete vital parts of the operating system.
In addition, by sharing root (/) and opening a path to every file system available on the IBM i, you are exposing NetServer connections to all problems that might be inherent with any particular file system. Some of these file systems, such as QOpenSys, QNTC, and QFileSvr.400, point to locations that are not on the IBM i where the file systems reside. For example, QOpenSys provides access to Unix and Posix based systems on the network, QNTC shares PCs and PC Servers on the network, and QFileSvr.400 provides access to other IBM i systems on the network. Problems with file systems that point to locations outside of the IBM i can not controlled nor corrected by IBM i code, so it is best to restrict unnecessary exposure to these file system. In addition, access to file systems can have a negative effect on performance and can cause NetServer to experience long delays.
The best practice is to "Share only what is needed." By only sharing the specific subdirectory needed by SMB clients, the danger of excessive exposure is drastically reduced. If more than one path is needed, Windows allows access through plenty of mapped drive letters and UNC path names. Also consider whether shares can be set to Read Only versus Read\Write.
For additional information, see Viruses, Malware, Spyware, Ransomware, the IBM i Operating System, and the Integrated File System
Additional Configuration Recommendations
Store the NetServer name in the IBM i host table entry (CFGTCP Option 10), and set the domain search priority to *LOCAL (CFGTCP Option 12) to avoid CPIB683 RC13 when starting NetServer.
The NetServer name must be unique on the network in order for NetServer to start. If NetServer is active on another IBM i or if the name is assumed by something else on the network, NetServer will fail to start with CPIB683 RC5 RC3420 even if the PING command does not find anything for the name.
03 November 2021