An SMB share is displayed incorrectly as an NFS share

 

Hello ALL,

 

I was reading some old emails and I'd like to share one more case that I worked. It was an interesting case where we have 2 scenario and 2 separates solution. Unfortunately one hasn’t solution found.

 

Let's go!

 

Scenario

============

We have a Windows Server running 'Client for NFS' (Windows 2K8R2 SP1) and a File Server running UNIX OS (NFS). When some user log onto Windows Server the end user needs to map the Unix File Shared using one letter. When that end user select the option for map an UNIX NFS server with the "Reconnect at logon" the message below is displayed if tries use the mapped drive letter after logoff/logon is done.

 

"Z:\ is not accessible. The filename, directory name, or volume label syntax is incorrect".

 

 

 

Actions and Solution PART I

=======================

• First action is use the article KB2025723 to review the Security Option.
  • Client for NFS on Windows 2008 R2 does not work properly

http://support.microsoft.com/kb/2025723

• The resolution is to select only “sys” option and reboot the system.

 

• After that you should deploy the KB2485529 to fix the error message "Z:\ is not accessible. The filename, directory name, or volume label syntax is incorrect" and for best practices update the Windows Server with the KB2580164.
• Now we have fix the error message and the drive Z:\ can be accessible.

• Now the interesting part ... After logoff and logon the mapped drivers (Z:) is working however just if we click again in Explorer Window on the drive letter Z:\
• Now we see after logon the driver letter is being displayed with Red Cross. "X"

• Event Viewer

Event 16397, NfsClnt

General Details

Windows(R) Lightweight DirectoryAccess Protocol (LDAP) failed a request to connect to Active Directory Domain Services(R) for Windows user< BLABLA\XYZ.ABC>.

Without the corresponding UNIX identity of the Windows user, the user cannot access Network File System (NFS) shared resources.

Verify that the Windows user is in Active Directory Domain Services and has access permissions.

• Found the article blog "Getting Red X sign on mounted NFS volume from Windows client " - http://blogs.technet.com/b/sfu/archive/2011/09/20/getting-red-x-sign-on-mounted-nfs-volume-from-windows-client.aspx

Windows NFS client is known not to handle multiple path NFS shares. The issue is by design and comes when the client is mounting an NFS share which is more than 26 characters in length.

 

Users would be able to access the NFS shares after mounting it to a drive letter but a red X (disconnected) sign would be there on the mounted volume. The NFS mounted drives will be in connected state even if UI shows disconnect.

 

The recommendation would be to have a single path nfs share like “\\servername\sharename” or a multipath NFS share having less than 25 characters.

• In that case the number of characters was 20.
• No more actions to do. This is by design.

Solution PART II

==============

NFS share are session specific and are not persistent mount. Even if we check the persistent mapping option while doing a Map network driver or put the parameter persistent=yes with the mount command.

 

Unlike CIFS shares where the drive mapping is persistent, NFS is not. So once the user logs off and logs back in, he will see the disconnected sign on the drive. The same observation would be there, if he runs the mount command from the cmd.

 

This is a known behavior.

 

Hope it helps!

Wi-fi Show Characters

Customer informed when configuring the wireless network for end users the option "show characters"  is enabled to display the password and with this option some end users are sharing this password to other unauthorized people.

Customer would like to know how to disable this option.

Assuming the customer is taking about "Show Characters" in the security tab of  Wireless Profile. This feature is made for administrators be able to recover a forgotten wireless network key. Customer must configure users as non-admin or more robust enterprise authentication method for wireless authentication.

Windows 7 adds the ability to recover a forgotten wireless network key. To accomplish this, open the properties of the wireless network, and from the Security tab check the box next to Show characters. This will show a previously entered wireless network key, so that it can be recovered without resetting the router back to factory defaults. Viewing the wireless network key in this manner requires administrative rights. This feature is protected by UAC prompt.

Problem:

How to prevent users from viewing the WEP key in plaintext.

Resolution:

Usually the key will be masked in the UI if it is provisioned in the profile. For example below steps can provision the profile with the shared WEP key.

1. On a windows 7 machine, create a new wireless profile and set the WEP authentication method along with the WEP key, save the change.

2. Open a command window with run as administrator and run command, netsh wlan export profile. All of the wireless network profiles will be exported to files in the current directory.

3. Copy the file for the newly defined profile to a new windows 7 machine.

4. Login the new windows 7 machine with local admin credential, open a command window with run as administrator, then run command, netsh wlan add profile <profile file path>

5. Then login the new windows 7 machine with a non-admin user, the password will be hidden for this user.

NOTE: for the local admin user or user with equivalent right will still be able to toggle the show characters option to view/hide the WEP key. 

On windows 7, however, there is an overhaul of WEP KEY UI on windows 7 as opposed to windows XP for users with local administrator right.  Those admin users will be always able to view the keys.

More analysis:

On windows 7, however, there is an overhaul of WEP KEY UI on windows 7 as opposed to windows XP for users with local administrator right.  Those admin users will be always able to view the keys. The thought behind this change is many SOHO/home users tend to forget the shared WEP key and it is a bit difficult to recover it as there is no obvious UI on XP for it. So it is decided to introduced the ability to allow users with admin right to view the key on windows 7 and this behavior cannot be turned off..

