"Access Denied" Accessing Windows 95 Share from Windows NT 4.0

• Microsoft Windows 95
• Microsoft Windows 95 OEM Service Release versions 1, 2, 2.1
• Microsoft Windows NT Workstation version 4.0
• Microsoft Windows NT Server version 4.0

SYMPTOMS

When you attempt to connect to a share on a Windows 95-based computer from a Windows NT 4.0 workstation or server, the connection attempt may not succeed and you may receive an "Access Denied" error message if the following conditions exist:

• The Windows 95 server has user-level security enabled (instead of share-level security), and the security provider is a Windows NT domain.
• You are attempting to connect to the Windows 95-based computer by using a UNC name (\\<servername>\<sharename>) instead of by mapping a drive letter to the share.
• The Windows NT 4.0 workstation or server has Service Pack 2 installed.

CAUSE

This symptom is the result of an interoperability problem between Windows NT 4.0 with Service Pack 2 installed and Windows 95. Windows NT 4.0 with Service Pack 2 makes a connection using a null user name, which Windows 95 does not handle correctly.

STATUS

Microsoft has confirmed this to be a problem in Microsoft Windows 95 and OEM Service Release 2 (OSR2). An update to address this problem is now available, but is not fully regression tested and should be applied only to computers experiencing this specific problem. Unless you are severely impacted by this specific problem, Microsoft does not recommend implementing this update at this time. Contact Microsoft Technical Support for additional information about the availability of this update.

MORE INFORMATION

Windows NT 4.0 Service Pack 2 (SP2) uses a new version of the Multiple UNC Provider (MUP) that contains new code for DFS. This code establishes a null session when you connect to a server. The Windows 95 File And Print Sharing service for Microsoft Networks (Vserver) does not handle the null session correctly and tries to use a null user name to check for the access rights. When the MUP null session requests arrives at Vserver, SessSetupX calls AccessLogon.

Because smb_uid is always zero, even for TESTUSER, there is no way to distinguish user TESTUSER from the null-session user. Vserver uses the null user name for credentials checking in further SMB commands and you receive the "Access Denied" error message.