/
sssd.conf.5.xml
4274 lines (4180 loc) · 204 KB
/
sssd.conf.5.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE reference PUBLIC "-//OASIS//DTD DocBook V4.4//EN"
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
<reference>
<title>SSSD Manual pages</title>
<refentry>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="include/upstream.xml" />
<refmeta>
<refentrytitle>sssd.conf</refentrytitle>
<manvolnum>5</manvolnum>
<refmiscinfo class="manual">File Formats and Conventions</refmiscinfo>
</refmeta>
<refnamediv id='name'>
<refname>sssd.conf</refname>
<refpurpose>the configuration file for SSSD</refpurpose>
</refnamediv>
<refsect1 id='file-format'>
<title>FILE FORMAT</title>
<para>
The file has an ini-style syntax and consists of sections and
parameters. A section begins with the name of the section in
square brackets and continues until the next section begins. An
example of section with single and multi-valued parameters:
<programlisting>
<replaceable>[section]</replaceable>
<replaceable>key</replaceable> = <replaceable>value</replaceable>
<replaceable>key2</replaceable> = <replaceable>value2,value3</replaceable>
</programlisting>
</para>
<para>
The data types used are string (no quotes needed), integer
and bool (with values of <quote>TRUE/FALSE</quote>).
</para>
<para>
A comment line starts with a hash sign (<quote>#</quote>) or a
semicolon (<quote>;</quote>).
Inline comments are not supported.
</para>
<para>
All sections can have an optional
<replaceable>description</replaceable> parameter. Its function
is only as a label for the section.
</para>
<para>
<filename>sssd.conf</filename> must be a regular file, owned by
root and only root may read from or write to the file.
</para>
</refsect1>
<refsect1 id='config-snippets'>
<title>CONFIGURATION SNIPPETS FROM INCLUDE DIRECTORY</title>
<para>
The configuration file <filename>sssd.conf</filename> will
include configuration snippets using the include directory
<filename>conf.d</filename>. This feature is available if
SSSD was compiled with libini version 1.3.0 or later.
</para>
<para>
Any file placed in <filename>conf.d</filename>
that ends in <quote><filename>.conf</filename></quote>
and does not begin with a dot (<quote>.</quote>) will
be used together with <filename>sssd.conf</filename>
to configure SSSD.
</para>
<para>
The configuration snippets from <filename>conf.d</filename>
have higher priority than <filename>sssd.conf</filename>
and will override <filename>sssd.conf</filename> when
conflicts occur. If several snippets are present in
<filename>conf.d</filename>, then they are included in
alphabetical order (based on locale).
Files included later have higher priority. Numerical
prefixes (<filename>01_snippet.conf</filename>,
<filename>02_snippet.conf</filename> etc.) can help
visualize the priority (higher number means higher
priority).
</para>
<para>
The snippet files require the same owner and permissions
as <filename>sssd.conf</filename>. Which are by default
root:root and 0600.
</para>
</refsect1>
<refsect1 id='general-options'>
<title>GENERAL OPTIONS</title>
<para>
Following options are usable in more than one configuration
sections.
</para>
<refsect2 id='all-section-options'>
<title>Options usable in all sections</title>
<para>
<variablelist>
<varlistentry>
<term>debug_level (integer)</term>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude" href="include/debug_levels.xml" />
</varlistentry>
<varlistentry>
<term>debug (integer)</term>
<listitem>
<para>
SSSD 1.14 and later also includes the
<replaceable>debug</replaceable> alias for
<replaceable>debug_level</replaceable> as a
convenience feature. If both are specified, the
value of <replaceable>debug_level</replaceable>
will be used.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>debug_timestamps (bool)</term>
<listitem>
<para>
Add a timestamp to the debug messages.
If journald is enabled for SSSD debug logging this
option is ignored.
</para>
<para>
Default: true
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>debug_microseconds (bool)</term>
<listitem>
<para>
Add microseconds to the timestamp in debug messages.
If journald is enabled for SSSD debug logging this
option is ignored.
</para>
<para>
Default: false
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>debug_backtrace_enabled (bool)</term>
<listitem>
<para>
Enable debug backtrace.
</para>
<para>
In case SSSD is run with debug_level less than 9,
everything is logged to a ring buffer in memory and
flushed to a log file on any error up to
and including `min(0x0040, debug_level)`
(i.e. if debug_level is explicitly set to 0 or 1 then
only those error levels will trigger backtrace,
otherwise up to 2).
</para>
<para>
Feature is only supported for `logger == files` (i.e.
setting doesn't have effect for other logger types).
</para>
<para>
Default: true
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</refsect2>
<refsect2 id='services-and-domains-section-options'>
<title>Options usable in SERVICE and DOMAIN sections</title>
<para>
<variablelist>
<varlistentry>
<term>timeout (integer)</term>
<listitem>
<para>
Timeout in seconds between heartbeats for this
service. This is used to ensure that the process
is alive and capable of answering requests. Note
that after three missed heartbeats the process
will terminate itself.
</para>
<para>
Default: 10
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</refsect2>
</refsect1>
<refsect1 id='special-sections'>
<title>SPECIAL SECTIONS</title>
<refsect2 id='services'>
<title>The [sssd] section</title>
<para>
Individual pieces of SSSD functionality are provided by special
SSSD services that are started and stopped together with SSSD.
The services are managed by a special service frequently called
<quote>monitor</quote>. The <quote>[sssd]</quote> section is used
to configure the monitor as well as some other important options
like the identity domains.
<variablelist>
<title>Section parameters</title>
<varlistentry>
<term>config_file_version (integer)</term>
<listitem>
<para>
Indicates what is the syntax of the config
file. SSSD 0.6.0 and later use version 2.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>services</term>
<listitem>
<para>
Comma separated list of services that are
started when sssd itself starts.
<phrase condition="have_systemd">
The services' list is optional on platforms
where systemd is supported, as they will either
be socket or D-Bus activated when needed.
</phrase>
</para>
<para>
Supported services: nss, pam
<phrase condition="with_sudo">, sudo</phrase>
<phrase condition="with_autofs">, autofs</phrase>
<phrase condition="with_ssh">, ssh</phrase>
<phrase condition="with_pac_responder">, pac</phrase>
<phrase condition="with_ifp">, ifp</phrase>
</para>
<para>
<phrase condition="have_systemd">
By default, all services are disabled and the administrator
must enable the ones allowed to be used by executing:
"systemctl enable sssd-@service@.socket".
</phrase>
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>reconnection_retries (integer)</term>
<listitem>
<para>
Number of times services should attempt to
reconnect in the event of a Data Provider
crash or restart before they give up
</para>
<para>
Default: 3
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>domains</term>
<listitem>
<para>
A domain is a database containing user
information. SSSD can use more domains
at the same time, but at least one
must be configured or SSSD won't start.
This parameter describes the list of domains
in the order you want them to be queried.
A domain name is recommended to contain only
alphanumeric ASCII characters, dashes, dots
and underscores. '/' character is forbidden.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>re_expression (string)</term>
<listitem>
<para>
Default regular expression that describes how to
parse the string containing user name and domain
into these components.
</para>
<para>
Each domain can have an individual regular
expression configured. For some ID providers
there are also default regular expressions. See
DOMAIN SECTIONS for more info on these regular
expressions.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>full_name_format (string)</term>
<listitem>
<para>
A <citerefentry>
<refentrytitle>printf</refentrytitle>
<manvolnum>3</manvolnum>
</citerefentry>-compatible format that describes how to
compose a fully qualified name from user name
and domain name components.
</para>
<para>
The following expansions are supported:
<variablelist>
<varlistentry>
<term>%1$s</term>
<listitem><para>user name</para></listitem>
</varlistentry>
<varlistentry>
<term>%2$s</term>
<listitem>
<para>
domain name as specified in the
SSSD config file.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>%3$s</term>
<listitem>
<para>
domain flat name. Mostly usable
for Active Directory domains, both
directly configured or discovered
via IPA trusts.
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
Each domain can have an individual format string configured.
See DOMAIN SECTIONS for more info on this option.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>monitor_resolv_conf (boolean)</term>
<listitem>
<para>
Controls if SSSD should monitor the state of
resolv.conf to identify when it needs to
update its internal DNS resolver.
</para>
<para>
Default: true
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>try_inotify (boolean)</term>
<listitem>
<para>
By default, SSSD will attempt to use inotify
to monitor configuration files changes and
will fall back to polling every five seconds
if inotify cannot be used.
</para>
<para>
There are some limited situations where it is
preferred that we should skip even trying to
use inotify. In these rare cases, this option
should be set to 'false'
</para>
<para>
Default: true on platforms where inotify is
supported. False on other platforms.
</para>
<para>
Note: this option will have no effect on
platforms where inotify is unavailable. On
these platforms, polling will always be used.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>krb5_rcache_dir (string)</term>
<listitem>
<para>
Directory on the filesystem where SSSD should
store Kerberos replay cache files.
</para>
<para>
This option accepts a special value
__LIBKRB5_DEFAULTS__ that will instruct SSSD
to let libkrb5 decide the appropriate
location for the replay cache.
</para>
<para>
Default: Distribution-specific and specified
at build-time. (__LIBKRB5_DEFAULTS__ if not
configured)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>user (string)</term>
<listitem>
<para>
The user to drop the privileges to where
appropriate to avoid running as the
root user.
<phrase condition="have_systemd">
This option does not work when running socket-activated
services, as the user set up to run the processes is
set up during compilation time.
The way to override the systemd unit files is by creating
the appropriate files in /etc/systemd/system/.
Keep in mind that any change in the socket user, group or
permissions may result in a non-usable SSSD. The same may
occur in case of changes of the user running the NSS
responder.
</phrase>
</para>
<para>
Default: not set, process will run as root
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>default_domain_suffix (string)</term>
<listitem>
<para>
This string will be used as a default domain
name for all names without a domain name
component. The main use case is environments
where the primary domain is intended for managing host
policies and all users are located in a trusted domain.
The option allows those users
to log in just with their user name without
giving a domain name as well.
</para>
<para>
Please note that if this option is set all
users from the primary domain have to use their
fully qualified name, e.g. user@domain.name,
to log in. Setting this option changes default
of use_fully_qualified_names to True. It is not
allowed to use this option together with
use_fully_qualified_names set to False. One
exception from this rule are domains with
<quote>id_provider=files</quote> that always try
to match the behaviour of nss_files
and therefore their output is not
qualified even when the default_domain_suffix
option is used.
</para>
<para>
Default: not set
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>override_space (string)</term>
<listitem>
<para>
This parameter will replace spaces (space bar)
with the given character for user and group names.
e.g. (_). User name "john doe" will
be "john_doe" This feature was added to
help compatibility with shell scripts that have
difficulty handling spaces, due to the
default field separator in the shell.
</para>
<para>
Please note it is a configuration error to use
a replacement character that might be used in
user or group names. If a name contains the
replacement character SSSD tries to return the
unmodified name but in general the result of a
lookup is undefined.
</para>
<para>
Default: not set (spaces will not be replaced)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>certificate_verification (string)</term>
<listitem>
<para>
With this parameter the certificate verification
can be tuned with a comma separated list of
options. Supported options are:
<variablelist>
<varlistentry>
<term>no_ocsp</term>
<listitem>
<para>Disables Online Certificate Status
Protocol (OCSP) checks. This might be
needed if the OCSP servers defined in
the certificate are not reachable from
the client.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>soft_ocsp</term>
<listitem>
<para> If a connection
cannot be established to an OCSP
responder the OCSP check is skipped.
This option should be used to allow
authentication when the system is
offline and the OCSP responder cannot be
reached.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ocsp_dgst</term>
<listitem>
<para>Digest (hash) function used to
create the certificate ID for the OCSP
request. Allowed values are:
<itemizedlist>
<listitem><para>sha1</para></listitem>
<listitem><para>sha256</para></listitem>
<listitem><para>sha384</para></listitem>
<listitem><para>sha512</para></listitem>
</itemizedlist></para>
<para>
Default: sha1 (to allow compatibility with
RFC5019-compliant responder)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>no_verification</term>
<listitem>
<para>Disables verification completely.
This option should only be used for
testing.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>partial_chain</term>
<listitem>
<para>Allow verification to succeed even
if a <replaceable>complete</replaceable>
chain cannot be built to a self-signed
trust-anchor, provided it is possible to
construct a chain to a trusted certificate
that might not be self-signed.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ocsp_default_responder=URL</term>
<listitem>
<para>Sets the OCSP default responder
which should be used instead of the one
mentioned in the certificate. URL must
be replaced with the URL of the OCSP
default responder e.g.
http://example.com:80/ocsp.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
ocsp_default_responder_signing_cert=NAME</term>
<listitem>
<para>This option is
currently ignored. All needed
certificates must be available in the
PEM file given by
pam_cert_db_path.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>crl_file=/PATH/TO/CRL/FILE</term>
<listitem>
<para>Use the
Certificate Revocation List (CRL) from
the given file during the verification
of the certificate. The CRL must be
given in PEM format, see
<citerefentry>
<refentrytitle>crl</refentrytitle>
<manvolnum>1ssl</manvolnum>
</citerefentry>
for details.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>soft_crl</term>
<listitem>
<para>
If a Certificate Revocation List (CRL)
is expired ignore the CRL checks for the
related certificates. This option should
be used to allow authentication when the
system is offline and the CRL cannot be
renewed.</para>
</listitem>
</varlistentry>
</variablelist>
</para>
<para>
Unknown options are reported but ignored.
</para>
<para>
Default: not set, i.e. do not restrict
certificate verification
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>disable_netlink (boolean)</term>
<listitem>
<para>
SSSD hooks into the netlink interface to
monitor changes to routes, addresses, links
and trigger certain actions.
</para>
<para>
The SSSD state changes caused by netlink
events may be undesirable and can be disabled
by setting this option to 'true'
</para>
<para>
Default: false (netlink changes are detected)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>enable_files_domain (boolean)</term>
<listitem>
<para>
When this option is enabled, SSSD
prepends an implicit domain with
<quote>id_provider=files</quote> before
any explicitly configured domains.
</para>
<para condition="no_enable_files_domain">
Default: false
</para>
<para condition="enable_files_domain">
Default: true
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>domain_resolution_order</term>
<listitem>
<para>
Comma separated list of domains and subdomains
representing the lookup order that will be
followed.
The list doesn't have to include all possible
domains as the missing domains will be looked
up based on the order they're presented in the
<quote>domains</quote> configuration option.
The subdomains which are not listed as part of
<quote>lookup_order</quote> will be looked up
in a random order for each parent domain.
</para>
<para>
Please, note that when this option is set the
output format of all commands is always
fully-qualified even when using short names
for input, for all users but the ones managed
by the files provider.
In case the administrator wants the output not
fully-qualified, the full_name_format option
can be used as shown below:
<quote>full_name_format=%1$s</quote>
However, keep in mind that during login, login
applications often canonicalize the username by
calling
<citerefentry>
<refentrytitle>getpwnam</refentrytitle>
<manvolnum>3</manvolnum>
</citerefentry>
which, if a shortname is returned for a
qualified input (while trying to reach a user
which exists in multiple domains) might
re-route the login attempt into the domain
which uses shortnames, making this workaround
totally not recommended in cases where
usernames may overlap between domains.
</para>
<para>
Default: Not set
</para>
</listitem>
</varlistentry>
</variablelist>
</para>
</refsect2>
</refsect1>
<refsect1 id='services-sections'>
<title>SERVICES SECTIONS</title>
<para>
Settings that can be used to configure different services
are described in this section. They should reside in the
[<replaceable>$NAME</replaceable>] section, for example,
for NSS service, the section would be <quote>[nss]</quote>
</para>
<refsect2 id='general'>
<title>General service configuration options</title>
<para>
These options can be used to configure any service.
</para>
<variablelist>
<varlistentry>
<term>reconnection_retries (integer)</term>
<listitem>
<para>
Number of times services should attempt to
reconnect in the event of a Data Provider
crash or restart before they give up
</para>
<para>
Default: 3
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>fd_limit</term>
<listitem>
<para>
This option specifies the maximum number of file
descriptors that may be opened at one time by this
SSSD process. On systems where SSSD is granted the
CAP_SYS_RESOURCE capability, this will be an
absolute setting. On systems without this
capability, the resulting value will be the lower
value of this or the limits.conf "hard" limit.
</para>
<para>
Default: 8192 (or limits.conf "hard" limit)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>client_idle_timeout</term>
<listitem>
<para>
This option specifies the number of seconds that
a client of an SSSD process can hold onto a file
descriptor without communicating on it. This value
is limited in order to avoid resource exhaustion
on the system. The timeout can't be shorter than
10 seconds. If a lower value is configured, it
will be adjusted to 10 seconds.
</para>
<para>
Default: 60, KCM: 300
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>offline_timeout (integer)</term>
<listitem>
<para>
When SSSD switches to offline mode the amount of
time before it tries to go back online will
increase based upon the time spent disconnected.
By default SSSD uses incremental behaviour to
calculate delay in between retries.
So, the wait time for a given retry will be longer
than the wait time for the previous ones.
After each unsuccessful attempt to go online,
the new interval is recalculated by the following:
</para>
<para>
new_delay = Minimum(old_delay * 2, offline_timeout_max) + random[0...offline_timeout_random_offset]
</para>
<para>
The offline_timeout default value is 60.
The offline_timeout_max default value is 3600.
The offline_timeout_random_offset default value is 30.
The end result is amount of seconds before next retry.
</para>
<para>
Note that the maximum length of each interval
is defined by offline_timeout_max (apart of random part).
</para>
<para>
Default: 60
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>offline_timeout_max (integer)</term>
<listitem>
<para>
Controls by how much the time between attempts to go
online can be incremented following unsuccessful
attempts to go online.
</para>
<para>
A value of 0 disables the incrementing behaviour.
</para>
<para>
The value of this parameter should be set in correlation
to offline_timeout parameter value.
</para>
<para>
With offline_timeout set to 60 (default value) there is no point
in setting offlinet_timeout_max to less than 120 as it will
saturate instantly. General rule here should be to set
offline_timeout_max to at least 4 times offline_timeout.
</para>
<para>
Although a value between 0 and offline_timeout may be
specified, it has the effect of overriding the
offline_timeout value so is of little use.
</para>
<para>
Default: 3600
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>offline_timeout_random_offset (integer)</term>
<listitem>
<para>
When SSSD is in offline mode it keeps probing
backend servers in specified time intervals:
</para>
<para>
new_delay = Minimum(old_delay * 2, offline_timeout_max) + random[0...offline_timeout_random_offset]
</para>
<para>
This parameter controls the value of the random offset
used for the above equation. Final random_offset value
will be random number in range:
</para>
<para>
[0 - offline_timeout_random_offset]
</para>
<para>
A value of 0 disables the random offset addition.
</para>
<para>
Default: 30
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>responder_idle_timeout</term>
<listitem>
<para>
This option specifies the number of seconds that
an SSSD responder process can be up without being
used. This value is limited in order to avoid
resource exhaustion on the system.
The minimum acceptable value for this option is 60
seconds.
Setting this option to 0 (zero) means that no
timeout will be set up to the responder.
This option only has effect when SSSD is built with
systemd support and when services are either socket
or D-Bus activated.
</para>
<para>
Default: 300
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>cache_first</term>
<listitem>
<para>
This option specifies whether the responder should
query all caches before querying the Data Providers.
</para>
<para>
Default: false
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect2>
<refsect2 id='NSS'>
<title>NSS configuration options</title>
<para>
These options can be used to configure the
Name Service Switch (NSS) service.
</para>
<variablelist>
<varlistentry>
<term>enum_cache_timeout (integer)</term>
<listitem>
<para>
How many seconds should nss_sss cache enumerations
(requests for info about all users)
</para>
<para>
Default: 120
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>entry_cache_nowait_percentage (integer)</term>
<listitem>
<para>
The entry cache can be set to automatically update
entries in the background if they are requested
beyond a percentage of the entry_cache_timeout
value for the domain.
</para>
<para>
For example, if the domain's entry_cache_timeout
is set to 30s and entry_cache_nowait_percentage is
set to 50 (percent), entries that come in after 15
seconds past the last cache update will be
returned immediately, but the SSSD will go and
update the cache on its own, so that future
requests will not need to block waiting for a
cache update.
</para>
<para>
Valid values for this option are 0-99 and
represent a percentage of the entry_cache_timeout
for each domain. For performance reasons, this
percentage will never reduce the nowait timeout to
less than 10 seconds.
(0 disables this feature)
</para>
<para>
Default: 50
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>entry_negative_timeout (integer)</term>
<listitem>
<para>
Specifies for how many seconds nss_sss should cache
negative cache hits (that is, queries for
invalid database entries, like nonexistent ones)
before asking the back end again.
</para>
<para>
Default: 15
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>local_negative_timeout (integer)</term>
<listitem>
<para>
Specifies for how many seconds nss_sss should keep
local users and groups in negative cache before
trying to look it up in the back end again. Setting
the option to 0 disables this feature.
</para>
<para>
Default: 14400 (4 hours)
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>filter_users, filter_groups (string)</term>
<listitem>
<para>
Exclude certain users or groups from being fetched
from the sss NSS database. This is particularly
useful for system accounts. This option can also
be set per-domain or include fully-qualified names
to filter only users from the particular domain or
by a user principal name (UPN).
</para>
<para>
NOTE: The filter_groups option doesn't affect
inheritance of nested group members, since
filtering happens after they are propagated for
returning via NSS. E.g. a group having a member
group filtered out will still have the member
users of the latter listed.
</para>
<para>
Default: root
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>filter_users_in_groups (bool)</term>
<listitem>
<para>
If you want filtered user still be group members
set this option to false.
</para>
<para>