RE: PWDLVL 2 & file shares

This information may help you isolate what is going on:


QNTC and CPDB053 - Error Exchanging Security Information



Technote
What is QNTC, and what does it connect to?
What is QNTC, and what does it connect to?

QNTC is a 'Distributed Files System' that is accessible through the IFS. It is a CIFS 1.0 compliant client that can be used to connect to the following:

o Shares on any Microsoft OS based system.
o Shares on a Linux Samba 3.0 (or newer) server.
o Shares in i5/OS NetServer.

Documentation for the CIFS 1.0 specification can be found at the following Web site:
//www.snia.org/tech_activities/CIFS/
How does QNTC authenticate with remote servers?
How does QNTC authenticate with remote servers?

QNTC can use two different methods to authenticate with remote servers. The most commonly used method is NTLM (Windows NT LAN Manager). The following definition of NTLM comes from Microsoft's NTLM Authentication protocol specification:
//msdn.microsoft.com/en-us/library/cc236621(PROT.10).aspx

NTLM is a challenge -response style authentication protocol. This means that to authenticate a user, the server sends a challenge to the client. The client then sends back a response that is a function of the challenge, the user's password, and possibly other information. Computing the correct response requires knowledge of the user's password. The server (or another party trusted by the server) can validate the response by consulting an account database to get the user's password and computing the proper response for that challenge.

It is important to note that QNTC will use NTLM and NTLMSSP for authentication; however QNTC does not use or support the NTLMv2 protocol because it is not part of the CIFS 1.0 specification.

QNTC can also use Kerberos authentication; however, that will be discussed in a separate document.
What i5/OS settings will affect QNTC authentication?
What i5/OS settings will affect QNTC authentication?

Since QNTC is a sub-component of iSeries NetServer, the configuration of NetServer will be used by QNTC. The only NetServer setting that can impact QNTC authentication is the Domain/Workgroup name. It is important to note that the Domain name in question is not the same entity as a TCP/IP domain name (in other words, IBM.COM), but is a Microsoft Windows Domain name. This may be given the same name as a TCP/IP domain; however, they are distinct and separate entities. The i5/OS system value QPWDLVL will directly impact QNTC authentication. For QNTC to use NTLM authentication, this system value must be set to 0 or 2. You can read more detailed information on this system value, and how it impacts QNTC and NetServer in the following Rochester Support Center knowledgebase documents:

431537697 , NetServer Authentication and Security Considerations :
406035134 , QPWDLVL 2/3 and Passwords Entered at QPWDLVL 0/1 :
468542275 , The iSeries NetServer and QPWDLVL 1,3 :

The user profile setting 'Local Password Management' (LCLPWDMGT) will impact which authentication method can be used with QNTC.
The default setting for this parameter is *YES. This means that the password for the user profile in question will be managed on the local system (the i5/OS partition that the user profile resides on). This will force QNTC to use NTLM authentication, and it will not be able to use Kerberos authentication. If this parameter is changed to *NO, the password for this user profile will not be managed by the local system, requiring the i5/OS partition to be configured for Single Sign-on and Enterprise Identity Mapping (EIM). This will force QNTC to Kerberos authentication only, it will not be able to use NTLM.

What is a CPDB053 error?
What is a CPDB053 error?

The 'Error exchanging security information' (CPDB053) error message is a failure message that is returned from QNTC to the job that is accessing a remote server through QNTC. This is a message indicating that the remote server returned an authentication failure return code, after QNTC sent the required authentication information (domain name, user-ID, password). The 'Technical description' section of this message will always include a specific 'Error Class' and Error Code' that was returned by the remote server to QNTC. The message also contains a list of the most common error classes and error codes, and their meanings.

The most common error class and error code received is Error class 1, error code 5 - Access denied. This is most commonly returned when the target Windows server is unable to authenticate the user-ID and password that was provided by QNTC. This may also occur when attempting to use a 'Domain Account' and iSeries NetServer is not configured to be in the same Windows Domain that the target Windows server is in.


I am getting Error Class 1 Return Code 5, what can I do to fix it?
I am getting Error Class 1 Return Code 5, what can I do to fix it?

What to do will depend upon the situation: Is this a new connection that has never worked, or is this an existing connection that has been working but is now failing?
New connection that has never worked
New connection that has never worked

