Bug 11291 - NetApp joined to a Samba/ADDC cannot resolve SIDs
NetApp joined to a Samba/ADDC cannot resolve SIDs
Product: Samba 4.1 and newer
Classification: Unclassified
Component: DCE-RPCs and pipes
All All
: P5 normal
: ---
Assigned To: Karolin Seeger
Samba QA Contact
: 11246 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2015-05-27 10:16 UTC by Arvid Requate
Modified: 2015-08-24 18:24 UTC (History)
7 users (show)

See Also:

0001-s4-rpc_server-netlogon-Fix-for-NetApp.patch (2.81 KB, patch)
2015-05-27 10:16 UTC, Arvid Requate
no flags Details
0001-s4-rpc_server-netlogon-Fix-for-NetApp.patch (2.86 KB, patch)
2015-08-06 13:04 UTC, Arvid Requate
no flags Details
Patch for v4-3-test (3.20 KB, patch)
2015-08-06 18:50 UTC, Stefan Metzmacher
metze: review? (abartlet)
jra: review+
asn: review+
Patch for v4-2-test (3.20 KB, patch)
2015-08-06 18:50 UTC, Stefan Metzmacher
metze: review? (abartlet)
jra: review+
asn: review+

Note You need to log in before you can comment on or make changes to this bug.
Description Arvid Requate 2015-05-27 10:16:46 UTC
Created attachment 11089 [details]

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 

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.
Comment 1 Arvid Requate 2015-05-27 10:19:05 UTC
Maybe this is the same issue as reported in Bug #11246
Comment 2 Lutz Willek 2015-05-27 23:26:18 UTC
(In reply to Arvid Requate from comment #1)
Comment 3 Lutz Willek 2015-05-28 00:22:30 UTC
(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.


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 


Lutz Willek
Comment 4 Luca Olivetti 2015-06-02 11:02:04 UTC
*** Bug 11246 has been marked as a duplicate of this bug. ***
Comment 5 Luca Olivetti 2015-06-02 11:02:45 UTC
Still valid in 4.2.2
Comment 6 Volker Lendecke 2015-07-09 07:08:34 UTC
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 7 Stefan Metzmacher 2015-07-09 07:30:59 UTC
Comment on attachment 11089 [details]

The patch looks good to me
Comment 8 Stefan Metzmacher 2015-07-09 07:32:20 UTC
(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.
Comment 9 Arvid Requate 2015-07-09 13:32:37 UTC
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?
Comment 10 Arvid Requate 2015-07-14 16:30:41 UTC
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?
Comment 11 Jeremy Allison 2015-07-31 19:54:48 UTC
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.
Comment 12 Jeremy Allison 2015-07-31 19:58:36 UTC
Arvid, can you resend this with your 'Signed-off-by:' added please ? That way we can get it into master and all released branches.
Comment 13 Stefan Metzmacher 2015-08-06 10:52:41 UTC
(In reply to Jeremy Allison from comment #12)

Yes, a missing test should not hold it back...
Comment 14 Arvid Requate 2015-08-06 13:04:00 UTC
Created attachment 11314 [details]
Comment 15 Stefan Metzmacher 2015-08-06 18:50:05 UTC
Created attachment 11318 [details]
Patch for v4-3-test
Comment 16 Stefan Metzmacher 2015-08-06 18:50:37 UTC
Created attachment 11319 [details]
Patch for v4-2-test
Comment 17 Andreas Schneider 2015-08-17 07:55:53 UTC
Comment on attachment 11319 [details]
Patch for v4-2-test

Comment 18 Stefan Metzmacher 2015-08-17 14:12:40 UTC
Pushed to autobuild-v4-{2,3}-test
Comment 19 Stefan Metzmacher 2015-08-18 11:36:42 UTC
Pushed to v4-{2,3}-test