Troubleshooting
Problem
This document explains why current Microsoft Windows versions (beginning as far back as Windows Me/NT/2000/XP) using NT LAN Manager Version 2 (NTLMv2) challenge/response authentication may prompt repeatedly for an operating system user ID and password. Although this is a Windows operating system issue, suggestions are provided that may be helpful in resolving the authentication issues.
Resolving The Problem
Microsoft Windows may prompt repeatedly for a user ID when mapping a drive to a NetServer share.
Windows operating systems using NT LAN Manager Version 2 (NTLMv2) challenge/response authentication require that a domain be specified as part of the credentials if passwords between the two systems are different and if the systems are in different domains. This means that when logging on NetServer, a domain and user ID combination may be needed if the Windows and NetServer passwords are different and if the NetServer is in a different domain than the PC.
According to Microsoft, the NTLMv2 hash includes both the user ID and the domain name as part of the hash and may not encrypt the password correctly if the resource is untrusted. This results in an authentication failure attempting to log on. This began to be seen more frequently with Windows XP and above, because these Windows versions converted to an authentication interface where the domain name is specifically required as part of the password prompt dialog. To work around the encryption problem, try changing the NetServer Domain to be the same Windows Domain as the PC is in. If this is not possible and if NetServer continues to prompt after a valid operating system user ID and password have been typed, using one of the following log on options may circumvent the problem. If one combination does not work, test the other combinations listed.
Note: The circumvention may work not work with all PCs Windows XP and above. This problem is caused by a Microsoft encryption problem and is not something that IBM can correct. When this problem is encountered, support is provided on a best effort basis .
On the Connect As prompt, enter a combination for user ID, such as:
o IBM_i_IP_Address\IBM_i_UserID
o PC-Domain\IBM_i_UserID
o Netserver-Domain\IBM_i_UserID
o PC-Name\IBM_i_UserID
o Netserver-Name\IBM_i_UserID
o FakeDomainName\IBM_i_UserID <--- use a name for the FakeDomainName that does not exist anywhere on your network (for example: DUMMY\IBM_i_UserID)
The password will be the IBM i password for that user profile.
Another work-around may be to use the same user ID and password combination for the Windows logon as for the IBM i NetServer logon.
This issue can also affect the Windows NET USE commands. The repeated prompt does not seem to occur; however, what flows on the session setup is different, and the password can get rejected.
For instance:
With Windows 2008 Server:
NET USE Z: \\ServerName\share /USER:UserID password fails authentication; however, NET USE Z: \\ServerName\share /USER:UserID and letting it prompt for the password has been known to work.
When traced, the difference in flows shows that when the command is allowed to prompt, it includes the 'servername' as the client domain. Again, it appears that Windows does not encrypt accurately without the prefaced servername domain.
NET USE: Z: \\ServerName\share /USER:ServerName\userid password works just like it would for the GUI.
With Windows 7:
NET USE Z: :\\IP Address\share /USER:ServerName\UserID password might fail; however, NET USE Z: \\ServerName\share /USER:ServerName\UserID password works.
Changing to NET USE Z: \\IP Address\share /USER:IPAddress\UserID password might also work.
Some NetServer users have also reported prompt issues due to PC-Domain authority. We have no specific details regarding the changes made; however, the repeated prompting for at least one user was resolved by increasing the specific Windows UserID authority to the PC-Domain.
Windows operating systems using NT LAN Manager Version 2 (NTLMv2) challenge/response authentication require that a domain be specified as part of the credentials if passwords between the two systems are different and if the systems are in different domains. This means that when logging on NetServer, a domain and user ID combination may be needed if the Windows and NetServer passwords are different and if the NetServer is in a different domain than the PC.
According to Microsoft, the NTLMv2 hash includes both the user ID and the domain name as part of the hash and may not encrypt the password correctly if the resource is untrusted. This results in an authentication failure attempting to log on. This began to be seen more frequently with Windows XP and above, because these Windows versions converted to an authentication interface where the domain name is specifically required as part of the password prompt dialog. To work around the encryption problem, try changing the NetServer Domain to be the same Windows Domain as the PC is in. If this is not possible and if NetServer continues to prompt after a valid operating system user ID and password have been typed, using one of the following log on options may circumvent the problem. If one combination does not work, test the other combinations listed.
Note: The circumvention may work not work with all PCs Windows XP and above. This problem is caused by a Microsoft encryption problem and is not something that IBM can correct. When this problem is encountered, support is provided on a best effort basis .
On the Connect As prompt, enter a combination for user ID, such as:
o IBM_i_IP_Address\IBM_i_UserID
o PC-Domain\IBM_i_UserID
o Netserver-Domain\IBM_i_UserID
o PC-Name\IBM_i_UserID
o Netserver-Name\IBM_i_UserID
o FakeDomainName\IBM_i_UserID <--- use a name for the FakeDomainName that does not exist anywhere on your network (for example: DUMMY\IBM_i_UserID)
The password will be the IBM i password for that user profile.
Another work-around may be to use the same user ID and password combination for the Windows logon as for the IBM i NetServer logon.
This issue can also affect the Windows NET USE commands. The repeated prompt does not seem to occur; however, what flows on the session setup is different, and the password can get rejected.
For instance:
With Windows 2008 Server:
NET USE Z: \\ServerName\share /USER:UserID password fails authentication; however, NET USE Z: \\ServerName\share /USER:UserID and letting it prompt for the password has been known to work.
When traced, the difference in flows shows that when the command is allowed to prompt, it includes the 'servername' as the client domain. Again, it appears that Windows does not encrypt accurately without the prefaced servername domain.
NET USE: Z: \\ServerName\share /USER:ServerName\userid password works just like it would for the GUI.
With Windows 7:
NET USE Z: :\\IP Address\share /USER:ServerName\UserID password might fail; however, NET USE Z: \\ServerName\share /USER:ServerName\UserID password works.
Changing to NET USE Z: \\IP Address\share /USER:IPAddress\UserID password might also work.
Some NetServer users have also reported prompt issues due to PC-Domain authority. We have no specific details regarding the changes made; however, the repeated prompting for at least one user was resolved by increasing the specific Windows UserID authority to the PC-Domain.
IBM has no similar examples using any more current Windows or Windows Server Versions.
[{"Type":"MASTER","Line of Business":{"code":"LOB68","label":"Power HW"},"Business Unit":{"code":"BU070","label":"IBM Infrastructure"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CLSAA2","label":"Integrated File System-\u003ENetServer"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Versions"}]
Historical Number
30470547
Was this topic helpful?
Document Information
Modified date:
07 January 2025
UID
nas8N1016520