I've come a bit further troubleshooting this issue. I ran a wireshark on the domain controller to see what's going on. Everything stops after the netapp filer's CIFS setup is sending a SMB Negotiate Protocol Request to the domain controller. The filer's CIFS is requesting a SBM1 session (NTLM 0.12 dialect), but the domain controller never sends a SMB Negotiate Protocol Response which it should do. The only thing happening after this (in wireshark) is LDAP communication that deletes the filer's computer object from Active Directory.
Another development is that it works to join the same netapp to the Active Directory in our test environment. I ran a wireshark on the domain controller in our test environment as well and here the domain controller does send a SMB Negotiate Protocol Response accepting the SMB1 session after which the process continues and completes successfully.
Another observation. We have another netapp cDOT filer which managed to join our production Active Directory a few weeks ago. Now when I run the command "cifs domain discovered-servers show" on this filer, domain controller "dc1.ad.domain" is listed as "unreachable". Next I created a new svm on this filer and ran "cifs create..." and it is having the same problems as the other filer: "Unable to make a NetLogon connection to dc1.ad.domain using the new machine account".
So a couple of things are actually pointing at some kind of problem with this specific domain controller. The thing is that it is working fine for our Windows clients and the server is not reporting any problems in the event logs. It seems to be working fine. The question is why it is not completing the SMB communication with our netapp filer during the cifs create process?
The problem was caused by an AD domain entry in the filer's local database for our test environment. Our AD in the test environment happens to have the same short name as our AD in the production environment. Earlier we were testing this filer and added it to the AD in our test environment. This created an entry somewhere in the filer that did not go away even though we removed the CIFS setup. When we wanted to add the filer to our production AD this "hidden" entry was conflicting.
I'm Sorry for the bump, but I'm curious if you have any more information regarding the conflicting 'hidden' entry in the filer.
It looks like I encountered the same problem with 2 different filers (one running cdot 8.2p4, the other 8.3.2). When trying to join the ad the error message and total trace looks identical to the one you mention. So I'm curious what exactly was causing the problem. The domain they are trying to join is the same, but both use different domain controllers to execute the join.
@RUTGERBLOM: Thanks alot for taking the time to answer! I can totally understand why that was the cause for you. We are having the exact same error; the computer account is created correctly in the AD, but the NetLogon part fails with "Socket receive error". We've done secd debug traces and are currently investigating this with NetApp, but progress is slow. Unlike you, this is our first attempt to connect the filer to the AD, so unfortunately the solution for your issue does not apply to us.
Is it a 2012 domain ? Possibly not the same issue, but we had a number of issues with c-mode 8.2 not supporting LDAP-S (or LDAP over SSL)...filer would create the account but was unable to join the domain. Turn off LDAP-S on the DC's and it worked fine (there was another setting we had to change but I am struggling to remember it)
I believe LDAPS is supported in 8.2.1, so maybe check to see if it is enabled on the DC's or the Sotrage