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

by Jeremy Saunders on August 7, 2012

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 15th 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

 

The 32-bit Binary Representation of the Client Capabilities NegotiateFlags

701ff hex 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1
Options S R I G C
741ff hex 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 0 1 0 0 0 0 0 1 1 1 1 1 1 1 1 1
Options S R O I G C

Option

Meaning

C

Supports RC4 encryption.

G

Does not require ValidationLevel 2 for nongeneric passthrough.

I

Supports RefusePasswordChange.

O

Supports strong keys.<67>

R

Supports the NetrServerPasswordSet2 functionality.<69>

S

Supports the NetrLogonGetDomainInfo functionality.<70>

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 8th 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.

Jeremy Saunders

Jeremy Saunders

Independent Consultant | Contractor | Microsoft & Citrix Specialist | Desktop Virtualization Specialist at J House Consulting
Jeremy is a highly respected, IT Professional, with over 30 years’ experience in the industry. He is an independent IT consultant providing expertise to enterprise, corporate, higher education and government clients. His skill set, high ethical standards, integrity, morals and attention to detail, coupled with his friendly nature and exceptional design and problem solving skills, makes him one of the most highly respected and sought after Microsoft and Citrix technical resources in Australia. His alignment with industry and vendor best practices puts him amongst the leaders of his field.
Jeremy Saunders
Jeremy Saunders
Jeremy Saunders
  • Shoaib

    Hi Jeremy,
    We recently bought Netapp FAS2220 v 8.1.1RC1 7-Mode and joined to domain windows 2008 R2 and getting the same NETLOGON error as above everyday.

    What I understand from the above that the error can be ignored?? Is that correct?? Or there is any solution to this problem?
    Shoaib

    • Jeremy

      Hi Shoaib,

      Correct. Ignore the error.

      Cheers,
      Jeremy.

  • Gordon

    We’re also getting this error, maybe not so coincidentally, mapping a cifs share to the file takes a lot longer than other filers and this is the only filer producing the error. You may be on the right track with WINS as we run it for backward compatiblity. I wish NetApp would fix this one.

    • Hi Gordon,

      Thanks for your comment. Mapping to CIFS shares on the NetApp Filers is indeed slow, hampering the login process. I’ve also seen file save issues from Excel and Word. That’s another blog 🙂 However, I’m interested to know what other Filers you’re comparing it too?

      Cheers,
      Jeremy

  • Gordon

    All our filers are NetApp. Of the ones holding CIFS, the larger which never seems to have mapping issues is a 3240, the smaller 2040 has had issues ever since install with slow mappings. Past firmware updates seem to have made no difference, though I do know it’s a bit behind now. The only other difference I can tell is that the hostname of the larger filer has been in use ever since NT4 domain days, the smaller hostname was introduced after we had decommissioned NT4 and moved to AD DNS and WINS

Previous post:

Next post: