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.
Ensure that IBM i is current on the Cumulative PTF package and recommended NetServer fixes before you request defect support. See IBM i Support: Recommended fixes. The Recommended Fixes lists are updated every three weeks (if new PTFs are available or when the PTFs are included in a new Cumulative PTF package).
IBM i NetServer Share Access with Password Authentication
QPWDLVL System Value
If password authentication is used, consider setting the QPWDLVL system value to 2 or 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. 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 must be planned carefully. If the password level change is not adequately planned for, operations with other systems might fail or users might not be able to sign on to the system.
Credentials in the form of domain\user
Because the IBM i user profile is not a Microsoft domain account, qualify the user ID with a domain that is not recognized by the Microsoft network. This bypasses domain controller validation and extra domain security checks that are intended for Microsoft domain accounts. When you are prompted for credentials or when you set 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 allows a mixed case password to be used. The Windows client converts the password to uppercase when the LM hash is generated. LM authentication is normally disabled in Windows. To enable it, a Windows security policy must be modified to allow it. NetServer does not default to using LM authentication, but it can be enabled by using the NetServer properties configuration screen in Navigator for i. To make this change, log in to Navigator for i and double-click the managed node (partition) to view the menu of options for that system. Hover over the network icon to show the menu of options, expand Servers and click 'TCP/IP Servers'.
Right-click 'IBM i NetServer' and select Properties from the menu. Go to the Security Tab, click the 'Expand Next Start' button, and check the option to 'Allow authentication with 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 lowercase or all uppercase, not in mixed case. In this situation, when users manually pass a single case password, NetServer authenticates 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 authenticate with QPWDLVL set to 2 or 3.
Why does 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. If Windows hashes a mixed case password, it does not match.
NET USE from a Windows command prompt
One way to troubleshoot password authentication problems is to use NET USE from the Windows command prompt. There are several reasons for using the NET command:
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 utility that is simpler than its GUI counterparts and it might 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:FAKE\IBMiUSRPRF IBMiPWD
To map a share to a drive letter use :
NET USE z: \\192.168.1.100\home /USER:FAKE\IBMiUSRPRF IBMiPWD
Users Disabled for NetServer Use
Note: Disabled for NetServer 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 number 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 reenables 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 failure happens because Windows often sends the password multiple times (in the background) before it prompts the user. This scenario is frequently 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 prevent this problem, follow:
|1.||Avoid persistent connections by not checking the property to reconnect at login. To map the drive at startup and store the domain\userid, place the NET USE statement as described into a Windows batch script. Omit the password and Windows prompts before you attempt to authenticate when there is no credential stored somewhere else (on Windows or on the network) that match 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. Windows 7 and later, have a Credential Manager. Persistent-mapped drives usually authenticate automatically at login by using these methods. However, there is no guarantee that it always works. In some cases, it works only when the system name being mapped to match the domain specified in the credential. For example, store 192.168.1.100\qsecofr when you map to \\192.168.1.100 with qsecofr. Use lowercase for the password unless QPWDLVL is 2 or 3. For more information about saving credentials, see Microsoft documentation (try doing a Windows 'Help' on 'Manage Passwords' or 'Credential Manager' or search Microsoft's website).|
Use Network Authentication Instead
Problems with password authentication to NetServer from Windows are common. However, setting up single sign-on with Kerberos authentication does require a substantial initial investment in time. Single sign-on bypasses issues with password authentication and it is virtually maintenance free once configured. For more information, see How to configure EIM and NAS using IBM Navigator for i
If QDLS access is required, consider disabling the QZLSFILET prestart job. The QDLS file system is not thread safe so access is denied for requests to access QDLS from 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 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 and 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 might show incorrect "Created:" date and time properties 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 opportunistic locking can provide a performance benefit in some cases, it can decrease performance in others. It frequently causes long delays. Unless there is a clear need to have this set on, consider turning it off in the NetServer properties. See the screen capture in the IBM i NetServer Configuration section of this document.
Line Description Settings
Ethernet line description settings for Line Speed and Duplex might limit NetServer performance severely when 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 has a negative impact on performance.
Windows WebClient Service
Performance issues exist in Windows 7 with a service named WebClient. Users find improved performance after either toggling the startup between manual and automatic or disabling the service all together. At least one user reported that when 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 process can be time-consuming, especially if mapping to a share that points to the root of the IFS. If Windows tries to index root, it parses through all the files on the system including QSYS.LIB and QNTC. Refer to Microsoft documentation for how to disable indexing when you map to file shares with many files within it.
IBM i NetServer Configuration
NetServer can be configured in the Network component of Navigator for i 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 request signing. This feature 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. Selecting the 'Optional' value 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. Functionality that might be prevented by a command restriction on the green screen might not be restricted through NetServer. A client might be able to change or delete vital parts of the operating system. Ensure that the object authorities are set correctly to prevent problems.
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 cannot be controlled nor corrected by IBM i code, so it is best to restrict unnecessary exposure to these file systems. 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 sharing only 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 information about malware, see Viruses, Malware, Spyware, ransomware, the IBM i Operating System, and the Integrated File System
More 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 the NetServer starts.
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 fails to start with CPIB683 RC5 RC3420. This problem can be avoided by disabling the browser registration: Can NetServer Run With The NetBIOS Protocol Disabled?
Was this topic helpful?
11 March 2022