Troubleshooting
Problem
This document provides additional information on how user profiles become disabled for NetServer use and describes the two most common causes and resolutions.
Symptom
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.
Cause
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
===> DSPLOG PERIOD((*AVAIL *BEGIN)) OUTPUT(*PRTSECLVL) MSGID(CPIB682)
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 the user does not specify a domain name, Windows sends one because 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_USRPRF
- IBM_i_IP_Address\IBM_i_USRPRF
- Netserver-Domain\IBM_i_USRPRF
- PC-Name\IBM_i_USRPRF
- Netserver-Name\IBM_i_USRPRF
Valid authentication credentials can be forced by using the "net use" command. For example,
C:\> net use i: \\MyIBMi\MyShare /user:FAKE\IBM_i_USRPRF IBM_i_password
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.
Related Information
Historical Number
616842153
Was this topic helpful?
Document Information
Modified date:
06 October 2023
UID
nas8N1011278