Problems accessing shared folder in Windows clustered file Server 2008 R2

0

Firs of all I need to apologise for my poor technical and language skills. I will try to describe a problem as detail as I can.

There is subnet 172.16.10.0/24 In this subnet I have 3 servers 1 storage and 7 workstations (real count are many more). All this machines connected to 1 single core switch.

172.16.10.15/24 gw 172.16.10.1 - windows domain controller sovi.sk (FQDN dcsrv.sovi.sk) win serv 2008r2
172.16.10.11/24 gw 172.16.10.1 - Cluster1 (FQDN Cluster1.sovi.sk) win serv 2008r2
172.16.10.12/24 gw 172.16.10.1 - Cluster2 (FQDN Cluster2.sovi.sk) win serv 2008r2
172.16.10.13-14/24             - IBM system storage
172.16.10.1                    - VPN router.        
172.16.10.9                    - file server role (NetBios Name ClusterFS)  
10.62.17.130                   - windows domain controller System911.com (win serv 2008r2)

Two servers and storage are parts of failover cluster. Sovi.sk windows domain controller that required for cluster. We are using cluster as failover file server for our internal subnet 172.16.10.0/24. There are a lot of folders with a configured SMB and NTLM permissions for sovi.sk users.

7 workstations (win 7 x64 pro) 172.16.10.101-107/24 gw 172.16.10.1 dns 10.62.17.130 that I described later are take part of our another domain System911.com.

Domain system911 are windows domain controller that located in cloud service (virtual machine VMware) Configurated NAT on 172.16.10.1 is giving our workstations access to domain System911.com (IP 10.62.17.130) but not for sovi.sk servers.

7 Workstations are using accounts of System911.com to logon. Everything are works fine. I am accessing on a file server from this 7 workstations on a file server by Network Path using netbios name \\ClusterFS\Share. Netbios name ClusterFS I write in file hosts of workstation System911.com (before that I create an A record on System911.com domain, but later I remove this). Share is a name of a folder. After I tape this network path windows ask me to enter an user and a password. I am using sovi.sk accounts for example admin@sovi.sk and type a password or sovi\admin and type a password. I prefer a second variant. After that, strange things start to begin. The windows appeared and show a message that "\\ClusterFS\Share is inaccessible error 0x800704cf". After I choose an Diagnose button the share folder appeared! Ok, after that everything works as it should be. But after about a few hours folders becomes inaccessible. I am trying to access to a folder again, the new authorization window appeared that required to input username and password again (input correct username and password don't solve the problem) the authorization window contains a message "The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you." Windows security journal informed about Audit Failure.

An account failed to log on.

Subject:
    Security ID:        NULL SID
    Account Name:       -
    Account Domain:     -
    Logon ID:       0x0

Logon Type:         3  (network access)

Account For Which Logon Failed:
Security ID:        NULL SID
Account Name:       1011120         (this is username of system911.com)
Account Domain:     system911.com

Failure Information:
Failure Reason:     Unknown user name or bad password.
Status:         0xC000006D
Sub Status:     0xC0000064

Process Information:
Caller Process ID:  0x0
Caller Process Name:    -

Network Information:
Workstation Name:   system911-PC1
Source Network Address: 172.16.10.101
Source Port:        57380

Detailed Authentication Information:
Logon Process:      NtLmSsp 
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only):   -
Key Length:     0

I am enable all NTLM audit but it's didn't give any proper information. After reading a lot of forums I discover a lot of answers that this is an attack of NULL SID but it's not. There is no access between subnet 172.16.10.0 and internet. This workstation system911-PC1 and another 6 don't have any viruses. All ports required for working NTLM, SMB, Kerberos are opened on servers and workstations. I even try to disable Firewall on servers and workstations. Network over TCP\IP enabled on network adapters.

Also I can't access to Share folder by IP \172.16.10.9\Share. Cmd command net use \ClusterFS show that the command completed successfully. If I use net use \172.16.10.9 the command show error 1231. This cmd comands I execute on system911-PC1 workstation. Cluster validation tests passes successfully, but with 1 warning, only one accessible subnet (two required as a recommendation).

I don't know how to enable access to folder by IP for example \172.16.10.9\Share. Also I need to know where is authorisation happened when I access to a shared folder on ClusterFS. Where is Authorisation for access to shared folder happened? On ClusterFS or on sovi.sk domain, or on system911.com domain? When my workstations trying to access to shared folders on ClusterFS who asking about authorisation, ClusterFS, Sovi.sk domain or system911.com domain? I can't configure an interforest trust between, because system911.com domain gives to me from another company as a service. Seems like NTLM problems. But as I described later everything works fine for a few hours. About error "The system detected a possible attempt to compromise security." The system of File server detects an attempt or system of workstation? Any thoughts about why after a few hours folders becomes inaccessible?

windows-server-2008-r2
network-share
server-message-block
failovercluster
ntlm
asked on Server Fault Nov 17, 2020 by John Constantine

1 Answer

1

OP reports: "The problem has been solved. I asked the firm to configure a NAT on hardware vpn gateway to give my servers acces to a cloud service. Now servers are part of System911 domain. Everything works fine without any security warnings. The only question that don't been solved is ntlm authorisation between two unsubordinated domains."

answered on Server Fault Jan 15, 2021 by user612579 • edited Jan 15, 2021 by Andrew Schulman

User contributions licensed under CC BY-SA 3.0