Created attachment 11089 [details] 0001-s4-rpc_server-netlogon-Fix-for-NetApp.patch The attached patch fixes an issue where a NetApp filer joined to a Samba/ADDC cannot resolve SIDs. Without this patch the issue can only be avoided by setting "allow nt4 crypto = yes" in smb.conf. Details are described in the git commit message. Additional logs of the issue can be found at the original bug report https://forge.univention.org/bugzilla/show_bug.cgi?id=37874 Metzes git commit 321ebc99b5a00f82265aee741a48aa84b214d6e8 introduced a workaround for a different but related issue. This patch makes a minor adjustment to that commit to delay flushing the cached challenge until it's clear that we are not in a NT_STATUS_DOWNGRADE_DETECTED situation. This bug has been observed with 4.0.2-rc2 but the patch (posted to the mailing list 19.03.2015 20:38) still applies to 4.2.1.
Maybe this is the same issue as reported in Bug #11246
(In reply to Arvid Requate from comment #1) yes
(In reply to Arvid Requate from comment #0) some additional informations. Netapp Bug 599507: http://mysupport.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=599507 (netapp login required) Description: A request has been submitted to add configurable options in Data ONTAP to allow the domain controller, acting as a client, to use the required encryption methods by default (e.g., RC4-HMAC) instead of first negotiating older cryptography methods. Fixed-In ONTAP Version: This bug is not scheduled to be fixed... --- The behavior described in NetApp Bug 599507 is very easy to follow, you can observe it with Samba debug level 12 in the input and output of netr_ServerAuthenticate2 function, the flag is NETLOGON_NEG_STRONG_KEYS and part of the negotiation flags during authentication. The result: Only after the first connection has failed and refused, the NetApp retried a challenge, this time with strong keys. --- Analysis: If the AD is rejecting this attempt, the next highest security level is attempted. According to analysis, the NetApp Filer acts against a Windows (2008R2) DC exactly identical, ie first trying an authentication challenge without strong keys. fun fact: The behave of Windows clients and servers including samba is diametrically (they trying an authentication challenge with strong keys first) --- Netapp Support: ...we indeed send a "weak" negotiate first and after that a "strong" one. This is hardcoded in ONTAP and can't be changed with any parameters; it's done to ensure backwards compatibility... ... is that we introduced this feature when testing Windows Longhorn (2008) with internal case 245412 (we actually added strong encryption). Unfortunately this one isn't public.... --- The real problem is that the (current) Samba code already cleared the old challenge at the time of the second connection attempt, because the authentication has been rejected without strong keys. As a result, Samba cant find a challenge for authentication anymore, ending with message "No challenge requested by client [HOSTNAME / HOSTNAME$], Can not authenticate" and terminates the connection. (dcerpc_netlogon.c) I do not think ONTAP is "wrong" here because the exactly same procedure against an Windows DC doing well. Based on this analysis, the solution is to ensure that the challenge is rejected only if it is clear it is not a "downgrade situation" --> see patch in comment #0 Regards Lutz Willek
*** Bug 11246 has been marked as a duplicate of this bug. ***
Still valid in 4.2.2
I know it's an easy to make request, but I'd love to see this supported with a smbtorture test to prove that Windows accepts this. Also, it will make it easier to convince Metze and Andrew that this is okay :-) Arvid, would that be possible?
Comment on attachment 11089 [details] 0001-s4-rpc_server-netlogon-Fix-for-NetApp.patch The patch looks good to me
(In reply to Volker Lendecke from comment #6) Yep, a test for with would be great. We also need a BUG: reference and a sign off on the patch.
I don't have much experience in writing testsuite cases. Are there any howtos? Also in cases like these (e.g. also Bug 11392), where adjustments are required for vendor specific protocol variations, what's the "best practice" approach to simulate what has been found in the network traces?
Ok, I'll see how far https://wiki.samba.org/index.php/Writing_Torture_Tests will get me. Any ideas how to simulate the network traces?
Metze already +1'ed this patch, so I don't think we should make a test a blocker for this fix - although it'd be nice to have.
Arvid, can you resend this with your 'Signed-off-by:' added please ? That way we can get it into master and all released branches.
(In reply to Jeremy Allison from comment #12) Yes, a missing test should not hold it back...
Created attachment 11314 [details] 0001-s4-rpc_server-netlogon-Fix-for-NetApp.patch
Created attachment 11318 [details] Patch for v4-3-test
Created attachment 11319 [details] Patch for v4-2-test
Comment on attachment 11319 [details] Patch for v4-2-test LGTM
Pushed to autobuild-v4-{2,3}-test
Pushed to v4-{2,3}-test
(In reply to Stefan Metzmacher from comment #13) I nearly broke this because no test was added. Can we please not accept such patches without tests?