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
|
<refsect1 id='idmap'>
<title>CORRESPONDANCE D'IDENTIFIANTS</title>
<para>
La fonctionnalité de correspondance d'ID permet à SSSD d'agir comme un
client de Active Directory sans demander aux administrateurs d'étendre les
attributs utilisateur pour prendre en charge les attributs POSIX pour les
identifiants d'utilisateur et de groupe.
</para>
<para>
Remarque : Lorsque la mise en correspondance des ID est activée, les
attributs uidNumber et gidNumber sont ignorés. Ceci afin d'éviter les
risques de conflit entre les valeurs attribuées automatiquement et assignées
manuellement. Si vous avez besoin d'utiliser des valeurs attribuées
manuellement, TOUTES les valeurs doivent être assignées manuellement.
</para>
<para>
Please note that changing the ID mapping related configuration options will
cause user and group IDs to change. At the moment, SSSD does not support
changing IDs, so the SSSD database must be removed. Because cached passwords
are also stored in the database, removing the database should only be
performed while the authentication servers are reachable, otherwise users
might get locked out. In order to cache the password, an authentication must
be performed. It is not sufficient to use <citerefentry>
<refentrytitle>sss_cache</refentrytitle> <manvolnum>8</manvolnum>
</citerefentry> to remove the database, rather the process consists of:
<itemizedlist>
<listitem>
<para>
Making sure the remote servers are reachable
</para>
</listitem>
<listitem>
<para>
Arrêter le service SSSD
</para>
</listitem>
<listitem>
<para>
Supprimer la base de donnée
</para>
</listitem>
<listitem>
<para>
Démarrer le service SSSD
</para>
</listitem>
</itemizedlist>
Moreover, as the change of IDs might necessitate the adjustment of other
system properties such as file and directory ownership, it's advisable to
plan ahead and test the ID mapping configuration thoroughly.
</para>
<refsect2 id='idmap_algorithm'>
<title>Algorithme de correspondance</title>
<para>
Active Directory fournit un objectSID pour chaque objet d'utilisateur et de
groupe dans l'annuaire. Cet objectSID peut être divisé en composants qui
représentent l'identité de domaine Active Directory et l'identificateur
relatif (RID) de l'objet utilisateur ou groupe.
</para>
<para>
L'algorithme de mise en correspondance des ID de SSSD tient un éventail
d'uid disponibles et le divise en sections de même taille, appelées «
tranches ». Chaque tranche représente l'espace disponible dans un domaine
Active Directory.
</para>
<para>
Lorsqu'une entrée d'utilisateur ou de groupe pour un domaine particulier est
rencontrée pour la première fois, SSSD alloue une des plages disponibles
pour ce domaine. Afin de rendre cette affectation de plage reproductible sur
les ordinateurs clients différents, l'algorithme de sélection de plage
suivant est utilisé :
</para>
<para>
La chaîne du SID est passée par l'intermédiaire de l'algorithme murmurhash3
pour le convertir en une valeur de hachage de 32 bits. Nous prenons ensuite
le modulo de cette valeur avec le nombre total des tranches disponibles pour
prendre la tranche.
</para>
<para>
Remarque : Il est possible de rencontrer les collisions dans le hachage et
le modulo en découlant. Dans ces situations, la tranche suivante disponible
sera sélectionnée, mais il n'est pas possible de reproduire le même jeu
exact des tranches sur d'autres machines (puisque l'ordre dans lequel elles
sont rencontrées déterminera leur tranche). Dans ce cas, il est recommandé
de passer à l'utilisation des attributs POSIX explicites dans Active
Directory (en désactivant la correspondance d'ID) ou configurer un domaine
par défaut afin de garantir qu'au moins un est toujours cohérent. Pour plus
d'informations, voir <quote>Configuration</quote>.
</para>
</refsect2>
<refsect2 id='idmap_config'>
<title>Configuration</title>
<para>
Configuration minimale (dans la section <quote>[domain/DOMAINNAME]</quote>)
:
</para>
<para>
<programlisting>
ldap_id_mapping = True
ldap_schema = ad
</programlisting>
</para>
<para>
The default configuration results in configuring 10,000 slices, each capable
of holding up to 200,000 IDs, starting from 200,000 and going up to
2,000,200,000. This should be sufficient for most deployments.
</para>
<refsect3 id='idmap_advanced_config'>
<title>Configuration avancée</title>
<variablelist>
<varlistentry>
<term>ldap_idmap_range_min (integer)</term>
<listitem>
<para>
Specifies the lower (inclusive) bound of the range of POSIX IDs to use for
mapping Active Directory user and group SIDs. It is the first POSIX ID which
can be used for the mapping.
</para>
<para>
NOTE : Cette option est différente de <quote>min_id</quote> en ce sens que
<quote>min_id</quote> agit comme filtre sur le résultat des requêtes vers ce
domaine, alors que cette option contrôle les plages de correspondance
d'ID. Il s'agit d'une distinction subtile, mais les bonnes pratiques
conseillent d'avoir <quote>min_id</quote> inférieur ou égal à
<quote>ldap_idmap_range_min</quote>
</para>
<para>
Par défaut : 200000
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ldap_idmap_range_max (integer)</term>
<listitem>
<para>
Specifies the upper (exclusive) bound of the range of POSIX IDs to use for
mapping Active Directory user and group SIDs. It is the first POSIX ID which
cannot be used for the mapping anymore, i.e. one larger than the last one
which can be used for the mapping.
</para>
<para>
NOTE : Cette option est différente de <quote>max_id</quote> en ce sens que
<quote>max_id</quote> agit comme filtre sur le résultat des requêtes vers ce
domaine, alors que cette option contrôle les plages de correspondance
d'ID. Il s'agit d'une distinction subtile, mais les bonnes pratiques
conseillent d'avoir <quote>max_id</quote> supérieur ou égal à
<quote>ldap_idmap_range_max</quote>
</para>
<para>
Par défaut : 2000200000
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ldap_idmap_range_size (integer)</term>
<listitem>
<para>
Spécifie le nombre d'identifiants pour chaque tranche. Si la taille de la
plage ne divise pas uniformément dans les valeurs minimale et maximale, des
tranches complètes seront créées autant que possible.
</para>
<para>
NOTE: The value of this option must be at least as large as the highest user
RID planned for use on the Active Directory server. User lookups and login
will fail for any user whose RID is greater than this value.
</para>
<para>
For example, if your most recently-added Active Directory user has
objectSid=S-1-5-21-2153326666-2176343378-3404031434-1107,
<quote>ldap_idmap_range_size</quote> must be at least 1108 as range size is
equal to maximal SID minus minimal SID plus one (e.g. 1108 = 1107 - 0 + 1).
</para>
<para>
It is important to plan ahead for future expansion, as changing this value
will result in changing all of the ID mappings on the system, leading to
users with different local IDs than they previously had.
</para>
<para>
Par défaut : 200000
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ldap_idmap_default_domain_sid (chaîne)</term>
<listitem>
<para>
Spécifier le SID de domaine du domaine par défaut. Cela garantira que ce
domaine est toujours affecté à la tranche zéro dans la carte d'ID, sans
passer par l'algorithme murmurhash décrit ci-dessus.
</para>
<para>
Par défaut : non défini
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ldap_idmap_default_domain (chaîne)</term>
<listitem>
<para>
Spécifier le nom de domaine par défaut.
</para>
<para>
Par défaut : non défini
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ldap_idmap_autorid_compat (boolean)</term>
<listitem>
<para>
Modifie le comportement de l'algorithme de mise en correspondance des ID
afin qu'il se comporte de manière identique à celui
<quote>idmap_autorid</quote> de winbind.
</para>
<para>
When this option is configured, domains will be allocated starting with
slice zero and increasing monotonically with each additional domain.
</para>
<para>
Remarque : Cet algorithme n'est pas déterministe (il dépend de l'ordre dans
lequel utilisateurs et groupes sont invités). Si ce mode est nécessaire pour
assurer la compatibilité avec les ordinateurs qui utilisent winbind, il est
recommandé d'utiliser également l'option
<quote>ldap_idmap_default_domain_sid</quote> pour garantir qu'au moins un
domaine est systématiquement alloué à la tranche zéro.
</para>
<para>
Par défaut : False
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>ldap_idmap_helper_table_size (integer)</term>
<listitem>
<para>
Maximal number of secondary slices that is tried when performing mapping
from UNIX id to SID.
</para>
<para>
Note: Additional secondary slices might be generated when SID is being
mapped to UNIX id and RID part of SID is out of range for secondary slices
generated so far. If value of ldap_idmap_helper_table_size is equal to 0
then no additional secondary slices are generated.
</para>
<para>
Par défaut : 10
</para>
</listitem>
</varlistentry>
</variablelist>
</refsect3>
</refsect2>
<refsect2 id='well_known_sids'>
<title>SID bien connus</title>
<para>
SSSD supports to look up the names of Well-Known SIDs, i.e. SIDs with a
special hardcoded meaning. Since the generic users and groups related to
those Well-Known SIDs have no equivalent in a Linux/UNIX environment no
POSIX IDs are available for those objects.
</para>
<para>
The SID name space is organized in authorities which can be seen as
different domains. The authorities for the Well-Known SIDs are
<itemizedlist>
<listitem><para>Null Authority</para></listitem>
<listitem><para>World Authority</para></listitem>
<listitem><para>Local Authority</para></listitem>
<listitem><para>Creator Authority</para></listitem>
<listitem><para>Mandatory Label Authority</para></listitem>
<listitem><para>Authentication Authority</para></listitem>
<listitem><para>NT Authority</para></listitem>
<listitem><para>Built-in</para></listitem>
</itemizedlist>
The capitalized version of these names are used as domain names when
returning the fully qualified name of a Well-Known SID.
</para>
<para>
Since some utilities allow to modify SID based access control information
with the help of a name instead of using the SID directly SSSD supports to
look up the SID by the name as well. To avoid collisions only the fully
qualified names can be used to look up Well-Known SIDs. As a result the
domain names <quote>NULL AUTHORITY</quote>, <quote>WORLD AUTHORITY</quote>,
<quote>LOCAL AUTHORITY</quote>, <quote>CREATOR AUTHORITY</quote>,
<quote>MANDATORY LABEL AUTHORITY</quote>, <quote>AUTHENTICATION
AUTHORITY</quote>, <quote>NT AUTHORITY</quote> and <quote>BUILTIN</quote>
should not be used as domain names in <filename>sssd.conf</filename>.
</para>
</refsect2>
</refsect1>
|
