IBM Support

User Profiles Disabled for Use with IBM i NetServer



This document provides additional information on how user profiles become disabled for NetServer use and describes the two most common causes and resolutions.


Windows displays an "Access denied" message when you try to map to IBM i NetServer.

The IBM i QSYSOPR job log contains message:

CPIB682 - User profile <TheUSRPRF> disabled for i5/OS Support for Windows Network Neighborhood access.


Profiles are disabled for NetServer use based on the QMAXSIGN system value. Disablement of profiles for NetServer use is tied to this system value and cannot be turned off. An internal counter tracks how many times an incorrect password is received by the IBM i NetServer for each profile. Hits against the counter remain until one of the following occurs:

  • The number of hits adds up to the QMAXSIGN value (at which point, the profile is disabled for NetServer use).
  • A successful connection is made.
  • The counter is reset by using GO NETS menu, call to the QZLSCHSI API, reenabling in Navigator for i, restarting NetServer, or a system IPL.

Note: IBM i NetServer uses the value of QMAXSIGN at the time the NetServer was started. Changes to the QMAXSIGN system value will not have any effect on IBM i NetServer until after it is restarted.

Diagnosing The Problem

The following command generates a QPDSPLOG spool file containing all of the "User profile <TheUSRPRF> disabled for IBM i Support for Windows Network Neighborhood access" messages. These messages each have a time stamp and the IP address of the client that sent the invalid credentials and can be useful in diagnosing the source of the problem.

Resolving The Problem

1) Windows XP and later are prefixing the user ID with the Windows domain or workstation name.

The password is sent in a hash. The hash is partially based on the domain name that is sent.

Even if you do not provide a domain name, Windows sends one; it is required for NTLMv2 password hashing.  If you are logged in to a Windows domain with that ID, it sends the domain password instead of the password you enter. To prevent that, you must provide a domain name that is not a real Windows domain. Although there is nothing special about the domain examples given here, the following examples are some that you can use:

  • FAKE\IBM_i_UserID
  • IBM_i_IP_Address\IBM_i_UserID
  • Netserver-Domain\IBM_i_UserID
  • PC-Name\IBM_i_UserID
  • Netserver-Name\IBM_i_UserID

Valid authentication credentials can be forced by using the "net use" command. For example:

C:\> net use i: \\MyiSeries\MyShare /user:FAKE\IBM_i_USRPRF IBM_i_password
Usually, Windows "remembers" when an alternate domain ID was used to successfully authenticate to a remote network resource and stops sending the invalid Windows domain ID.

2) Mixed-case password
The other common cause of user profiles becoming disabled for NetServer is that the IBM i system value QPWDLVL is set to the default value of 0. This value means all users' passwords are stored in single case. NetServer always accepts the case of the password that is passed to it. So, if the Windows client passes a mixed-case password, NetServer compares it against the single-case password that is stored on the IBM i and they do not match. Windows administrators frequently require a mixed-case password. If the Windows and IBM i UIDs are the same and the passwords are the same except for the case, repeated failed attempts causes the user profile to become disabled for use with NetServer.

For more information about upgrading the IBM i password level, see Considerations for changing QPWDLVL from 0 to 3

Finally, administrators could consider making use of Kerberos (Single Sign-on) so that authentication tokens are passed to NetServer instead of encrypted user ID and password.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"Component":"Integrated File System","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"Version Independent","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}]

Historical Number


Document Information

Modified date:
11 July 2022