none
Windows 7 + The specified network password is not correct (connecting to shared drive)

    Question

  • I'm having difficulty connecting my Windows 7 Home Premium (release version) to a Netapp shared drive which the Netapp is part of a domain.  The Netapp is properly connected to the PDC and is in Wins and machines part of the domain have no troubles connecting.  When I browse to the share on Win 7, it pops up a username/password prompt.  I type in a correct domain, login and password for the correct domain (I know the password is correct, I type it every day).  Note that this Win 7 machine is Home Premium.  With Vista HP, I had no troubles connecting to this specific system at all using a proper domain login/password.  In fact, it worked perfectly and I connected just fine.  With Win 7, it always gives me 'The specified network password is not correct'.  I am able to connect to Windows systems with drive shares in the domain, but I cannot connect to this Network Appliance device.

    I have tried every method of getting my system to authenticate properly including

    • changing DNS
    • changing WINS
    • promoting a BDC to a PDC
    • demoting an old PDC to BDC
    • ensured the clocks are synced
    • used multiple accounts
    Did something about the Windows authentication (i.e., increased encryption bit size or type) change between Vista and Windows 7 to cause this failure in the authentication on the Netapp?  If so, is there a registry setting to revert it back to the Vista version?

    Thanks.

    --
    Brian
    • Edited by Boomerang_Dave Friday, October 30, 2009 3:31 AM clarification
    Friday, October 30, 2009 3:30 AM

Answers

  • Arthur,

    Thank you for this information. While this answer didn't solve the problem directly, it put me on the right track.  Here's the problem.  This is Windows 7 Home Premium edition. gpedit.msc and secpol.msc only exist on Windows versions that support connection to a domain (i.e., Ultimate, Professional, Business, etc).  This policy editor does not exist on Home Premium. However, since you mentioned that it's probably using NTLMv2, I searched this forum on NTLMv2 and Windows 7 and turned up this article. Basically, rtoledo2002 says that to accomplish this in Windows 7 Home Premium you do the following:

    "1. Run the registry editor and open this key: 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 
    1. If it doesn't already exist, create a DWORD value named 
    LmCompatibilityLevel 
    3. Set the value to 1 
    4. Reboot"

    I found that Windows 7 Home Premium has the LmCompatibilityLevel DWORD set to 3.  I changed it to 1, rebooted and now I can connect to this drive share without problems.

    Thanks for steering me in the right direction.

    --
    Brian


    Saturday, October 31, 2009 7:53 AM
  • This issue can be caused by the incompatible Kerberos encryption types. I suggest that you make the following changes on the Windows 7 computer:

    1. Open gpedit.msc.
    2. Find the policy

    Windows Settings -> Security Settings -> Local Policies -> Security Options ->Network Security: Configure encryption types allowed for Kerberos

    3. Configure the policy. If it is not configured, actually both DES cipher suites are disabled. I suggest that you enable all the suits.

    Then please check the result.

    If the issue persists, please change the NTLM type in Windows 7. You may refer the following article.

    Network security: LAN Manager authentication level

    Please change the level to “Send LM & NTLM - use NTLMv2 session security if negotiated”.


    Arthur Xie - MSFT
    Saturday, October 31, 2009 6:08 AM
    Moderator

