Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Wednesday, August 21, 2019 9:56 AM
Windows 10 1709 just performed August Cumulative updates (and some office).
After a reboot, some of our machines are spamming our SAN and taking up thousands of connections.
The SMBClient > Security Event Log is filled with:
Error / SMBClient / 31001
An attempt to initialize a security context failed.
Error: An invalid parameter was passed to a service or function.
Security status: 0x80090308
User name:
Logon ID: 0x13A822F
Server name: \my-server
Principal name: cifs/my-server1UWhRGBAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAsubdomain.domain.comICAAAA
The specific share is basically users home drives. It also contains another drive which is mapped through a login script.
If looks as if the Principal name is malformed, what with all the extra characters.
Our SAN connections are showing a possible corresponding error:
SSXAK()=TOO_MANY_SESSIONS Client=client.ip.address.here origin=699 stat=Miscellaneous failure. ASN.1 identifier doesn't match expected value.
A quick netstat command shows only one TCP conecction to the IP address of the share.
We are stumped on why this is happening, seems related to the updates but these are big security updates this month.
All replies (5)
Wednesday, August 21, 2019 6:56 PM
Hello MrBeatnik,
Do you have any idea where the share path is coming from? An AD homeDirectory value, a script?
The target principal name will be constructed from the server name as it appears in the UNC path.
The error code (SEC_E_INVALID_TOKEN) is a bit odd too. I would not expect even passing an such an unusual target name to InitializeSecurityContext to generate that error.
Gary
Thursday, August 22, 2019 1:46 PM
Both AD homedirectory and a script map to the share area, albeit different folder names underneath.
We use a share (DFS) that sits infront of this cifs share, so it is DFS that is presenting the underlying name.
Thursday, August 22, 2019 6:36 PM
Hello MrBeatnik,
Sorry, we seem to have misunderstood each other. I wanted to know if there is any possibility that the server name "my-server1UWhRGBAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAsubdomain.domain.comICAAAA" could have appeared in any "net use" command or UNC path. Normally, the "principal" name is constructed from this input (the server name in the UNC path). I guess that you have edited this string to conceal your company name but in this case (as in many others), it makes providing assistance more difficult. The repeated "AAAA" pattern looks like something that would result from base64 encoding an authentication data structure ("AAAA" is 3 zero bytes base64 encoded), but the string editing makes estimating the plausibility of this interpretation impossible.
One could try using Event Tracing for Windows (ETW) to try to understand what is happening, but the interpretation of the trace output is difficult. If one is not prepared to share the actual error relevant data in this small group (45 views of this thread in 36 hours), then it is unlikely that one would share the even more revealing ETW trace data.
Gary
Friday, August 23, 2019 3:21 PM
I agree that it does look like BASE64, a few characters are different in some log entries.
Yes, I have edited the domain name, but I can't imagine why the real name would assist as that's not obfuscated as the apparent BASE64 string is. Anything in particular you are thinking about that I'm overlooking?
The server name should actually be in the format myserver.domain.com (note no subdomain).
We have an additional DNS search suffix of subdomain.domain.com, so it almost appears to be doing a search with the suffixes (perhaps it only has the name "myserver" to deal with and trying to build the FQDN). It certainly wouldn't be able to reach the server with that FQDN as it doesn't reside in the subdomain.
The servername, malformed or not, certainly does not appear in any net use command or UNC path.
netstat also does not show that connection.
The only connection we make is to \subdomain.domain.com\share - presented as DFS and connecting to myserver.domain.com in the background. We never try to connect to that FQDN directly at any point.
We are currently in support with MS. I'll update when (if!) I have an answer, but I appreciate any further help in the mean time.
Friday, August 23, 2019 6:06 PM
Hello MrBeatnik,
There is obviously not much low level information to be gleaned from the data that you made available. In this case, even the smallest hints such as total string length, result of interpreting some string fragments as base64, etc. are all that there is to cogitate about.
What I would try is using Event Tracing for Windows (ETW) to trace what is happening - even if this means using an AutoLogger session (https://docs.microsoft.com/en-us/windows/win32/etw/configuring-and-starting-an-autologger-session) to capture what happens during startup/logon.
Just for fun, I added my-server1UWhRGBAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAsubdomain.domain.comICAAAA to my hosts file and traced what happened.
Here was the first reference to that server (I had issued the command "dir \my-server1UWhRGBAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAsubdomain.domain.comICAAAA\C$"):
The SMB processing starts in earnest here:
There is lots of information here; we can see the SPN being built (BuildSpn) and the InitializeSecurityContext invocations and results in routine BuildSessionSetupSecurityBlob (two rounds of status 590610 = 0x90312 = SEC_I_CONTINUE_NEEDED, followed by success (0) - the typical NTLM pattern).
Dipping into the SMB packets, we can see the SMB2_NETNAME_NEGOTIATE_CONTEXT_ID in the negotiate exchange and the security buffers in the session setup exchanges:
A trace like that of the behaviour on you systems would provide substantially more food for thought, possibly showing when the odd name first shows up (my current guess is that the file server is responsible for introducing it)...
Gary