THE ENTIRE TIME SYSTEM!!!

Dellsmash1

Cadet
Joined
Mar 1, 2019
Messages
4
There seems to be a MASSIVE confusion with setting time in freenas... I now have 2 freenas boxes that have now decided that "b'active Directory Failed to Reload" is the only thing they are going to give me with regards to retrieving Active Directory information.... When researching freeBSD and freenas it seems there is a BIOS/SYSTEM clock and a freenas software clock? IDK but one you can set and the other you cannot? again IDK because the real inner workings are a mystery and the only thing anyone can tell you is "UTC" whatever the hell that means... its not even a time zone and I cannot set all of my servers to UTC and expect to work 10 hours behind the rest of the world here.... My question is, if freenas shows the EXACT time in the GUI... the command 'ntpdate -q mydomain.com' shows an offset of 0.05101 then why the hell does the active directory software in freenas say "Clock Skew To Great" and if it thinks the clock skew is to great then how the hell am I suppose to SET IT!
 
Last edited:

Dellsmash1

Cadet
Joined
Mar 1, 2019
Messages
4
Ok... no confusion just a bug.... I have 2 Freenas box's running v11.0 and over the past 2 weeks both have checked out of Active Directory... After deciding there was clearly a clock issue I started running the time using the CLI in freenas (date yymmddhhmm) from 1am until the current time.... After doing this on both freenas boxes they both began communicating again with Active Directory.... Again trying to simply set the Time or setting NTP settings or even rebooting did not work... it was not until I changed the time over and over that it finally began to communicate.
 

rvassar

Guru
Joined
May 2, 2018
Messages
971
UTC = Universal Time Coordinated. Also called Greenwich Time in some countries. It's been a world standard since at least 1960.

Coordinated Universal Time

Active Directory uses Kerberos ticketing to exchange information, which imposes a strict time synchronization mandate. Your motherboard has a battery backed clock that's mostly used to roughly set the OS clock at boot. The NTP system is used to synchronize and stabilize the OS clock, calculating it's drift vs. other time sources, and attempting to groom the clock so that time stays within some minuscule margin of error from the recognized standards like the NIST atomic clocks, and those of other countries. NTP generally functions over tens of minutes to hours, so just setting a clock or rebooting it causes it to fall out of sync, and restart its synchronization process.

NTP is not perfect. There are best practices for configuring it, but in general, you want to have either 1 or 3 or more NTP time sources. Never only two sources, no matter what they are. When there's only two, the clock will hop back and forth between them, favoring which ever one is closest to itself at the moment. This can drive Kerberos nuts. Generally, I keep three "Internet pool" sources configured on my FreeNAS box, and three other local machines (Rasberry Pi's and an ESXi box in my case) also configured similarly. If my network connection goes down, the local machines reference each other, and at least drift out of sync together.

I should also add... If your AD server is virtualized, check to make sure the VM's time is not wobbling. I have given up trying to run anything time critical in the FreeNAS Bhyve VM's, as they do not pass time calls down to the underlying host OS like ESXi does, and as a result they wander several seconds per day without NTP correction. With NTP correction, they step-correct 128ms every ten minutes or so on my FN box.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Also, it's worth noting that "UTC" is a representation of time, just as any timezone is. When properly synchronized, your servers will all report the exact same number for "date +%s" if you run it at the exact same time. This is the number that ntpd is working to maintain.

The UNIX userland takes this number and applies things like /etc/localtime and TZ to arrive at a useful human-readable representation. For kicks, try this at your shell:

csh% ( setenv TZ Asia/Bangkok ; date ); date
Wed Mar 13 01:43:18 ICT 2019
Tue Mar 12 13:43:18 CDT 2019

No my server really didn't fly halfway around the globe in less than a second. UNIX doesn't care what you want for a timezone. It will happily display it in the format you desire, if you tell it.

The confusion with UTC happens because there are issues with the PC BIOS and PC RTC. Plebians set the BIOS clock to their "local" time, which causes a bunch of trouble because it does not contain timezone information, so FreeBSD, Linux, etc., all put some effort into fixing this user brokenness. In FreeBSD, the interface is handled through adjkerntz, which you can read the manual page on if you care. The simpler fix is just to set your BIOS clock to UTC.
 

Dellsmash1

Cadet
Joined
Mar 1, 2019
Messages
4
So is there no way to set bios clock in freeBSD? In other flavors I understand you can use “hwclock”... Also This is a legitimate bug, I set the clock using “date yymmddhhmm” and I did this over and over from 1am, 2am, 3am, 4am..etc until I made it to the correct time which was like 10am, after doing that on 2 seperate NAS’s both with the active directiry sync problem they both started working correctly.... Mind you, I had set the clock a dozen times over the course of weeks with NAS 1 and it would not join to save its life.... Did this method and bam. Worked right away, I fail to see how this is a bios or rtc clock issue if its working on the correct time just like i had set many times before....
 
Joined
Jan 4, 2014
Messages
1,644
Last edited:

Constantin

Vampire Pig
Joined
May 19, 2017
Messages
1,828
Sounds like implementing a rock-solid local NTP server is the way to go once there are lots of critical services depending on a "good" time to function. A Pi with a good external clock (temperature-compensated RTC like the Chronodot) should do the trick

Make the Pi use external NTP servers as a reference when they're available, switch to "local" mode when they're not. Meanwhile, all local queries go to the Pi and hence drift merrily together.

