The adsys daemon¶
When are the policies refreshed¶
On the client the policies are refreshed in 3 situations:
At boot time for the policy of the machine.
At login time for the policy of the user.
Periodically by a timer for the machine and the user policy.
What happens when a policy refresh fails¶
When the client is offline, e.g. a laptop, or the Active Directory server is unreachable, you still want to use the machine and be able to log in. For this purpose, ADSys uses a cache located in
There are 2 types of cache:
A cache for the GPO downloaded from the server in directory
A cache for the rules as applied by ADSys in
The enforcement of the policy will fail when the cache is empty or the client fails to retrieve the policy from the server.
If the enforcement of the policy fails:
At boot time, ADSys stops the boot process.
At login time, login is denied.
During periodic refresh, the policy currently applied on the client remains.
How to change refresh rate¶
Periodic refresh of the policies (machine and active users) is handled by the systemd timer unit
You can list the timers with the command
$ systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2021-05-18 10:05:49 CEST 11min left Tue 2021-05-18 09:35:49 CEST 18min ago adsys-gpo-refresh.timer adsys-gpo-refresh.service
Tue 2021-05-18 10:31:34 CEST 36min left Tue 2021-05-18 09:31:09 CEST 23min ago anacron.timer anacron.service
The default refresh rate is 30 minutes.
You can override the refresh rate with the configuration variables
OnUnitActiveSec in a configuration file as follow:
# Refresh ADSys GPO every 2 hours
The changes will be effective after a reload of the daemon with
systemctl daemon-reload or after a reboot.
$ sudo systemctl daemon-reload
$ sudo systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTIVATES
Tue 2021-05-18 10:35:45 CEST 16min left Tue 2021-05-18 10:05:50 CEST 1h43min ago adsys-gpo-refresh.timer adsys-gpo-refresh.service
OnUnitActiveSec=statements are used to reset the system-wide timer unit time instead of adding new timers.
man systemd.timerfor more information.
You can get more details about the timer status itself as an administrator:
$ sudo systemctl status adsys-gpo-refresh.timer
● adsys-gpo-refresh.timer - Refresh ADSys GPO for machine and users
Loaded: loaded (/lib/systemd/system/adsys-gpo-refresh.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2021-05-18 08:35:48 CEST; 1h 23min ago
Trigger: Tue 2021-05-18 10:05:49 CEST; 6min left
Triggers: ● adsys-gpo-refresh.service
may 18 08:35:48 adclient04 systemd: Started Refresh ADSys GPO for machine and users.
TODO: adsysctl service status to get next scheduled refresh
The ADSys daemon is started on demand by systemd’s socket activation and only runs when it’s required. It will gracefully shutdown after idling for a short period of time (by default 120 seconds).
ADSys doesn’t ship a configuration file by default. However, such a file can be created to modify the behavior of the daemon and the client.
The configuration file can be system-wide in
/etc/adsys.yaml. This will thus apply to both daemon and client. You can have per-user configuration by creating
$HOME/adsys.yaml. It will then affect only the client for this user.
The current directory is also searched for an
adsysctl commands accept a
--config|-c <configuration_file_path> flag to set the path to a configuration file at run time. It can be used for testing purpose for instance.
An example of configuration file with all the options can be found in the ADSys repository:
# Service and client configuration
# Service only configuration
# Backend selection: sssd (default) or winbind
# SSSD configuration
# Winbind configuration
# (if ad_backend is set to winbind)
# Client only configuration
Configuration common between service and client¶
verbose Increase the verbosity of the daemon or client. By default, only warnings and error logs are printed. This value is set between 0 and 3. This has the same effect as the
socket Path the Unix socket for communication between clients and daemon. This can be overridden by the
--socketoption. Defaults to
/run/adsysd.sock(monitored by systemd for socket activation).
Service only configuration¶
service_timeout Time in seconds without any active request before the service exits. This can be overridden by the
--timeoutoption. Defaults to 120 seconds.
backend Backend to use to integrate with Active Directory. It is responsible for providing valid kerberos tickets. Available selection is
winbind. Default is
sssd. This can be overridden by the
sss_cache_dir The directory that stores Kerberos tickets used by SSSD. By default
run_dir The run directory contains the links to the kerberos tickets for the machine and the active users. This can be overridden by the
--run-diroption. Defaults to
Backend specific options¶
sssd.conf. This is the source of selected sss domain (first entry in
domains:), to find corresponding active directory domain section.
ad_domain in that section is used for the list of domains list of the host.
ad_server (optional) is used as the Active directory LDAP server to contact. If it is missing, then the “Active Server” detected by sssd will be used.
default_domain_suffix is used too, and falls back to the domain name if missing.
Default lookup path is
/etc/sssd/sssd.conf. This can be overridden by the
Path to the sss database to find the HOST kerberos ticket. Default path is
/var/lib/sss/db. This can be overridden by the
A custom domain can be used to override the C API call that ADSys executes to determine the active domain – which is returned by the
wbinfo --own-domain (e.g.
A custom domain controller can be used to override the C API call that ADSys executes to determine the AD controller FQDN – which is returned by
wbinfo --dsgetdcname domain.com (e.g.
Client only configuration:**¶
client_timeout Maximum time in seconds between 2 server activities before the client returns and aborts the request. This can be overridden by the
--timeoutoption. Defaults to 30 seconds.
Debugging with logs (cat command)¶
It is possible to follow the exchanges between all clients and the daemon with the
cat command. It forwards all logs and message printing from the daemon alone.
Only privileged users have access to this information. As with any other command, the verbosity can be increased with
-v flags (it’s independent of the daemon or client current verbosity). More flags increases the verbosity further up to 3.
More information is available in the next chapter covering adsysctl cat command.
There are additional configuration options matching the adsysd command line options. Those are used to define things like dconf, apparmor, polkit, sudo directories… Even though they exist mostly for integration tests purposes, they can be tweaked the same way as other configuration options for the service.
Do not hesitate to use the shell completion and the
help subcommands to get more information about the subcommands.