If this error is encountered the first time, a QNTC connection to a remote server is attempted or has always produced this failure. The first thing to check is to see if there is a corresponding user-ID (with matching password) on the target server. This means that if you sign on to the iSeries with usrprf JOEP (with password abc123), you will need to be able to sign on to the target server with user-ID JOEP (and password abc123). If you cannot sign on to the target server with the same credentials that are used to sign on to the iSeries, the target server will not be able to authenticate the connection.

If the usrprf in question does have a matching user-ID that can sign on to the target server, it is time to check the password settings. Does the target server require the use of a mixed-case password (for example, P assword, pa SS word, PASS word)? If this is required, review the previous section 'What i5/OS settings will affect QNTC authentication?' , specifically the statements about sysval QPWDLVL. If QPWDLVL is set to level 0, QNTC will send the password in all lowercase. (S02 has set QPWDLVL to 0 so DON't use mixcased passwords)

Verify that iSeries NetServer is configured with the same Windows Domain as the target server. Use a 'Local Account' (a user account that is set up locally on the target server) instead of a 'Domain Account'.
Existing connection that has worked before, and is now failing
Existing connection that has worked before, and is now failing

If this error starts to occur with a connection that has been previously working, the first thing to look at is: What changed? Something somewhere changed to cause this failure to occur.

If this failure is occurring in a batch job that is running on a schedule on the iSeries, was the job submitted to run under the correct usrprf? This is done by specifying the usrprf on the USER parameter of the SBMJOB command. Was the password changed on either the iSeries or the target server, but not changed on both? It is common practice to require passwords to be changed on a regular basis. You should make sure the password is kept 'in sync' between the iSeries and the target server. Is the user-ID a 'Domain Account' on the target server? You should set up a matching 'Local Account' on the target server and test connectivity. If the 'Local Account' fails, review the section New connection that has never worked . If it does not fail, review the section I see this error when using a Domain account but a Local Account works fine .
Another possible cause of this failure is if 'SMB Signing' is set to required on the target server. QNTC does support 'SMB signing'; however, it should be set to 'Enabled' instead of 'Required' on the target server. The following Microsoft knowledge base document has more specific information on 'SMB Signing':
//support.microsoft.com/kb/887429
I am getting an error code that is not listed; now what?
I am getting an error code that is not listed; now what?

The following Microsoft document contains a more complete list of Error Codes and Error Classes that would be returned by a Windows OS:
//msdn.microsoft.com/en-us/library/aa302198.aspx

Can I use a Domain Account, or do I have to use a Local Account?
Can I use a Domain Account, or do I have to use a Local Account?

It makes no difference to i5/OS or QNTC (or any CIFS1.0 compliant client using NTLM) how the target server will do its authentication. The concept of a 'Local' or 'Domain' account is specific to Microsoft-based operating systems, and is not part of the CIFS 1.0 specification.
I see this error when using a Domain Account; however, a Local Account works fine. What does this mean?
I see this error when using a Domain Account; however, a Local Account works fine. What does this mean?

This indicates that the target server was unable to validate the provided user-ID and password with its Domain Controller. This is a validation process that occurs between the target Windows server and its Domain Controller. This process is outside of the control, influence, or knowledge of the QNTC connection as noted in Step 4 of the following Microsoft Technet document:
//msdn.microsoft.com/en-us/library/cc236629(PROT.10).aspx

The client sends an NTLM AUTHENTICATE_MESSAGE message to the server. The message contains the name of a user and a response that proves that the client has the user's password. The server validates the response sent by the client. If the user name is for a local account, it can validate the response by using information in its local account database. If the user name is for a domain account, it can validate the response by sending the user authentication information (the user name, the challenge sent to the client, and the response received from the client) to a domain controller (DC) that can validate the response (Section 3.1 [MS-APDS]). The NTLM protocol completes.

An example of the differences between local authentication and domain authentication can be found in the following Microsoft TechNet document:
//msdn.microsoft.com/en-us/library/cc246036(PROT.10).aspx

Here is a Microsoft Knowledge base document describing the Network access validation algorithms for Microsoft base OS's:
//support.microsoft.com/kb/103390/en-us

But I do not have a problem accessing this share from a Windows PC, when using the same user-ID
But I do not have a problem accessing this share from a Windows PC when using the same user-ID

This will happen because all currently supported Microsoft OS's will implicitly use Kerberos authentication, not NTLM, as described in the following Microsoft Technet document:
//msdn.microsoft.com/en-us/library/aa302196.aspx


Reply or Forwarded mail from: Kenneth E Graap