All replies

  • This issue can be caused by the incompatible Kerberos encryption types. I suggest that you make the following changes on the Windows 7 computer:

    1. Open gpedit.msc.
    2. Find the policy

    Windows Settings -> Security Settings -> Local Policies -> Security Options ->Network Security: Configure encryption types allowed for Kerberos

    3. Configure the policy. If it is not configured, actually both DES cipher suites are disabled. I suggest that you enable all the suits.

    Then please check the result.

    If the issue persists, please change the NTLM type in Windows 7. You may refer the following article.

    Network security: LAN Manager authentication level

    Please change the level to “Send LM & NTLM - use NTLMv2 session security if negotiated”.


    Arthur Xie - MSFT
    Saturday, October 31, 2009 6:08 AM
    Moderator
  • Arthur,

    Thank you for this information. While this answer didn't solve the problem directly, it put me on the right track.  Here's the problem.  This is Windows 7 Home Premium edition. gpedit.msc and secpol.msc only exist on Windows versions that support connection to a domain (i.e., Ultimate, Professional, Business, etc).  This policy editor does not exist on Home Premium. However, since you mentioned that it's probably using NTLMv2, I searched this forum on NTLMv2 and Windows 7 and turned up this article. Basically, rtoledo2002 says that to accomplish this in Windows 7 Home Premium you do the following:

    "1. Run the registry editor and open this key: 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 
    1. If it doesn't already exist, create a DWORD value named 
    LmCompatibilityLevel 
    3. Set the value to 1 
    4. Reboot"

    I found that Windows 7 Home Premium has the LmCompatibilityLevel DWORD set to 3.  I changed it to 1, rebooted and now I can connect to this drive share without problems.

    Thanks for steering me in the right direction.

    --
    Brian


    Saturday, October 31, 2009 7:53 AM
  • Brina,

    I am using Windows 7 Home Premium as well, and I had a problem connecting to the file share on my Win 2k domain.
    I tweaked the registry as described above expect I changed the value to 2.
    And it's connected.
    The value 1 didn't work for me.
    It probably uses different values for different systems.
    Thanks for sharing the info.

    Won
    Wednesday, December 09, 2009 7:10 AM
  • All,

    Neither solution worked for me.  I am trying to connect my Windows 7 Enterprise to a Buffalo Technology LinkStation LS-WX2.0TL/R1 Network Storage Server.  I have tried connecting to this server through a wired connection and a wireless connection.  I am unable to get either to work.  I have tried changing the above values in the "LMCompatibilityLevel" registry key to "1", restarted my computer, and it was still unable to connect.  I also tried changing the registry key to "2" and it did not work.  I also tried to use the gpedit.msc solution and that did not work.  Below is a screen shot of my Network Security settings within the Local Group Policy Editor.

    Photobucket

    The weird thing is that I have another computer with Windows XP installed and it is able to connect to the server just fine.  The server did come with software (NASNavigator version 2.31) that I installed on my Windows 7 computer.  It actually sees the server within that software.  I see the IP address and everything works great within that software.  But when I try to browse the browse the shared folders nothing happens.  Does anyone have any suggestions.

    Sunday, January 02, 2011 1:22 AM
  • Chris20042004,

    I'm experiencing the same issue w Buffalo Linkstation Pro LS-V1.0TL and Windows 7.  (btw Apple OS X connected fine)

    Bummed that changing the LMcompatibilityLevel to either 1 or 2 did _not_ solve that problem.

    if I find out anything, I'll post back.

    Thursday, February 17, 2011 8:40 AM
  • (this is an HP laptop w Windows 7 64 bit Home Premium OS. )

    ok made some progress, I tried changing the LmCompatibilityLevel to 1 but as reported by some, did not solve my problem.

    I looked carefully at the Windows 7 error message and tried doing exactly what it said...

    "Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again."

    I disconnected all the mapped drives (folders) to the Buffalo NAS and then rebooted.

    then mapped the drive's folder using the login credentials from Buffalo as "server\username" and password.

    worked !!

    then as a quick test I tried mapping a second folder set with permissions of a different user (local user on the Buffalo drive) and that failed.

    note: I also had trouble getting Windows to "forget" any drives that were disconnected, and the reboot seemed to fix that.

     

    also this link has pertinent info on the topic:

    http://social.msdn.microsoft.com/forums/en-US/biztalkgeneral/thread/aeeb452d-0254-4bc2-a598-20f1f57ee8e0/

    what I don't understand is why this limitation exists ?

    Thursday, February 17, 2011 10:42 PM
  • Arthur,

    Thank you for this information. While this answer didn't solve the problem directly, it put me on the right track.  Here's the problem.  This is Windows 7 Home Premium edition. gpedit.msc and secpol.msc only exist on Windows versions that support connection to a domain (i.e., Ultimate, Professional, Business, etc).  This policy editor does not exist on Home Premium. However, since you mentioned that it's probably using NTLMv2, I searched this forum on NTLMv2 and Windows 7 and turned up this article. Basically, rtoledo2002 says that to accomplish this in Windows 7 Home Premium you do the following:

    "1. Run the registry editor and open this key: 
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 
    1. If it doesn't already exist, create a DWORD value named 
    LmCompatibilityLevel 
    3. Set the value to 1 
    4. Reboot"

    I found that Windows 7 Home Premium has the LmCompatibilityLevel DWORD set to 3.  I changed it to 1, rebooted and now I can connect to this drive share without problems.

    Thanks for steering me in the right direction.

    --
    Brian


    After upgrading my Window 7 Home Premium 64 to professional and tried the steps above... it worked...

    But the issue come back again after the recent security update for microsoft .net framework4 Client profile on 12 April 2012. Now it does not work even with the same fix above until I painstakingly UNINSTALL all client profile updates!!!!

    Microsoft really need to improve on this....it is really annoying...

     

     
    Saturday, April 14, 2012 8:38 AM