Can connect to server via RDP but cannot via share files

Question

On a Windows 2012 server I have a network shared folders. The problem is that I can access those resources using remote desktop connection, but when I use \serverIP also asks me username and password, I enter the data requested but responds with the message "access denied". Please help.

This event is logged in the Windows Security logs on the server when I try to connect to the share:

- System 
  - Provider 
   [ Name]  Microsoft-Windows-Security-Auditing 
   [ Guid]  {54849625-5478-4994-A5BA-3E3B0328C30D} 

   EventID 4625 
   Version 0 
   Level 0 
   Task 12544
   Opcode 0
   Keywords 0x8010000000000000 

  - TimeCreated
   [ SystemTime]  2016-09-29T13:15:42.325867400Z
   EventRecordID 35148404 
   Correlation

  - Execution
   [ ProcessID]  764 
   [ ThreadID]  4188      
   Channel Security
   Computer ZFSERVER.zonafrancapc.co
   Security

- EventData     
  SubjectUserSid S-1-0-0
  SubjectUserName - 
  SubjectDomainName - 
  SubjectLogonId 0x0 
  TargetUserSid S-1-0-0 
  TargetUserName Sistemas 
  TargetDomainName SISTEMAS-ZFPC 
  Status 0xc0000022 
  FailureReason %%2304 
  SubStatus 0x0 
  LogonType 3 
  LogonProcessName NtLmSsp 
  AuthenticationPackageName NTLM 
  WorkstationName SISTEMAS-ZFPC 
  TransmittedServices - 
  LmPackageName - 
  KeyLength 0 
  ProcessId 0x0 
  ProcessName - 
  IpAddress 192.168.250.110 
  IpPort 57825 

Answer 1

Per our conversation in the comments on your question it seems like you're client and server are in different subnets.

In that scenario the server and/or client may have been hardened (via a security update) to prevent "SMB over NetBIOS" traffic from flowing outside of the local subnet.

If this is the case, you may be able to workaround your issue by adding/editing the registry value below (as documented in the MS article linked to above).

NETBIOS communication outside of the local subnet is hardened. Therefore, by default, some features that depend on NETBIOS (such as SMB over NETBIOS) will not work outside the local subnet. To change this new default behavior, create the following registry entry:

SUBKEY: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
Value Name: AllowNBToInternet
Type: Dword
Value: 1
Default value of the flag: 0

It's not clear if you would have to update/add this value on both the client and the server, and I don't have environment stood up to test this in at the moment.

I would just add/update the registry entry on both the client and the server and see if it fixes it (may need to reboot one or both). If it does fix it, then you could experiment with removing it from one or the other (and please let us know what you find out).

NOTE:

If you do end up using this as a permanent solution you should consider disabling WPAD to mitigate the initial vulnerability as documented in the original security bulletin (you'll need to check to make sure internet browsing works as necessary afterwards).

Workarounds

• Stop WPAD using a host file entry

  1. Open the host file located at following location as an administrator: %systemdrive%\Windows\System32\Drivers\etc\hosts

  2. Create the following entry for WPAD in the host file: 255.255.255.255 wpad.

Answer 2

If I'm reading the event text properly, the server you're trying to connect to is named "ZFSERVER", the workstation you're connecting from is "SISTEMAS-ZFPC", and the username you're trying to connect with is "Sistemas".

But, based on this:

TargetUserName Sistemas
TargetDomainName SISTEMAS-ZFPC

It looks like you're trying to connect as "SISTEMAS-ZFPC\Sistemas" which is not a valid user on ZFSSERVER.

A good way to determine what username you should be logging in with is to login with RDP, go to a command line, and run "whoami". The domain\username that shows up is what should be entered when you are prompted for credentials.

If you're confidant that you're already entering this information when prompted for credentials then you could have mismatched "Network security" settings between the server and your workstation. To check for this, run "secpol.msc" on each system and compare the settings under:

Security Settings
  Local Polices
    Security Options
      - Domain member: *
      - Microsoft network server: *
      - Microsoft network client: *
      - Network security: *

Pay particularly close attention to the following settings which have cause me issues in the past:

<prefix from above>: Digitally encrypt or sign secure channel data (always)
<prefix from above>: Digitally encrypt secure channel data (when possible)
<prefix from above>: Digitally sign secure channel data (when possible)
Network security: LAN Manager authentication level

_{(I don't have a Windows 2012 server in front of me right now, but I believe these settings are named the same way in 2012.)}

NOTE: You will probably need to reboot your workstation for any changes you make to be effective.