First published on CloudBlogs on Dec, 12 2008
We have a temporary role in CSS where support folks will help out in supporting prerelease (also known as beta) software. I’ve worked a couple of Windows betas, and it’s a great experience. I mention this since I remember a few years ago during the beta of a prior Windows release where there was an initiative to make the errors that would appear in Windows less scary sounding.
Most people can recall the infamous problem descriptions like “fatal error”. Fatal sounds pretty final, doesn’t it? Tough to recover from “fatal”.
But really that’s the point of this blog post. Though we try very hard to make things intuitive and not frightening sounding, not all of our errors or problem descriptions end up sounding like they really should.
Here’s a case in point. One of my colleagues asked me to check into some events that a customer had some concern over. They weren’t seeing an actual failure of service, they simply wanted to make sure that these events (which would occur in pairs intermittently) didn’t mean something really bad. Because they sounded pretty scary.
12/1/2008 10:43:33 AM
LSASRV Warning SPNEGO (Negotiator)
40961 N/A Server21
The Security System could not establish a secured connection with the server cifs/Server12.child.adatum.com. No authentication protocol was available.
12/1/2008 10:43:33 AM
LSASRV Warning SPNEGO (Negotiator)
40960 N/A Server21
The Security System detected an attempted downgrade attack for server cifs//Server12.child.adatum.com. The failure code from authentication protocol Kerberos was "There are currently no logon servers available to service the logon request.
The scary part is the phrase “downgrade attack”. Let’s face it-the only time an attack isn’t a bad thing necessarily is when it’s a Big Mac Attack. Hmmmm. Big Mac.
Anyway, let’s stay focused here. What is a “downgrade attack”? And why were these events occurring?
This error occurred as a result of the computer Server21
trying to access a file resource on the remote server Server12.child.adatum.com. The negotiated authentication protocol for that connection was Kerberos. Unfortunately, after that negotiation between the client and that remote server Server12.child.adatum.com occurred, the client (Server21) was unable to request the needed Kerberos ticket cifs/Server12.child.adatum.com because there were no DCs available at that moment to send the request to.
Why was that? Don't know. It could have been a temporary or transient issue on the DC side, the network between client and DC, a trust issue, a DNS issue, or even a performance issue on the DC. The general idea is that the DC locator running in the Netlogon service of the client in this case was aware it couldn’t find a DC for the child.adatum.com domain at that time.
So why is this termed an “attack”? It probably shouldn’t be. Whatever client side code on Server21 which instigated the need to access some file on Server12.child.adatum.com probably just tried once to access the file, relying on the security subsystem to negotiate the authentication to that resource. When that failed it didn’t automatically fail over to NTLM necessarily-unless the application side allowed said to. It’s possible that the connection did or would succeed using NTLM (which is less secure) since NTLM doesn’t require communication with a domain controller. Yes-access to that file resource may have actually succeeded seamlessly other than the above events after all. So this isn’t an attack, but certainly is not a preferable thing to have happen. Maybe we should call it an obstruction or failure.
To troubleshoot this scenario, if I was seeing it intermittently or even very consistently, I would start by
enabling Netlogon debug logging
on the client (in this case Server21) and look to see what behavior or error codes are shown in that log for the time indexes which correspond to the same time as the above events.
That’s not all
that
scary, now, is it?
