Filer cannot join Domain - System clock and domain controller clock are more than 5 minutes apart.

[erich_diener]

I realize that this topic has been addressed before, but I wondered if installing DATA OnTap is the only accepted solution.

I am setting up a new FAS 2050 on a brand new Win2K8 domain.

When trying to setup a Volume as a share on a Domain via CIFS, I get the error above (wording is approx).  I have manually set both systems' clocks.  This does not fix the error.  Even when they are within one minute, I get the same error.  I have also tried changing the timezone (timed options) on either system to make them match.  I have also ensured that the Windows 2008 DC is serving NTP.  Nothing works.  Always the same error.  The filer can see both the DNS name and the IP address.  The preferred DCs are entered into the filer.  Sorta stuck...I'd love to read some ideas!

Please note that this is a stand alone network and cannot connect to the web.

[martin_fisher]

Hi,

Just reading your post, have you run 'CIFS Setup' ? what options did you select for ActiveDirectory

You should have been prompted with a series of options as below:

(1) Active Directory domain authentication (Active Directory domains only)
(2) Windows NT 4 domain authentication (Windows NT or Active Directory domains)
(3) Windows Workgroup authentication using the filer's local user accounts
(4) /etc/passwd and/or NIS/LDAP authentication

I have had the exact same error message today, working on an old FAS3020 with a production 2003 Active Directory domain. I used the 'date -u' command and manually updated the appliance time to within a few seconds of the domain and then re ran the CIFS setup and rejoined the Filer to the domain.

Have you also checked your credentials for joining the AD domain.

Thanks

Martin

[erich_diener]

Martin, thanks for your input!

Yeah, date -u is one of the first things I tried.  But I'm not opposed to trying it again!  Also, when your credentials aren't sufficient, you get a different error (I checked!)

If anything changes, I will let you know.

[martin_fisher]

Hi Erich,

is NTP setup/enabled on the appliance as well ?

Enable NTP and make sure you have at least 1 or more named servers in the following field: e.g:

options.timed.servers:    

Also check that these servers are reporting the correct times. We use 2 DC's, for this purpose.

Good Luck.

Thanks

Martin

[danielpr]

Hi Erich,

The quickest way to get it going would just be to alter the FAS clock to be within 5 minutes of a DC's clock.  You can use the date command for this. A;so check the DC clock time for the difference.

For a longer term solution, you can setup ONTAP to use time services to synchronize it's clock.  Check out the set of options under options timed.

You can sync the clock using NTP and RDATE , Please refer the following steps

NTP

Try to find a NTP server available in the Internet which serves for local (GMT) and configure the same. For example i will show you how to configure the  NTP setup in Filer.

FAS2020> ping 0.asia.pool.ntp.org   ====> Check if your NTP server is alive
0.asia.pool.ntp.org is alive
FAS2020> options timed.servers
FAS2020> date
Fri Jun 19 11:30:46 GMT 2009 ===============> Wrong time

FAS2020> options timed.servers 0.asia.pool.ntp.org
Reminder: you should also set option timed.servers on the partner node
or the next takeover may not function correctly.

FAS2020> options timed.enable on

Reminder: you should also set option timed.enable on the partner node

or the next takeover may not function correctly.

FAS2020>

So the time sync will happen with the public NTP servers during the scheduled time.

Rdate

To get the date/time sync immediealty you need to go for RDATE which is the other Timed protocol. Basically some NTP servers used to support Rdate aswell.

Since my NTP server doesn’t support the RDATE I have gone for another Public NTP server for the Rdate sync.

FAS2020> ping tick.greyware.com

stan.greyware.com is alive

FAS2020> rdate tick.greyware.com

Fri Jun 19 06:28:33 GMT 2009  ====================> Time has been synced with the Rdate Server

FAS2020>

Now the Storage System should be in sync with the Public NTP servers. Now check the date and time with your DC.

[erich_diener]

Unfortunately, this server has no access to the public domain.  As it turns out, the DC had bad time too and was reporting a different time than the system time.  I was able to get the CIFS share mounted, but the time on the FAS is still wrong (albeit sync'd with the DC's bad time).

Now I have an issue with the account permission for mounting the share...off to another discussion.

Thanks for your help!

[erich_diener]

Oh and I selected Active Directory Authentication (option 1).

[kvinay]

Hi Erich,

              This is a problem to do with difference in the time on your filer and the time on the machine or host which is your DC .Please try having filer and DC time same and then trying to configure CIFS you should succeed.You can use date command on the filer to set or change the time.

Regards,

Vinay

[Lewisr650]

Is there a way to validate what date and time is set on the remote AD server?  I have the date and time set on both the filer and the AD server where they are within seconds of each other and the CIFS setup still won't join the domain.  I have setup NTP on the AD server as well, have tried syncing the Filer to the AD server using RDATE but get a connection refused message.  It seems that there should be a way to validate the date on both systems better than the tools available.  If the CIFS setup would respond with the AD date it certainly would be better troubleshooting message than "your systems time is more than 5 minutes apart".

Any thoughts on troubleshooting this?  I have the timezone set the same, and have the clocks set within seconds of eachother but CIFS setup still complains that the times are more than 5 minutes out of sync.

Thanks,

Richard

[martin_fisher]

Hi

as previously mentioned in the posts, i would check the date and time setup of the remote AD server and also double check the username and password for the CIFS Setup.

If your filer has the correct time and is within seconds of the AD server, then the error must be within the CIFS setup.

have you checked the messages log for any errors ?

thanks

[shane_bradley]

Have you checked the timezone? i've run into this issue before when the timezone is incorrectly set on the filer.

[Lewisr650]

So...the odd thing is that the Windows system uses a notation of PDT = Pacific/Los_Angeles = GMT-8 and the Filer uses a notation of Americas/Los_Angeles = GMT-8.  If I set the filer to Americas/Los_Angeles and Windows system to Pacific/LosAngeles they don't sync up.  If I set the Windows system to GMT and the filer to America/Los_Angeles they sync up.  I of course set the time to be the same prior to trying to sync them.  The challenge is that the windows system time is the off by 8 hours.

It just seems to me that NetApp could provide a little more productive interface for setting these timezones, or at least provide an override to say "Are you sure you want to change the time on the filer equal to that of the Domain Controller?"...rather than just erroring out saying they are more than 5 minutes out of sync.  This is software afterall.  Tell me what each one is set to along with the timezone so I am led down the proper direction to success.  If the software can tell their's a difference...show the end user so they have enough information to make a decision.

Frustrating.

[shane_bradley]

The error is based off the kerberos auth algorithm, Tokens are only valid for 5 minute, creating a mechanism for automatically changing this would/could open up a whole can of worms from a security standpoint i would suspect.(i'm no security expert though)

The timezone one is abit weird, i'd probably log a call about that, from a filer perspective (and any linux/unix host as far as i know) the America/Los_Angeles thing is just a definition of the UTC offset and the dates when it changes i.e. daylight saving starting and finishing all that is, is a path (/vol/<root_vol>/etc/zoneinfo/America) and a file (Los_Angeles) the UTC offset is used for calculations on time difference so its pretty strange that it doesnt work.

[JIGNESH1983]

Hi.

Exactly same error I am facing too ...

I am using Netapp 8.1 Simulator with System Manager and Unable setup CIFS due to time skew is too long error. However, i have successfully deployed with iSCSI protocol.

My e-mail Address : Jignesh_Rajguru@Hotmail.com