CIFS setup problem

[RUTGERBLOM]

8.2.1

I'm having trouble adding a FAS8020 to Active Directory. I've checked all the basic things like routes, DNS and IP connectivity and it all looks good, but I receive this error:

cifs create -cifs-server NETAPP03 -domain ad.domain

Error: Machine account creation procedure failed

  [   622] Loaded the preliminary configuration.

  [   791] Created a machine account in the domain

  [   791] SID to name translations of Domain Users and Admins

           completed successfully

  [   906] Kerberos password set for 'NETAPP03$@AD.DOMAIN' succeeded

  [   906] Set initial account password

  [   908] Connecting to NetLogon server dc1.ad.domain

           (192.168.227.10)

  [   909] Unable to connect to dc1.ad.domain through the

           192.168.227.50 interface

**[   909] FAILURE: Unable to make a NetLogon connection to

**         dc1.ad.domain using the new machine account

  [   916] Deleted existing account

           'CN=NETAPP03,CN=Computers,DC=ad,DC=domain'

Error: command failed: Failed to create the Active Directory machine account "NETAPP03". Reason: Socket receive error.

[RUTGERBLOM]

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?

Cheers!

[graemeharney]

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

[graemeharney]

I should add for a new system, LDAP-S Seems  to be enabled, for one upgraded from 8.2 it is disabled

[deltamanagement]

@RUTGERBLOM : Did you ever solve this? We have the same issue. Could it be a windows update that somehow caused the NetApp -> AD connection mismatch?

[RUTGERBLOM]

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.

NetApp support had to fix this.

Best regards,

Rutger

[deltamanagement]

@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.

Regards,

Johan Karlsson

Delta Management

[omougin]

Hello,

This post is old, but did you solved your issue and how did you solved it ?

Regrds

[Bram]

@RUTGERBLOM

Hello Rutger,

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.

Thank you in advance.

[xdesloovere]

Rutger,

Have you been able to resolve this since we are having the same issue.

Friendly regards,

Xavier

[clackamas]

Check to see if the time is in sync.  I don't know about cDOT but in 7 mode cifs setup fails if the filers time is off by more than 5 minutes from the AD server.

[PETER1971]

I encountered similar issues when trying to register the CIFS against the Domain Controllers that has multiple network interfaces (and IP's in different subnets).

After some troubleshooting, I came up with the following solution:

If the AD has multiple network interfaces (and subnets), the vServer CIFS fails to register against it, it starts complaining about ldap unreachable.

What I did to solve this:

- change the GPO (default domain policy) to disable ldapsigning required

- disable all network interfaces on the domain controllers except the one used by CIFS.

- reboot domain controllers.

This way, it will register correctly. Afterwards you can enable all nics again.

But still this is not how it should be, I now get messages in the log complaining about a failure to reach the AD but the clients still seem to access the CIFS shares.

So next step is to add prefered DC's, this seems to help keeping the connection to the DC's reachable. but still gives me unreachable on those IP's:

Vserver        Domain Name                   Preferred Domain Controllers

-------------- ----------------------------- ----------------------------------

vs_hllc        HLMWEB.LOCAL                  172.25.8.23, 172.25.8.24

and the discovered servers:

  Domain Name     Type     Preference DC-Name         DC-Address      Status

--------------- -------- ---------- --------------- --------------- ---------

hlmweb.local    MS-LDAP  preferred  hllc023         10.0.0.23       OK

hlmweb.local    MS-LDAP  adequate   hllc024         10.0.0.24       undetermined

hlmweb.local    MS-DC    adequate   hllc023         172.25.8.23     unreachable

hlmweb.local    MS-DC    adequate   hllc024         172.25.8.24     unreachable

4 entries were displayed.

The AD/DNS is pingable and reachable on the 172.25.8 network, not on the 10.0.0 network so it's very strange that it says 10.0.0.23 is OK!

Someone else also encountering similar issues?

[marcosnet]

I'm having the same problem. Did you solve it ?