Hi everyone,
Hopefully someone can point me in the right direction as this is getting really old and my support ticket is going absolutely nowhere yet..
We have a standard CIFS share setup on our FAS8040, running Clustered OnTAP 9.1P1.
And most of the time - everything works just fine without any errors but every now and then we get an error trying to connect to the folders on the CIFS share. Error message says that our AD account is "currently disabled", which it's not of course. If I had to take a stab at it, I'd say this happens maybe once out of every 20-100 times we run that particular script.
This seems to happen only on 2008r2 servers, but honestly I do not know at this time if we have any other OS versions running this same script. I'll find out.
And, might be related - or not, I see that when I open the share in file explorer (\\cifs-server\share), it takes over 1 minute to open but then it's fine and browsing through the folders is normal. But if I close the explorer window and wait about 20 sec + and try again, same thing happens all over again.
At first, I thought we were running into Kerberos Max Token Size issue since it's 2008 R2 machines. But looking at the logs, the connection is using NTLMv2 so even though I have changed that setting. it did nothing for this specific issue.
The account that is being used is a member of a large number of groups, so it would've made sense for the Token Size issue but that is only for Kerberos tickets as far as I know.
Here's an extract from secd.log when the AD account return "Disabled":
00000027.01394212 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.012.163] info : Successfully authenticated with DC DCNAME.domain.com { in connectToDomainController() at src/connection_manager/secd_connection.cpp:289 }
00000027.01394213 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.012.177] debug: Connecting to share \\DCNAME\ipc$ { in pclConnectToShare() at src/utils/secd_connection_utils.cpp:95 }
00000027.01394214 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.012.710] debug: Succeeded; open tid: 36871 { in pclConnectToShare() at src/utils/secd_connection_utils.cpp:117 }
00000027.01394215 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.012.746] debug: Using Cached scKey for vs12:DCNAME { in getSecureChannelKey() at src/configuration_manager/secd_configuration_manager.cpp:2416 }
00000027.01394216 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.012.767] debug: SChannel key for DCNAME already established { in ensureSChannelKeyEstablished() at src/connection_manager/secd_connection.cpp:348 }
00000027.01394217 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.012.775] debug: pclOpenFile: Opening file \netlogon over tid 36871 { in pclOpenFile() at src/utils/secd_connection_utils.cpp:165 }
00000027.01394218 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.013.470] debug: pclOpenFile: Succeeded; open fid: FID-[type=SMB1]-[SMB1=32769]-[SMB2=0:0] { in pclOpenFile() at src/utils/secd_connection_utils.cpp:222 }
00000027.01394219 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.013.478] debug: Binding to \netlogon { in connect() at src/connection_manager/secd_connection.cpp:1233 }
00000027.0139421a 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.013.520] debug: Using Cached scKey for vs12:DCNAME { in getSecureChannelKey() at src/configuration_manager/secd_configuration_manager.cpp:2416 }
00000027.0139421b 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.014.475] debug: Successfully bound to \netlogon { in connect() at src/connection_manager/secd_connection.cpp:1273 }
00000027.0139421c 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.014.493] debug: Connected to new NetLogon service on DCNAME.domain.com { in makeConnectionAttempt() at src/connection_manager/secd_connection_manager.cpp:1020 }
00000027.0139421d 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.014.689] debug: Attempting pass-through auth with DC DCNAME. { in doAuthenticateWithDC() at src/authentication/secd_seclibglue.cpp:1077 }
00000027.0139421e 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.039.105] info : Authentication failed with DC DCNAME. Not retriable. (Status: 0xc0000234) { in doAuthenticateWithDC() at src/authentication/secd_seclibglue.cpp:1103 }
00000027.0139421f 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.039.227] info : Login attempt by local user 'DOMAIN\username' using NTLMv2 style security
00000027.01394220 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.039.289] info : User is not known
00000027.01394221 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.039.314] debug: acceptContext return state: 2, output blob length: 15, ntstatus 0xc0000064 { in secd_rpc_auth_extended_1_svc() at src/authentication/secd_rpc_auth.cpp:1172 }
00000027.01394222 09e19cec Tue Oct 03 2017 17:00:01 -07:00 [kern_secd:info:7929] | [000.039.340] debug: SecD RPC Server sending reply to RPC 151: secd_rpc_auth_extended { in secdSendRpcResponse() at src/server/secd_rpc_server.cpp:1888 }
Any thoughts, tips or pointers would be greatly appreciated. As mentioned, I have a support ticket opened with NetApp but it's been going nowhere for a couple of weeks now and I honestly don't know if this is a NetApp issue or somewhere else at this time.
Thanks!
Tom
