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