NTP
Authelia has the ability to check the system time against an NTP server, which at the present time is checked only during startup. This section configures and tunes the settings for this check.
In the instance of inability to contact the NTP server or an issue with the synchronization Authelia will fail to start unless configured otherwise. It should however be noted that disabling this check is not a supported configuration and instead administrators should correct the underlying time issue. i.e. if this check is disabled and a service reliant on the time being accurate has a failure, it’s very unlikely we will produce/accept a fix in this scenario without additional benefits.
Configuration
Example Configuration
This section is intended as an example configuration to help users with a rough contextual layout of this configuration section, it is not intended to explain the options. The configuration shown may not be a valid configuration, and you should see the options section below and the navigation links to properly understand each option individually.
Options
This section describes the individual configuration options.
address
Determines the address of the NTP server to retrieve the time from. The format is <host>:<port>
, and both of these are
required.
address
Reference Note
This configuration option uses a common syntax. For more information please see both the configuration example and the Common Syntax: Address reference guide.
Configures the address for the NTP Server. The address itself is a connector and the scheme must be udp
,
udp4
, or udp6
.
Examples:
version
Determines the NTP version supported. Valid values are 3 or 4.
max_desync
Reference Note
This configuration option uses a common syntax. For more information please see both the configuration example and the Common Syntax: Duration reference guide.
This is used to tune the acceptable desync from the time reported from the NTP server.
disable_startup_check
Important Note
Administrators are strongly urged to fix the underlying time issue instead of utilizing this option. See the FAQ for more information.
Setting this to true will disable the startup check entirely.
disable_failure
Important Note
Administrators are strongly urged to fix the underlying time issue instead of utilizing this option. See the FAQ for more information.
Setting this to true will allow Authelia to start and just log an error instead of exiting. The default is that if Authelia can contact the NTP server successfully, and the time reported by the server is greater than what is configured in max_desync that Authelia fails to start and logs a fatal error.
Frequently Asked Questions
This section acts as a frequently asked questions for the NTP behavior and configuration.
Why is this check important and enabled by default?
This check is essential to validate the system time is accurate which ensures the following:
- The Session cookie expiration times are accurately set which is important because:
- If the time is too far in the past sessions could:
- Be considered already expired by browsers leading to strange redirect issues.
- Be considered expired by browsers much sooner than intended.
- If the time is too far into the future sessions could:
- Be considered expired by browsers much later than intended.
- If the time is too far in the past sessions could:
- The OpenID Connect JWT issued at/not before/expiration times are
set correctly which is important because:
- If the time is too far in the past the OpenID Connect issued JWT’s could:
- Be considered already expired by relying parties at the time of issue.
- Be considered expired by relying parties much sooner than intended.
- If the time is too far into the future OpenID Connect issued JWT’s could:
- Be considered invalid by correctly configured relying parties as the issue time is too far in the future.
- Be considered invalid by badly configured relying parties much later than intended.
- If the time is too far in the past the OpenID Connect issued JWT’s could:
- The TOTP verification codes could:
- Be considered invalid when they are technically correct.
Why should this check not be disabled?
Due to the fact this can affect elements such as the JWT validity and session validity it’s important for security this check is operational.