Furthermore, OPEN/WEP wireless authentication is often intended for personal/home users and it is proven to be less secure compared with other authentication options.  A cryptanalysis of WEP has been published that exploits the way the RC4 cipher and IV is used in WEP, resulting in a passive attack that can recover the RC4 key after eavesdropping on the network. Depending on the amount of network traffic, and thus the number of packets available for inspection, a successful key recovery could take as little as one minute. As a result, it is recommended to use stronger and more secure authentication method like 802.1X/WPA2 for enterprise environment.  Regarding more options of wireless deployment, please refer to

• Foundation Network Companion Guide: Deploying 802.1X Authenticated Wireless Access with PEAP-MS-CHAP v2

Get instructions on how to deploy 802.1X authenticated wireless access by using Protected Extensible Authentication Protocol-Microsoft Challenge Handshake Authentication Protocol version 2 (PEAP-MS-CHAP v2).

• 802.1X Authenticated Wireless Access Design Guide

Learn how to plan and design a new end-to-end 802.1X authenticated wireless infrastructure deployment, using features in Windows Server 2008 and 802.1X-capable wireless access points that you deploy on your network.

• IEEE 802.11 Wireless LAN Security with Microsoft Windows

Understand the security issues with 802.11 wireless networks and how Microsoft Windows can be used to make 802.11 wireless networks as secure as the 802.11 standards allow. For a webcast version of this white paper, click here.

• The Advantages of PEAP

Learn about the efforts of the IEEE and the Internet Engineering Task Force (IETF) to address secure wireless access and see how the Protected Extensible Authentication Protocol (PEAP) compares to other standards-based and proprietary schemes.

• July 2010 - Connecting to Wireless Networks with Windows 7  This article describes how to connect to 802.11 wireless networks and manage wireless network profiles with Windows 7.

• May 2005 - Wi-Fi Protected Access 2 (WPA2) Overview The Wi-Fi Protected Access 2 (WPA2)/Wireless Provisioning Services Information Element (WPS IE) Update for Windows XP with Service Pack 2 is a free download that updates the wireless client components in Windows XP with Service Pack 2 to support WPA2. This article describes the features of WPA2 security and WPA2 support included with the update.

There are more resources on the wireless portal http://technet.microsoft.com/en-us/network/bb530679.aspx.

Printing from a Legacy Application - using 'Dir' with LPT port fails

Another cool case that show us how Microsoft Windows editions works with SMB protocol.
Let's think about the whole scenario:
    - When try redirect printing to any LPT port results in ‘Access Denied’ .
   
    - Using the command “net use lpt1 \\computername\printername” to redirect the output from an legacy application to a network printer. This command was working fine under Windows 2003 in order to enable network printing from the DOS application. After migrating the Print Server for Windows 2008 based the CMD (DIR >LPT1) and DOS Legacy Application it's not working.
    - Message "Access Denied" and "Printer not Available".
   
<Solution>
    - Download Processor Monitor and executed on Print Server.
    - Analyze the Logs and found the following information:
   
    C:\Windows\system32\ntvdm.exe
    Date & Time:    23/11/2011 15:12:23
    Event Class:    File System
    Operation:    CreateFile
    Result:    ACCESS DENIED
    Path:    \\;LanmanRedirector\;LPT1:00000000000fb07e\abcdserver\epson\
    TID:    6872
    Duration:    0.0057445
    Desired Access:    Generic Write, Read Attributes
    Disposition:    OpenIf
    Options:    Synchronous IO Non-Alert, Non-Directory File
    Attributes:    N
    ShareMode:    Write
    AllocationSize:    0
   
   
    - To resolve the issue we need to change the way the Servers and Workstations communication with each other.
    - Since the Windows Vista, Microsoft upgrade this way to communication using the SMB version 2.
   
    Server Message Blocks Protocol (SMB) is the file sharing protocol used by default on Windows-based computers. SMB 1.0 was designed for early Windows operating systems , but until Windows Server 2008 and Vista.
    SMB 2.0 was introduced in Windows Vista and Windows Server 2008. SMB 2.0 is designed for the needs of the next generation of file servers. Windows Server 2008 R2 and Windows Vista and Windows7 support both SMB 1.0 and SMB 2.0 in order to preserve backward compatibility.
   
    Here's how SMB is used when related to SMB versions:
        ○ When a Windows Server 2008/Vista "client" connects to a Windows Server 2008/Vista "server", SMB 2.0 is used.
        ○ When a Windows Server 2008/Vista "client" connects to a Windows 2000/XP/2003 "server", SMB 1.0 is used.        ○ When a Windows 2000/XP/2003 "client" connects to a Windows Server 2008/Vista "server", SMB 1.0 is used.
        ○ When a Windows 2000/XP/2003 "client" connects to a Windows 2000/XP/2003 "server", SMB 1.0 is used.
   
   
    - OK. Now the solution:
    - Using the Regedit to disable SMB2 on the server (I used this one).
        1.Run "regedit" on Windows Server 2008 based computer.
        2.Expand and locate the sub tree as follows.
        HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
       
        3.Add a new REG_DWORD key with the name of "Smb2" (without quotation mark)
        Value name: Smb2
        Value type: REG_DWORD
            0 = disabled
            1 = enabled
       
        4.Set the value to 0 to disable SMB 2.0, or set it to 1 to re-enable SMB 2.0.
       
        5.Reboot the server.
       
    - Restarted Services ["Server" "Printer Spooler" "Workstation"] . I prefer restart the server (but sometimes customer cannot).
    - Get a new ProcMon and no access denied or \\;LanmanRedirector logs found.
    - Tested DIR >LPT1 = OK
    - Tested on application and works.