Cost and power consumption should be fairly minimal.
 

Apollo

Wizard
Joined
Jun 13, 2013
Messages
1,449
So is there no way to set bios clock in freeBSD? In other flavors I understand you can use “hwclock”... Also This is a legitimate bug, I set the clock using “date yymmddhhmm” and I did this over and over from 1am, 2am, 3am, 4am..etc until I made it to the correct time which was like 10am, after doing that on 2 separate NAS’s both with the active directiry sync problem they both started working correctly.... Mind you, I had set the clock a dozen times over the course of weeks with NAS 1 and it would not join to save its life.... Did this method and bam. Worked right away, I fail to see how this is a bios or rtc clock issue if its working on the correct time just like i had set many times before....
Normally, when you update the Date through CLI, it directly update the BIOS RTC clock.
The reason you are having those issues is due to the fact your PC is not aware of the timezone you are in. When you have Freenas installed, there is a section in your settings that dictates which time zone you are in. When the timezone is properly set, then only update the time using the CLI as your local time. What this does is still going to keep your BIOS at your local time but FreeBSD will see the local time then translate what is the UTC time and check with UTC time server.
 

file_haver

Explorer
Joined
Sep 19, 2018
Messages
55
So is there no way to set bios clock in freeBSD? In other flavors I understand you can use “hwclock”... Also This is a legitimate bug, I set the clock using “date yymmddhhmm” and I did this over and over from 1am, 2am, 3am, 4am..etc until I made it to the correct time which was like 10am, after doing that on 2 separate NAS’s both with the active directiry sync problem they both started working correctly.... Mind you, I had set the clock a dozen times over the course of weeks with NAS 1 and it would not join to save its life.... Did this method and bam. Worked right away, I fail to see how this is a bios or rtc clock issue if its working on the correct time just like i had set many times before....

Despite being the plebian solution (LOL) I actually have the correct local time set both in BIOS and I have FreeNAS set to my time zone as well. I have never once touched the FreeNAS NTP settings much less the clock settings via shell, but i can assure you that this is what i had to do to keep my Active Directory working without issue. This is how I have kept my FreeNAS boxes set up since version 10 and i'm currently on version 11,2 and my Microsoft services still work.

As I've never had an issue across OS lines doing things this way, i plan that i will continue to do it this way.
 
Last edited:

Apollo

Wizard
Joined
Jun 13, 2013
Messages
1,449
Maybe the issue is your Microsoft service using the wrong time zone, or other services getting the wrong time.
 

file_haver

Explorer
Joined
Sep 19, 2018
Messages
55
Maybe the issue is your Microsoft service using the wrong time zone, or other services getting the wrong time.

The MS services are all configured for the correct time zone, so I had assumed MS stuff assumes your BIOS is set to local time and you have your time zone correct as well.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,544
The MS services are all configured for the correct time zone, so I had assumed MS stuff assumes your BIOS is set to local time and you have your time zone correct as well.

One quick and dirty way to fix time on the FreeNAS server is to use the date command. If you run it without arguments, then it displays current date and time. date 201903130527 sets the date and time to March 13 2019, at 5:27 AM (be mindful of timezones). If you're still getting errors about clockskew after fixing the time, try running kdestroy and service ix-kinit start to destroy your current kerberos ticket and grab a fresh one.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Maybe the issue is your Microsoft service using the wrong time zone, or other services getting the wrong time.

Microsoft doesn't give a crap about the time zone either, and is also using a UTC representation internally. That's why most of this discussion of time zones is not actually relevant to the synchronization problem, which is likely to be some sort of time sync issue.
 

Dellsmash1

Cadet
Joined
Mar 1, 2019
Messages
4
but again... let me re-iterate... I set the time over and over and double triple checked, no go. I then set the time using the date xxxxxxxxxx command from 1am up through the current time. It joined the domain once I got to the correct time. It SHOULD have never left the domain as the time was correct to begin with and THEN it should have definitely joined when I set it a thousand times over the course of 1 or 2 weeks!.... I digress, it did not until i changed the time over and over again starting from 1am until the correct current time.... I would guess this was a 1 time freak situation however, it did it on 2 different systems at 2 completely different times. And please note, as i was changing the time using date xxxxxxxxxx i was checking to see if it would join the domain, each time was a failure until i hit the current time, then BINGO!!! were up and have been for 2 days now.
 

jgreco

Resident Grinch
Joined
May 29, 2011
Messages
18,681
Some of us have hundreds or thousands of systems that synchronize their time without issue.

PC hardware is fickle. We generally favor Supermicro kit here because it generally works without lots of drama. Unfortunately, without any clue as to what kind of hardware you're using, or what quirks it might contain, all we can really do is explain the way it works and then sorta shrug.

I've seen systems where a bad CMOS battery teases the RTC into doing really strange things.

I've seen systems where the BIOS is just very strange about the clock.

I've seen systems where the available timesources on the platform are quirky or even just downright broken.

But for the most part, I've really not had a lot of problems with clock sync, dating back to the exciting early days of NTP where things didn't work so well and there actually *were* some problems.
 

rvassar

Guru
Joined
May 2, 2018
Messages
971
It does sound like there was some kind of quirk or glitch, but... @jgreco is right. Without more info, all we can do is guess.
 
Top