CIFS server can't join AD

[ddrougeau]

I know this has probably been answered somewhere...but I can't find it.  I'm new to NetApp and though this simulator would be a great way to learn since our company is considering their solutions.  I have the initial cluster setup, aggregate, subnet, and vserver.  but when I try to create the CIFS server and join it to my lab DC, I get this error about the LSA service

Data ONTAP API Failed :Failed to create the Active Directory machine account "CIFS". Reason: SecD Error: no server available Details: Error: Machine account creation procedure failed [ 105] Loaded the preliminary configuration. [ 121] Created a machine account in the domain [ 121] Connecting to LSA server netappdc.netapp.loc (192.168.111.5) [ 123] Cluster and Domain Controller times differ by more than the configured clock skew (KRB5KRB_AP_ERR_TKT_NYV) [ 123] Failed to initiate Kerberos authentication. Trying NTLM. [ 124] Successfully authenticated with DC netappdc.netapp.loc **[ 125] FAILURE: Unable to connect to LSA service on ** netappdc.netapp.loc (Error: ** RESULT_ERROR_CIFS_SMB_ACCESS_DENIED) [ 125] No servers available for MS_LSA, vserver: 3, domain: netapp.loc. [ 125] Could not find Windows SID 'S-1-5-21-3619059543-1436041144-4270238130-512' [ 128] Deleted existing account 'CN=CIFS,CN=Computers,DC=netapp,DC=loc' . (Error: 13001)

Any help is seriously appreciated...

[aborzenkov]

You need to synchronize time between servers that are part of Windows domain (actually, Kerberos realm). It has really nothing to do with NetApp.

[ddrougeau]

Thanks for responding. I only have one server and it's the DC so there isn't anything to sync on the windows side. The cluster is showing the correct time, but the time zone is etc/utc which isn't correct since I'm in Seattle. When I change the time zone to US/Pacific on system manager, the time is off by several hours.

[aborzenkov]

NetApp is just a server from Windows point of view and must have correct time that match domain controller.

[mbeattie · Accepted solution]

Hi,

Have you tried setting your timezone to closest city to you listed in the link below:

https://library.netapp.com/ecmdocs/ECMP1368852/html/GUID-48AD434D-433B-4208-8D9E-C3696707E20C.html

Before you can join the vserver to the domain you first need to set the date\time and timezone to ensure the systems time is within 5 minutes of your domain controller.

To check the time on your DC you can use the net time command:

C:\>net time \\testdc01
Current time at \\testdc01 is 23/07/2015 6:26:37 PM

The command completed successfully.

Then set the date on your cluster:

cluster1> system date modify -dateandtime 201507231826.48

cluster1> system date show
Node      Date                      Time zone
--------- ------------------------- -------------------------
node1
          7/23/2015 18:26:53 +10:00 Australia/Sydney

Then set your timezone

cluster1> timezone America/Vancouver
1 entry modified

cluster1> system date show
Node      Date                      Time zone
--------- ------------------------- -------------------------
node1
          7/23/2015 01:27:12 -07:00 America/Vancouver

Also it's worth mentioning that you will need to enter credentials of an Active Directory user account during the cifs setup process that has permissions in Active Directory to create the computer object and join the vserver to the domain.

The minimum required Active Directory permissions for computer objects in your organizational unit are:

http://support.microsoft.com/kb/932455

Create Computer Objects

Reset Password

Read and write Account Restrictions

Validated write to DNS host name

Validated write to service principal name

hope this helps

/matt

[aborzenkov]

---

you first need to set the date\time and timezone to ensure the systems time is within 5 minutes of your domain controller

---

Time zone is irrelevant; but quite a lot of people confuse computer time with wall clock time. This is true only as long as time zones are set identically indeed. All servers must have the same time when converted to UTC. IOW if server A is 3 hours east of Greenwich and has time 7pm and server B is 3 hours west of Greenwich and has time 1pm then both servers actually have the same time (4pm UTC time). Of course if someone now tries to "correct" time on server B by setting it to 7pm it becomes totally wrong.

[RPHELANIN]

if this is simulator have a look at the Time Settings on the ESXi host and then ssh to the ESXI host and run the date command and verify they are the same. If the are different the simulator is most liley picking up the incorrect time.

[ddrougeau]

Thanks mbeattie and everyone for the responses.  Once I changed the timezone/time it joined the domain immediately.  I'm new to Data ONTAP CLI so I was missing the syntax for this.  Interestingly I had to change the zone first, then the time or it would throw the time off by 7 hours.

-duane

[ddrougeau]

I guess it all makes sense.  UTC to the simulator is my desktop system's time so changing the time zone on the cluster was in reference to my system time...throwing it off several hours.

[BradStoltzTA]

If you have disabled SMBv1 on your domain controllers

you need to make sure you have your SVM set to use SMB2 for Domain Controller Connection.

We disabled SMBv1 across the organisation in order to prevent any potential issues with the recent ransomeware exploits of SMBv1 (Petya and WannaCry)

Run the following command sets the SVM to use SMB2 and disable SMB1, and you will be able to join the AD domain with SMBv1 disabled on the domain controller. (you must be in advanced privelege mode to run this command [set advanced])

cifs security modify -vserver <SVM-Name> -smb1-enabled-for-dc-connections false -smb2-enabled-for-dc-connections true

Hope this saves someone else the several hours i spent pulling my hair out today trying to resolve.

[DCGozer]

Wow - thank you!  I've been messing with this issue for a while now.

[SjorsH]

Unfortunately the options -smb1-enable-for-dc-connections and -smb2-enabled-for-dc-connections are not available on the version I use (NetApp Release 8.3.1P2)

[connoisseur]

Thanks.. this solved my problems.

As Windows AD 2016 seems to have SMB1 disabled by default our customer got alot of problems after updating the AD servers..

---

@BradStoltzTA wrote:

If you have disabled SMBv1 on your domain controllers

you need to make sure you have your SVM set to use SMB2 for Domain Controller Connection.

We disabled SMBv1 across the organisation in order to prevent any potential issues with the recent ransomeware exploits of SMBv1 (Petya and WannaCry)

Run the following command sets the SVM to use SMB2 and disable SMB1, and you will be able to join the AD domain with SMBv1 disabled on the domain controller. (you must be in advanced privelege mode to run this command [set advanced])

cifs security modify -vserver <SVM-Name> -smb1-enabled-for-dc-connections false -smb2-enabled-for-dc-connections true

Hope this saves someone else the several hours i spent pulling my hair out today trying to resolve.

---