NetApp Filers and vFilers generating Netlogon Event ID 5722 errors on Windows 2008 R2 Domain Controllers

I have a customer where the NetApp Filers and vFilers are generating Netlogon Event ID 5722 in the System event log on the Windows 2008 R2 Domain Controllers.

Example:

Log Name:           System
Source:                NETLOGON
Date:                   18/07/2012 11:32:22 AM
Event ID:             5722
Task Category:    None
Level:                   Error
Keywords:           Classic
User:                    N/A
Computer:           dc1.mydomain.com
Description:
The session setup from the computer vfiler1 failed to authenticate. The name(s) of the account(s) referenced in the security database is vfiler1$.  The following error occurred:
The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

Debugging:

• Enabling Netlogon debugging as recommended by Microsoft by running the Nltest.exe command line as documented in KB942564.

Nltest.exe /DBFLAG:2000FFFF

• Review of the Netlogon.log file shows us the following:

07/18 11:32:22 [SESSION] MYDOMAIN: NetrServerAuthenticate entered: vfiler1 () on account vfiler1$ (Negot: 701ff)
07/18 11:32:22 [SESSION] NetrServerAuthenticate3: the client vfiler1$ is asking for NT4 crypto and this server disallows it.
07/18 11:32:22 [MISC] Eventlog: 5722 (1) "vfiler1" "vfiler1$" 0xc0000388 d0706242 73ca0006 205b4f26 3a297e85   Bbp....s&O[ .~):
07/18 11:32:22 [CRITICAL] Failed to get client's address: 0x000006e4
07/18 11:32:22 [SESSION] MYDOMAIN: NetrServerAuthenticate entered: vfiler1 () on account vfiler1$ (Negot: 741ff)
07/18 11:32:22 [SESSION] MYDOMAIN: NetrServerAuthenticate returns Success: vfiler1 on account vfiler1$ (Negot: 741ff)

• Note that even though the time stamps are the same, the Netlogon.log file reads from top to bottom.

Explanation:

• The vFiler first attempts to authenticate using the Windows NT4 cryptography algorithm.
• The Domain Controller disallows it.
• A 5722 (NETLOGON) error is logged in the System Event log with the following Description:
  • The session setup from the computer vfiler1 failed to authenticate. The name(s) of the account(s) referenced in the security database is vfiler1$.
  • The following error occurred: The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.
• The “Failed to get client’s address: 0x000006e4” error simply means that the RPC bind failed (RPC_S_CANNOT_SUPPORT), which is to be expected.
• The vFiler re-attempts the authentication using STRONG KEY SUPPORT as per the 15^th bit in the Client Capabilities NegotiateFlags.

NegotiateFlags is a pointer to a 32-bit set of bit flags in little-endian format that indicate features supported. As input, the set of flags are those requested by the client and SHOULD be the same as ClientCapabilities. As output, they are the bit-wise AND of the client’s requested capabilities and the server’s ServerCapabilities. For more details, see the Netlogon Negotiable Options

Conclusion:

NetApp’s advice in their KB2013862 article to make the change as recommended in Microsoft KB942564 is fairly poor. Whilst this can be successfully enabled for testing purposes, it is not a recommended solution due to the security implications. The NetApp KB article says that “For backward compatibility purposes, a NetApp Filer may try an older version of encryption for the session key during authentication”. Notice the use of the word “may”? However, there is clearly no need to “lower” security to use the older cryptography algorithms compatible with Windows NT, as the Filers and vFilers work as expected. This means that the error is benign and can be ignored. However, as it creates unnecessary errors in the Domain Controller event logs, it would be far better if NetApp added a configuration option to their Data ONTAP Operating System to instruct it to always use STRONG KEY SUPPORT. These unnecessary errors would then be avoided.

For reference, the NetApps were running Data ONTAP 8.0.2. Let’s hope that NetApp address this sooner than later.

Update as of 8^th November 2012:

A friend (Christoph Wegener) pointed me to section 23.7 of the IBM System Storage N series Software Guide Redbook that states “If DNS is not enabled or is configured incorrectly, the domain joining phase either fails or, if a Microsoft Windows Internet-Naming Server (WINS) is running, assumes that the domain being joined is a Windows NT 4.0 domain”. Reading this got me thinking that it could also affect the domain re-authentication process. In this case I have not deployed WINS and NetBIOS is also disabled. However, this may be valuable information when trying to understand why NetApp state that “a NetApp Filer may try an older version of encryption for the session key during authentication”. What if the response back from DNS was slow and timed out? There is nothing logged to prove this. But one certainly has to wonder if this is indeed a bug, or simply that a condition has been met that forces it to use an older version of encryption for the session key during authentication. It would be nice to get some input from someone at NetApp that has a complete understanding of this process.

• Bio
• Twitter
• LinkedIn
• Latest Posts

Jeremy Saunders

Technical Architect | DevOps Evangelist | Software Developer | Microsoft, NVIDIA, Citrix and Desktop Virtualisation (VDI) Specialist/Expert | Rapper | Improvisor | Comedian | Property Investor | Kayaking enthusiast at J House Consulting

Jeremy Saunders is the Problem Terminator. He is a highly respected IT Professional with over 35 years’ experience in the industry. Using his exceptional design and problem solving skills with precise methodologies applied at both technical and business levels he is always focused on achieving the best business outcomes. He worked as an independent consultant until September 2017, when he took up a full time role at BHP, one of the largest and most innovative global mining companies. With a diverse skill set, high ethical standards, and attention to detail, coupled with a friendly nature and great sense of humour, Jeremy aligns to industry and vendor best practices, which puts him amongst the leaders of his field. He is intensely passionate about solving technology problems for his organisation, their customers and the tech community, to improve the user experience, reliability and operational support. Views and IP shared on this site belong to Jeremy.

@jeremysaunders

Follow @jeremysaunders

Latest posts by Jeremy Saunders (see all)

• Best Practice for the Active Setup StubPath value - September 25, 2023
• User Profile Migration Strategy and PowerShell Script with a User Interface - August 28, 2023
• Cold Starting and/or Hydrating Your Applications To Improve Their Startup Times - June 27, 2023

Tagged as: Domain Controller, Filers, NetApp, Netlogon 5722, NT4 crypto, NT4 cryptography algorithm, STRONG KEY SUPPORT, vFilers, Windows 2008