1NIS+LDAPmapping(4)               File Formats               NIS+LDAPmapping(4)
2
3
4

NAME

6       NIS+LDAPmapping - configuration file for mapping between NIS+ and LDAP
7

SYNOPSIS

9       /var/nis/NIS+LDAPmapping
10
11

DESCRIPTION

13       The  /var/nis/NIS+LDAPmapping  configuration  file contains the mapping
14       between NIS+ objects, particularly table entries, and LDAP entries  and
15       attributes.  This  information can come from LDAP, from this file, from
16       the rpc.nisd(1M) command line, or from a combination of all three.  The
17       values  in this file supersede those obtained from the LDAP server, but
18       values from the command line supersede those in the file.
19
20
21       Each line in the file can be up to 8191 bytes long,  not  counting  the
22       newline.  There  can  be  an indefinite number of continuation lines. A
23       continuation is indicated by a '\' (backslash) in  the  last  position,
24       immediately  before the newline of a line. Characters are escaped, that
25       is, exempted from special interpretation, when preceeded by a backslash
26       character.
27
28
29       The  '#' (hash) character starts a comment. White space is either ASCII
30       space or a horizontal tab. In general, lines consist of optional  white
31       space,  an  attribute  name, at least one white space character, and an
32       attribute value.
33

EXTENDED DESCRIPTION

35   Getting Started
36       The default rpc.nisd(4) configuration file at /etc/default/rpc.nisd and
37       the  template  file at /var/nis/NIS+LDAPmapping.template are sufficient
38       for the minimum NIS+ installation. The following assumptions are made:
39
40           1.     The NIS+ standard directories, tables, and groups created by
41                  nissetup(1M) or nisserver(1M) should be mapped. However, the
42                  timezone.org_dir and client_info.org_dir tables  should  not
43                  be mapped.
44
45           2.     The  NIS+  objects  for  which  the rpc.nisd is a master are
46                  mapped both to and from LDAP.
47
48           3.     Those NIS+ objects for which the rpc.nisd is a  replica  are
49                  mapped from LDAP.
50
51           4.     The  LDAP server is running on the local machine, and it can
52                  be reached at port 389 on the 127.0.0.1 IP address.
53
54           5.     The authentication method is none,  meaning  that  all  LDAP
55                  calls,  whether for reading or writing, are unauthenticated.
56                  There is no transport layer security.
57
58           6.     The default values for TTLs and LDAP container locations and
59                  object classes are valid.
60
61           7.     The  LDAP  server  supports RFC 2307bis. You want to use the
62                  RFC 2307bis object classes and attributes. See Notes
63
64           8.     The  nisplusObject  attribute,  the   nisplusObjectContainer
65                  object  class,  and  the ou=nisPlus container have been cre‐
66                  ated.
67
68           9.     You do not need to store  or  retrieve  table  entry  owner,
69                  group  owner, entry access rights, or entry object TTL in or
70                  from LDAP. For more information on these pseudo-columns, see
71                  the discussion of zo_owner, and the like, in the description
72                  of the nisplusLDAPcolumnFromAttribute attribute.
73
74           10.    NIS+  principal  names  and  RPC  netnames  (the  cname  and
75                  auth_name  columns, respectively, in the cred.org_dir table)
76                  should be derived from the owner  of  the  cred  table.  For
77                  example,  if  the  owner is npadm.my.dom.ain., the cname and
78                  auth_name values for entries created from LDAP data will  be
79                  of the form:
80
81                    user-or-host.my.dom.ain.
82
83                  and
84
85                    unix.uid-or-host@my.dom.ain
86
87                  respectively.
88
89
90       If  these  assumptions  are true, you can enable mapping by copying the
91       /var/nis/NIS+LDAPmapping.template file to /var/nis/NIS+LDAPmapping  and
92       restart  the  rpc.nisd. If you want to either upload NIS+ data to LDAP,
93       or download LDAP data to NIS+, see the description of the  nisplusLDAP‐
94       initialUpdateAction attribute on rpc.nisd(4).
95
96
97       If one or more of the assumptions are false, do the following:
98
99           1.     To  remove  mappings,  identify  the database id of the NIS+
100                  object that should not be mapped, then delete or comment out
101                  the  nisplusLDAPdatabaseIdMapping, nisplusLDAPentryTtl, nis‐
102                  plusLDAPobjectDN, nisplusLDAPattributeFromColumn,  and  nis‐
103                  plusLDAPcolumnFromAttribute attributes for that database id.
104
105                  To  add mappings, find an existing mapping for a NIS+ object
106                  similar to the one you want to map, and then use  that  map‐
107                  ping  as  a template to create the nisplusLDAPdatabaseIdMap‐
108                  ping, nisplusLDAPentryTtl, nisplusLDAPobjectDN, nisplusLDAP‐
109                  attributeFromColumn,    and   nisplusLDAPcolumnFromAttribute
110                  attributes for the new mapping. The new mapping must have  a
111                  unique database id.
112
113                  To  enable  mapping  of  the timezone or client_info tables,
114                  consult your LDAP server documentation about how  to  create
115                  attributes and object classes, and set up the following. The
116                  following is LDIF data for ldapadd(1). Attribute and  object
117                  class OIDs are examples only.
118
119                  For client_info:
120
121                    dn: cn=schema
122                    changetype: modify
123                    add: attributetypes
124                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.12.0 \
125                       NAME 'nisplusClientInfoAttr' \
126                       DESC 'NIS+ client_info table client column' \
127                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
128                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.12.1 \
129                       NAME 'nisplusClientInfoInfo' \
130                       DESC 'NIS+ client_info table info column' \
131                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
132                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.12.2 \
133                       NAME 'nisplusClientInfoFlags' \
134                       DESC 'NIS+ client_info table flags column' \
135                       SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
136
137                    dn: cn=schema
138                    changetype: modify
139                    add: objectclasses
140                    objectclasses:  ( 1.3.6.1.4.1.42.2.27.5.42.42.13.0 \
141                       NAME 'nisplusClientInfoData' \
142                       DESC 'NIS+ client_info table data' \
143                       SUP top STRUCTURAL MUST ( cn ) \
144                       MAY (nisplusClientInfoAttr $ nisplusClientInfoInfo $ \
145                           nisplusClientInfoFlags))
146
147                  For  the  ou=ClientInfo  container,  substitute  your actual
148                  search base for searchBase):
149
150                    dn: ou=ClientInfo,searchBase
151                    ou: ClientInfo
152                    objectClass: top
153                    objectClass: organizationalUnit
154
155                  For timezone:
156
157                    dn: cn=schema
158                    changetype: modify
159                    add: attributetypes
160                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.15.0 \
161                              NAME 'nisplusTimeZone' \
162                              DESC 'tzone column from NIS+ timezone table' \
163                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
164
165                    dn: cn=schema
166                    changetype: modify
167                    add: objectclasses
168                    objectclasses:  ( 1.3.6.1.4.1.42.2.27.5.42.42.16.0 \
169                              NAME 'nisplusTimeZoneData' \
170                              DESC 'NIS+ timezone table data' \
171                              SUP top STRUCTURAL MUST ( cn ) \
172                              MAY ( nisplusTimeZone $ description ) )
173
174                  For the ou=Timezone container:
175
176                    dn: ou=Timezone,searchBase
177                    ou: Timezone
178                    objectClass: top
179                    objectClass: organizationalUnit
180
181                  Uncomment  the   mapping   attributes   for   timezone   and
182                  client_info   in   the   mapping   file,   and  restart  the
183                  rpc.nisd(1M) daemon.
184
185           2.     To disable write mapping, edit the nisplusLDAPobjectDN value
186                  for  the appropriate database id. Remove the writeObjectSpec
187                  value, leaving only  the  readObjectSpec  value.  Make  sure
188                  there are no trailing colons.
189
190                  To  disable read mapping, remove the readObjectSpec, leaving
191                  the database id, two colons, and the writeObjectSpec value.
192
193           3.     Replicas cannot write-map objects. Remove disable read  map‐
194                  ping, remove mapping entirely for the relevant database ids,
195                  as described above.
196
197           4.     Change the preferredServerList value to the  correct  server
198                  address(es)  and port(s). If configuration data is retrieved
199                  fromLDAP,  also  edit   the   nisplusLDAPpreferredServerList
200                  value.
201
202           5.     Edit the authenticationMethod attribute value to the authen‐
203                  tication method that you want to use. If configuration  data
204                  is  retrieved from LDAP, edit the nisplusLDAPconfigAuthenti‐
205                  cationMethod value. If the method  is  anything  other  than
206                  none, you will need to specify one or more of the following,
207                  depending upon the method.
208
209                  nisplusLDAPconfigProxyUser
210                  nisplusLDAPproxyUser
211
212               The bind-DN to use for authentication.
213
214
215           nisplusLDAPconfigProxyPassword
216           nisplusLDAPproxyPassword
217
218               The password or key for the bind-DN and method. Make sure  that
219               the  file  containing  the  password  or  key is protected from
220               access by unauthorized users.
221
222           To use transport layer security, set nisplusLDAPconfigTLS  or  nis‐
223           plusLDAPTLS  to  ssl, and set nisplusLDAPconfigTLSCertificateDBPath
224           or nisplusLDAPTLSCertificateDBPath to the file containing the  cer‐
225           tificate DB. In order to successfully use authentication and trans‐
226           port layer security, the server must also support the  chosen  val‐
227           ues.
228
229           6.     To  change  the  TTLs,  edit the nisplusLDAPentryTtl for the
230                  appropriate database id.
231
232                  To change LDAP container locations or object  classes,  edit
233                  the  nisplusLDAPobjectDN  value for the appropriate database
234                  id.
235
236           7.     To determine which object classes and  attributes  are  sup‐
237                  ported,  consult  your LDAP server documentation. If you are
238                  using the iPlanet directory server,  see  idsconfig(1M)  for
239                  information  to  set  up  RFC  2307bis  object  classes  and
240                  attributes.
241
242           8.     Refer to your LDAP server documentation for  how  to  create
243                  attributes and object classes, and set up the following:
244
245                    dn: cn=schema
246                    changetype: modify
247                    add: attributetypes
248                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.1.0 \
249                              NAME 'nisplusObject' \
250                              DESC 'An opaque representation of a NIS+ object' \
251                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE )
252
253                    dn: cn=schema
254                    changetype: modify
255                    add: objectclasses
256                    objectclasses: ( 1.3.6.1.4.1.42.2.27.5.42.42.2.0 \
257                             NAME 'nisplusObjectContainer' \
258                             SUP top STRUCTURAL DESC 'Abstraction of a NIS+ object' \
259                             MUST ( cn $ nisplusObject ) )
260
261
262                  ou=nisPlus  is a container assumed to reside at the default‐
263                  SearchBase. See rpc.nisd(4). The  following  LDIF  input  to
264                  ldapadd(1)  will  create  the  ou=nisPlus container. Replace
265                  dc=some,dc=domain with your actual base.
266
267                    dn: ou=nisPlus,dc=some,dc=domain
268                    ou: nisPlus
269                    objectClass: top
270                    objectClass: organizationalUnit
271
272                  The nisplusObjectContainer,  nisplusObject,  and  ou=nisPlus
273                  labels  are  suggestions.  If  you  change nisplusObjectCon‐
274                  tainer, or ou=nisPlus, edit  the  mapping  file  to  reflect
275                  this. To change nisplusObject, for example, to myObject, add
276                  nisplusObject=myObject to the filterAttrValList and attrVal‐
277                  List  portions  of the readObjectSpec and writeObjectSpec of
278                  the nisplusLDAPobjectDN  value  for  the  mapping.  See  the
279                  description of nisplusLDAPobjectDN below.
280
281           9.     Refer  to  your  LDAP server documentation for how to create
282                  attributes and object classes, and set up the following. The
283                  following  is LDIF data for ldapadd(1). Attribute and object
284                  class OIDs are examples only.
285
286                    dn: cn=schema
287                    changetype: modify
288                    add: attributetypes
289                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.0 \
290                              NAME 'nisplusEntryOwner' \
291                              DESC 'Opaque representation of NIS+ entry owner' \
292                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
293                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.1 \
294                              NAME 'nisplusEntryGroup' \
295                              DESC 'Opaque representation of NIS+ entry group' \
296                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
297                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.2 \
298                              NAME 'nisplusEntryAccess' \
299                              DESC 'Opaque representation of NIS+ entry access' \
300                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
301                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.4.3
302                              NAME 'nisplusEntryTtl' \
303                              DESC 'Opaque representation of NIS+ entry TTL' \
304                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
305
306                    dn: cn=schema
307                    changetype: modify
308                    add: objectclasses
309                    objectclasses:  ( 1.3.6.1.4.1.42.2.27.5.42.42.5.0 \
310                           NAME 'nisplusEntryData' \
311                           SUP top STRUCTURAL DESC 'NIS+ entry object non-column data' \
312                           MUST ( cn ) MAY ( nisplusEntryOwner $ nisplusEntryGroup $ \
313                           nisplusEntryAccess $ nisplusEntryTtl ) )
314
315                  Edit the mapping file to enable storing entry owner,  group,
316                  access,   and   TTL  in  LDAP.  The  template  mapping  file
317                  /var/nis/NIS+LDAPmapping.template has commented-out sections
318                  for  the passwd and cred database ids that show how this can
319                  be done.
320
321           10.    To  preserve  the  cname  and  auth_name  column  data  when
322                  cred.org_dir  entries are stored in NIS+, you can create the
323                  nisplusPrincipalName and nisplusNetname attributes. See your
324                  LDAP  server  documentation for how to create attributes and
325                  object classes, and set up the following:
326
327                    dn: cn=schema
328                    changetype: modify
329                    add: attributetypes
330                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.7.0 \
331                              NAME 'nisplusPrincipalName' \
332                              DESC 'NIS+ principal name' \
333                              EQUALITY caseIgnoreIA5Match SINGLE-VALUE \
334                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
335                    attributetypes: ( 1.3.6.1.4.1.42.2.27.5.42.42.9.0 \
336                              NAME 'nisplusNetname' \
337                              DESC 'Secure RPC netname' \
338                              EQUALITY caseIgnoreIA5Match SINGLE-VALUE \
339                              SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
340
341                    dn: cn=schema
342                    changetype: modify
343                    add: objectclasses
344                    objectclasses:  ( 1.3.6.1.4.1.42.2.27.5.42.42.10.0
345                             NAME 'nisplusAuthName' \
346                             SUP top AUXILLIARY DESC 'NIS+ authentication identifiers' \
347                             MAY ( nisplusPrincipalName $ nisplusNetname ) )
348
349                  Edit the mapping file to use  the  new  nisplusPrincipalName
350                  and  nisplusNetname.  The  template /var/nis/NIS+LDAPmapping
351                  file contains commented-out sections that support  the  nis‐
352                  plusPrincipalName  and  nisplusNetname  attributes.  See the
353                  nisplusLDAPobjectDN, nisplusLDAPattributeFromColumn and nis‐
354                  plusLDAPcolumnFromAttribute attribute values for the credlo‐
355                  cal, creduser, and crednode database ids .
356
357   Attributes for Data Mapping
358       The following attributes are recognized. Any values specified for these
359       attributes  in  the  file,  including  an  empty value, override values
360       obtained from LDAP.
361
362
363       There are several attributes that can have  multiple  values,  one  for
364       each  database  id.  Depending  on  the source, the multiple values are
365       specified in the following ways:
366
367       LDAP       Multi-valued attributes, where each value corresponds to one
368                  database id.
369
370
371       File       One  line,  which may be continued, for each value (database
372                  id). The line starts with the name of the attribute
373
374
375       Command     -x option for each value (database id).
376
377
378
379       Unless otherwise noted, all elements of the syntaxes below may be  sur‐
380       rounded  by  white  space. Separator characters and white space must be
381       escaped if they are part of syntactic elements.
382
383       nisplusLDAPdatabaseIdMapping
384
385           Maps a database id to a NIS+ object. If  the  object  name  is  not
386           fully  qualified,  that  is,  it  does  not  end in a dot, the nis‐
387           plusLDAPbaseDomain  is  appended.  See  rpc.nisd(4).  There  is  no
388           default value. The syntax of the value is:
389
390             databaseId ":" objectspec
391
392           where
393
394           databaseId    Label  identifying a subset of a NIS+ object for map‐
395                         ping purposes.
396
397
398           objectspec    objectname | "[" indexlist "]" tablename
399
400
401           objectname    The name of a NIS+ object (including tables)
402
403
404           tablename     The name of a NIS+ table
405
406
407           indexlist     colspec ["," colspec]
408
409
410           colspec       colname "=" colvalue
411
412
413           colname       The name of a column in the table
414
415
416           colvalue      colvaluestring | \" colvaluestring \"
417
418           The [indexlist]tablename form is intended for those cases where  it
419           is  necessary  to  select  a subset of a NIS+ table. The subset are
420           those NIS+ entries that match the indexlist. If there are  multiple
421           indexed  specifications for a particular NIS+ table, they are tried
422           in the order retrieved until one matches. Note that retrieval order
423           usually  is unspecified for multi-valued LDAP attributes. Hence, if
424           using indexed specifications when  nisplusLDAPdatabaseIdMapping  is
425           retrieved  from  LDAP, make sure that the subset match is unambigu‐
426           ous.
427
428           If the colvaluestring contains  white  space  or  commas,  it  must
429           either  be  surrounded  by double quotes, or the special characters
430           must be escaped.Wildcards are allowed in the colvaluestring. If the
431           objectname  or  tablename  is not fully qualified, the nisplusLDAP‐
432           baseDomain value is appended. If the objectname is empty the  value
433           of nisplusLDAPbaseDomain is substituted.
434
435           The following example shows how to associate the passwd database id
436           with the passwd.org_dir table:
437
438             passwd:passwd.org_dir
439
440           The following example shows how to associate the LOCAL  entries  in
441           the cred.org_dir table with the credlocal database id:
442
443             credlocal:[auth_type=LOCAL]cred.org_dir
444
445           The following example shows how to use the creduser database id for
446           those entries in the cred.org_dir table that represent  credentials
447           (keys)  for  users. That is, they have a netname (auth_name) of the
448           type unix.<numeric-id>@domain.
449
450             creduser:[auth_type="D*",auth_name="unix.[0-9]*"]cred.org_dir
451
452
453
454       nisplusLDAPentryTtl
455
456           Establish TTLs for NIS+ entries derived from LDAP.  The  syntax  of
457           the value is:
458
459             databaseId ":" initialTTLlo ":" initialTTLhi ":" runningTTL
460
461
462           initialTTLlo    The  lower  limit  for the initial TTL (in seconds)
463                           for data read from disk when the  rpc.nisd  starts,
464                           or  from  LDAP  during  an  initial  down-load. See
465                           rpc.nisd(4) for the description of the nisplusLDAP‐
466                           initialUpdate  attribute.  If  initialTTLhi also is
467                           specified, the actual initialTTL will  be  randomly
468                           selected  from  the  interval  initialTTLlo to ini‐
469                           tialTTLhi, inclusive. If the field is  left  empty,
470                           it yields the default value of 1800 seconds.
471
472
473           initialTTLhi    The upper limit for the initial TTL. If left empty,
474                           it defaults to 5400.
475
476
477           runningTTL      The TTL (in seconds) for data retrieved  from  LDAP
478                           while  the  rpc.nisd  is  running.  Leave the field
479                           empty to obtain the default value of 3600 seconds.
480
481           If there is no specification of TTLs for a  particular  databaseId,
482           the  default  values are used. If the initialTTLlo and initialTTLhi
483           have the same value, the effect will be that all data known to  the
484           rpc.nisd  at  startup times out at the same time. Depending on NIS+
485           data lookup patterns, this could cause spikes  in  rpc.nisd-to-LDAP
486           traffic.  In  order  to  avoid that, you can specify different ini‐
487           tialTTLlo and initialTTLhi values and obtain a  spread  in  initial
488           TTLs.  The  NIS+  object TTL is a separate and distinct entity used
489           for other purposes, notably the TTL of NIS+  directory  objects  in
490           the  shared  directory cache managed by the nis_cachemgr(1M). There
491           is no connection between the  nisplusLDAPentryTtl  and  object  TTL
492           values for a NIS+ object.
493
494           The following example shows how to specify that entries in the NIS+
495           hosts table read from LDAP should be valid for four hours. When the
496           rpc.nisd  restarts, the disk database entries are valid for between
497           two and three hours.
498
499             hosts:7200:10800:14400
500
501
502
503       nisplusLDAPobjectDN
504
505           Specifies the connection between a databaseId and the  LDAP  direc‐
506           tory. The syntax of the value is:
507
508             databaseId ":" objectDN *( ";" objectDN )
509
510
511           objectDN             readObjectSpec [":"[writeObjectSpec]]
512
513
514           readObjectSpec       [baseAndScope [filterAttrValList]]
515
516
517           writeObjectSpec      [baseAndScope [attrValList [":" deleteDisp]]]
518
519
520           baseAndScope         [baseDN] ["?" [scope]]
521
522
523           filterAttrValList    ["?" [filter | attrValList]]
524
525
526           scope                "base" | "one" | "sub"
527
528
529           attrValList          attribute "=" value *("," attribute "=" value)
530
531
532           deleteDisp           "always" | perDbId | "never"
533
534
535           perDbId              "dbid" "=" delDatabaseId
536
537
538           delDatabaseId        database  id  per nisplusLDAPdatabaseIdMapping
539                                above.
540
541           The  baseDN  defaults  to  the  value  of   the   defaultSearchBase
542           attribute.  If the baseDN ends in a comma, the defaultSearchBase is
543           appended.
544
545           scope defaults to one. It has  no  meaning  and  is  ignored  in  a
546           writeObjectSpec.  The  filter is an LDAP search filter. There is no
547           default value. The attrValList is a list  of  attribute  and  value
548           pairs.  There is no default value. As a convenience, if an attrVal‐
549           List is specified in a readObjectSpec, it is converted to a  search
550           filter  by  ANDing together the attributes and values. For example,
551           the attribute and value list:
552
553             objectClass=posixAccount,objectClass=shadowAccount
554
555           is converted to the filter:
556
557             (&(objectClass=posixAccount)(objectClass=shadowAccount))
558
559           Entry objects are mapped by means of  the  relevant  table  mapping
560           rules  in the nisplusLDAPattributeFromColumn and nisplusLDAPcolumn‐
561           FromAttribute attributes. Entry objects do not have  explicit  nis‐
562           plusLDAPobjectDN attributes.
563
564           If  a  writeObjectSpec  is omitted, and there is no trailing colon,
565           the effect is to not attempt writes at all. If there is a  trailing
566           colon after the readObjectSpec, it is implied that the writeObject‐
567           Spec is the same as the readObjectSpec.
568
569           Note that writes only are attempted by  a  master  server  for  the
570           mapped NIS+ object. Replicas silently ignore any writeObjectSpec:s.
571
572           The  deleteDisp  specifies  how  NIS+  object  deletion  should  be
573           reflected in LDAP. The following values are recognized:
574
575           always                Always attempt to remove the LDAP entry. This
576                                 is the default.
577
578
579           dbid=delDatabaseId    Set the mapped entries to values specified by
580                                 the nisplusLDAPattributeFromColumn  attribute
581                                 values  for  delDatabaseId.  This  only makes
582                                 sense for the databaseId:s  corresponding  to
583                                 NIS+  tables  or subsets of tables. For other
584                                 NIS+ objects,  if  dbid=  is  specified,  the
585                                 action  will be always. In the delDatabaseId,
586                                 deletion  of  individual  attributes  can  be
587                                 specified  by  leaving  the RHS of the = in a
588                                 mapping rule empty.  The  delDatabaseId  rule
589                                 set  should  specify  a  dn.  Otherwise,  the
590                                 rpc.nisd might try to derive a dn by perform‐
591                                 ing an LDAP lookup on the attributes and val‐
592                                 ues from the rule set,  quite  possibly  with
593                                 unexpected results.
594
595
596           never                 Upon  NIS+ object deletion, the corresponding
597                                 LDAP data is  left  unchanged.  If  the  NIS+
598                                 object  is an entry, this means that the only
599                                 effect of  the  deletion  is  to  temporarily
600                                 remove it from the rpc.nisd's cache.
601
602           The following is an example of how to get the ipnodes table entries
603           from the ou=Hosts container under  the  default  search  base,  and
604           write to the same place.
605
606             ipnodes:ou=Hosts,?one?objectClass=ipHost:
607
608           The  following example shows how to obtain the passwd table entries
609           from the ou=People containers under the default  search  base,  and
610           also  from  dc=another,dc=domain.  The  latter is an example of the
611           equivalent of and replacement for a NIS+ table path. Writes  should
612           only  be  attempted to the first objectDN. NIS+ entry deletions for
613           the first objectDN are not reflected in LDAP:
614
615             passwd:ou=People,?one?objectClass=shadowAccount,\
616                             objectClass=posixAccount::never;\
617                     ou=People,dc=another,dc=domain,?one?\
618                             objectClass=shadowAccount,\
619                             objectClass=posixAccount
620
621           The following example shows how to obtain the passwd table  entries
622           from  the  ou=People  container under the default search base. Upon
623           NIS+ entry deletion, update the LDAP entry  per  the  passwd_delete
624           database id:
625
626             passwd:ou=People,?one?objectClass=shadowAccount,\
627                             objectClass=posixAccount::\
628                     dbid=passwd_delete
629
630           where nisplusLDAPattributeFromColumn for passwd_delete could be:
631
632             passwd_delete:\
633                     dn=("uid=%s,", name), \
634                     uid=name, \
635                     userPassword=("*NP*"), \
636                     uidNumber=uid, \
637                     gidNumber=gid, \
638                     gecos=("INVALID: %s", gcos), \
639                     homeDirectory=home, \
640                     loginShell=("/bin/false"), \
641                     (shadowLastChange,shadowMin,shadowMax, \
642                      shadowWarning, shadowInactive,shadowExpire, \
643                      shadowFlag)=(shadow, ":"), \
644                     nisplusEntryOwner=zo_owner, \
645                     nisplusEntryGroup=zo_group, \
646                     nisplusEntryAccess=zo_access
647
648
649
650       nisplusLDAPcolumnFromAttribute
651
652            Specifies  how  a NIS+ table and column value is derived from LDAP
653           attribute values. The syntax is:
654
655             databaseId ":" colattrspec *("," colattrspec)
656
657           The format of colattrspec is shown below in the discussion  of  the
658           column and attribute conversion syntax.
659
660           The  following  is  an  example  of  how  to map by direct copy and
661           assignment the value of the ipHostNumber attribute to the addr col‐
662           umn:
663
664             addr=ipHostNumber
665
666           Formats  for  the  column  and attribute conversion syntax are dis‐
667           cussed below, including examples of  complex  attribute  to  column
668           conversions..
669
670           There  are  four  special  pseudo-columns that are used to indicate
671           non-column entry object data:
672
673           zo_owner     The NIS+ principal that  owns  the  entry  object.  By
674                        default,  the zo_owner value is inherited from the ta‐
675                        ble.
676
677
678           zo_group     The NIS+ group owner of the entry object. By  default,
679                        the zo_group value is inherited from the table.
680
681
682           zo_access    The  NIS+  access  rights  to  the entry. Table column
683                        rights are  stored  in  the  table.  By  default,  the
684                        zo_access value is inherited from the table.
685
686
687           zo_ttl       The  NIS+  TTL  for the entry. This is not the TTL for
688                        the entry when cached by the rpc.nisd. By default, the
689                        zo_ttl value is inherited from the table.
690
691           The default /var/nis/NIS+LDAPmapping.template assumes the existence
692           of the following corresponding LDAP attributes  in  the  containers
693           for the passwd and cred tables:
694             nisplusEntryOwner
695             nisplusEntryGroup
696             nisplusEntryAccess
697             nisplusEntryTtl
698           These  attributes are not part of any schema specified in an RFC or
699           similar document. They must be created if they are to be used. They
700           are  assumed to belong to the as nisplusEntryData object class, and
701           they contain a single string value. The format of  this  string  is
702           private, and subject to change without notice.
703
704           For  most  tables,  the non-column entry data can be inherited from
705           the  containing  table,  and  the  pseudo-columns  should  be  left
706           unmapped.  Notable  exceptions  are  the passwd and cred tables, if
707           individual users have access to modify their own  passwd  and  cred
708           entries.  This would usually be the case if the site is not running
709           the rpc.nispasswdd(1M) daemon.
710
711
712       nisplusLDAPattributeFromColumn
713
714           Specifies how an LDAP attribute value is derived  from  NIS+  table
715           and column values. The syntax is:
716
717             databaseId ":" colattrspec *("," colattrspec )
718
719           The  format  of colattrspec is shown below in the discussion of the
720           column and attribute conversion syntax.
721
722           As a special case, if the dn attribute value derived from a  colat‐
723           trspec  ends  in a comma (','), the baseDN from the writeObjectSpec
724           is appended.
725
726           The following is an example of how to map the  value  of  the  addr
727           column to the ipHostNumber attribute by direct copy and assignment:
728
729             ipHostNumber=addr
730
731           All  relevant attributes, including the dn, must be specified. Non-
732           column entry object data can be mapped as noted under  the  discus‐
733           sion of nisplusLDAPcolumnFromAttribute above.
734
735
736   Column and Attribute Conversion Syntax
737       The general format of a colattrspec is:
738
739         colattrspec     = lhs "=" rhs
740         lhs             = lval | namespeclist
741         rhs             = rval | [namespec]
742         namespeclist    = namespec | "(" namespec *("," namespec) ")"
743
744
745
746       The  lval  and rval syntax are defined below at Values. The format of a
747       namespec is:
748
749       namespec        ["ldap:"] attrspec [searchTriple] |  ["nis+:"]  colspec
750                       [objectspec]
751
752
753       colspec         column | "(" column ")"
754
755
756       attrspec        attribute | "(" attribute ")"
757
758
759       searchTriple    ":" [baseDN] ["?" [scope] ["?" [filter]]]
760
761
762       baseDN          Base DN for search
763
764
765       filter          LDAP search filter
766
767
768       objectspec      objectspec per nisplusLDAPdatabaseIdMapping
769
770
771
772       The repository specification in a namespec defaults as follows:
773
774           o      For  assignments to a column, nis+: on the LHS, ldap: on the
775                  RHS. NIS+ column values on the  RHS  are  those  that  exist
776                  before the NIS+ entry is modified.
777
778           o      For  assignments to an attribute, ldap: on the LHS, nis+: on
779                  the RHS. LDAP attribute values on the  RHS  are  those  that
780                  exist before the LDAP entry is modified.
781
782
783       Enclosing the column or attribute name in parenthesis denotes a list of
784       column or attribute values. For attributes, the meaning is the list  of
785       all attributes of that name, and the interpretation depends on the con‐
786       text. See the discussion at Values. This list specification is  ignored
787       when a searchTriple or objectspec is supplied.
788
789
790       For  columns,  the  (colname)  syntax is used to map multiple attribute
791       instances to multiple NIS+ entries.
792
793
794       The searchTriple can be used to specify an attribute  from  a  location
795       other than the read or write target. The defaults are as follows:
796
797       baseDN    If  omitted,  the  default  is  the  current objectDN. If the
798                 baseDN ends in a comma, the value  of  the  defaultSearchBase
799                 attribute is appended.
800
801
802       scope     one
803
804
805       filter    Empty
806
807
808
809       Similarly,  the objectspec can be used to specify a column value from a
810       NIS+ table other than the one implicitly indicated by  the  databaseId.
811       If  searchTriple  or  objectspec is explicitly specified in a namespec,
812       the retrieval or assignment, whether from or to LDAP or NIS+,  is  per‐
813       formed without checking if read and write are enabled for the LDAP con‐
814       tainer or NIS+ table.
815
816
817       Omitting the namespec in an rhs is only allowed if the lhs  is  one  or
818       more attributes. The effect is to delete the specified attribute(s). In
819       all other situations, an  omitted  namespec  means  that  the  rule  is
820       ignored.
821
822
823       The filter can be a value. See Values. For example, to find the ipHost‐
824       Number using the cn, you could specify  the  following  in  the  filter
825       field:
826
827         ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))
828
829
830
831       In  order  to remove ambiguity, the unmodified value of a single column
832       or attribute must be specified as the following when used in the filter
833       field.
834
835         ("%s", namespec)
836
837
838
839       If  the filter is not specified, the scope will be base, and the baseDN
840       is assumed to be the DN of the entry that contains the attribute to  be
841       retrieved  or  modified. To use previously existing column or attribute
842       values in the mapping rules requires a lookup  to  find  those  values.
843       Obviously,  this will add to the time required to perform the modifica‐
844       tion. Also, there is  a  window  between  the  time  when  a  value  is
845       retrieved,  and  then  slightly  later, stored back. If the values have
846       changed in the mean time, the change may be overwritten.
847
848
849       When colattrspecs are grouped into rule sets, in the value  of  a  nis‐
850       plusLDAPcolumnFromAttribute      or      nisplusLDAPattributeFromColumn
851       attribute, the evaluation of the colattrspecs  proceed  in  the  listed
852       order.  However, evaluation may be done in parallel for multiple colat‐
853       trspecs. If there is an error when evaluating  a  certain  colattrspec,
854       including retrieval or assignment of entry or column values, the extent
855       to which the other colattrspec rules are evaluated is unspecified
856
857   Wildcards
858       Where wildcard support is available, it is  of  the  following  limited
859       form:
860
861       *        Matches any number of characters.
862
863
864       [x]      Matches the character x.
865
866
867       [x-y]    Matches any character in the range x to y, inclusive..
868
869
870
871       Combinations  such  as [a-cA-C0123] are also allowed.This example would
872       match any one of a, b, c, A, B, C, 0, 1, 2, or 3.
873
874   Substring Extraction
875         substringextract = "(" namespec "," matchspec ")"
876         name             = column or attribute name
877         matchspec        =
878
879
880
881       The matchspec is a string like the scanf(3C) format string, except that
882       there  may  be  at  most  one format specifier, a single %s. The output
883       value of the substringextract is the substring matching the location of
884       the %s.
885
886
887       If  there  is  no  %s  in the formatstring, it must instead be a single
888       character, which is assumed to be a field separator for  the  namespec.
889       The  output  values  are the field values. Wild cards are supported. If
890       there is no match, the output value is the empty string, "".
891
892
893       For example, if the column cname has the value  user.some.domain.name.,
894       the value of the expression:
895
896         (cname, "%s.*")
897
898
899
900       is user, which can be used to extract the user name from a NIS+ princi‐
901       pal name.
902
903
904       Similarly, use this expression to extract the third of the  colon-sepa‐
905       rated fields of the shadow column:
906
907         (shadow, "*:*:%s:*")
908
909
910
911       This  form  can be used to extract all of the shadow fields. However, a
912       simpler way to specify that special case is:
913
914         (shadow, ":")
915
916
917   Values
918         lval           = "(" formatspec "," namespec *("," namespec) ")"
919         rval           = "(" formatspec ["," namelist ["," elide] ] ")"
920         namelist       = name_or_sse *( "," name_or_sse)
921         name_or_sse    = namespec | substringextract
922         formatspec     =
923         formatstring   = A string combining text and % field specifications
924         elide          =
925         singlechar     = Any character
926
927
928
929       This syntax is used to produce rval values that incorporate  column  or
930       attribute  values,  in  a manner like printf(3C), or to perform assign‐
931       ments to lval like scanf(3C). One important  restriction  is  that  the
932       format  specifications,%  plus a single character, use the designations
933       from ber_encode(3LDAP). Thus, while %s is  used  to  extract  a  string
934       value, %i causes BER conversion from an integer. Formats other than %s,
935       for instance, %i,  are  only  meaningfully  defined  in  simple  format
936       strings without any other text.
937
938
939       The following ber_printf() format characters are recognized:
940
941         b  i  B  n  o  s
942
943
944
945       If  there  are  too  few  format  specifiers,  the format string may be
946       repeated as needed.
947
948
949       When used as an lval, there is a combination of  pattern  matching  and
950       assignment, possibly to multiple columns or attributes.
951
952
953       For example, in an assignment to an attribute, if the value of the addr
954       column is 1.2.3.4, the rval:
955
956         ("ipNetworkNumber=%s,", addr)
957
958
959
960       produces the value ipNetworkNumber=1.2.3.4,, while:
961
962         ("(%s,%s,%s)", host, user, domain)
963
964
965
966       results   in   (assuming   host="xyzzy",   user="-",    domain="x.y.z")
967       "(xyzzy,-,x.y.z)".  The  elide character feature is used with attribute
968       lists. For example:
969
970         ("%s,", (mgrprfc822mailmember), ",")
971
972
973
974       concatenates all mgrprfc822mailmember values into  one  comma-separated
975       string, and then elides the final trailing comma. Thus, for
976
977         mgrprfc822mailmember=usera
978         mgrprfc822mailmember=userb
979         mgrprfc822mailmember=userc
980
981
982
983       the value would be usera,userb,userc.
984
985
986       If  the  NIS+  column intval is in binary format, that is, the B column
987       flag is set, and it is to be interpreted as an integer, the following:
988
989         ("%i", intval)
990
991
992
993       produces  a  value  suitable  for  assignment  to   an   integer-valued
994       attribute.
995
996
997       The  nisPublicKey  attribute  encodes  the  algorithm  type  and number
998       (equivalent to the auth_type column) and the public  key  as  a  single
999       string  such  as  {dh192-0}xxxxxxxx (public key truncated for clarity).
1000       The following will extract the corresponding  auth_type and public_data
1001       values:
1002
1003         ("{%s}%s", auth_type, public_data)
1004
1005
1006
1007       As  a  special  case, to combine an LHS extraction with an RHS implicit
1008       list creates multiple entries and values. For example,
1009
1010         ("(%s,%s,%s)", host, user, domain)=(nisNetgroupTriple)
1011
1012
1013
1014       creates one NIS+ entry for each nisNetgroupTriple value.
1015
1016   Assignments
1017       The assignment syntax, also found at Column  and  Attribute  Conversion
1018       Syntax, is as follows:
1019
1020         colattrspec    = lhs "=" rhs
1021         lhs            = lval | namespeclist
1022         rhs            = rval | namespec
1023         namespeclist   = namespec | "(" namespec *("," namespec) ")"
1024
1025
1026
1027       By using the syntax defined above, the general form of a simple assign‐
1028       ment, which is a one-to-one mapping of column to attribute, would be:
1029
1030         ("%s", colname)=("%s", attrname)
1031
1032
1033
1034       As a convenient short-hand, this can also be written as:
1035
1036         colname=attrname
1037
1038
1039
1040       A list specification, which is a name enclosed in parenthesis,  can  be
1041       used to make many-to-many assignments. The expression:
1042
1043         (colname)=(attrname)
1044
1045
1046
1047       where  there are multiple instances of attrname, creates one NIS+ entry
1048       for each such instance, differentiated by  their  colname  values.  The
1049       following  combinations of lists are allowed, but they are not particu‐
1050       larly useful:
1051
1052       (attrname)=(colname)    Equivalent to attrname=colname
1053
1054
1055       attrname=(colname)      Equivalent to attrname=colname
1056
1057
1058       (colname)=attrname      Equivalent to colname=attrname
1059
1060
1061       colname=(attrname)      Equivalent to colname=attrname
1062
1063
1064
1065       If a multi-valued RHS is assigned to a single-valued LHS, the LHS value
1066       will  be  the first of the RHS values. If the RHS is an attribute list,
1067       the first attribute is the first one returned by the LDAP  server  when
1068       queried.  Otherwise, the definition of "first" is implementation depen‐
1069       dent.
1070
1071
1072       Finally, the LHS might be an explicit list of  columns  or  attributes,
1073       such as:
1074
1075         (name1,name2,name3)
1076
1077
1078
1079       If the RHS is single-valued, this assigns the RHS value to all entities
1080       in the list. If the RHS is multi-valued, the first value is assigned to
1081       the  first  entity  of the list, the second value to the second entity,
1082       and so on. Excess values or entities are silently ignored.
1083

EXAMPLES

1085       Example 1 Assigning an Attribute Value to a Column
1086
1087
1088       The following example illustrates  how  to  assign  the  value  of  the
1089       ipHostNumber attribute to the addr column
1090
1091
1092         addr=ipHostNumber
1093
1094
1095       Example  2  Creating  Multiple  NIS+  Entries  from  Multi-Valued  LDAP
1096       Attributes
1097
1098
1099       An LDAP entry with:
1100
1101
1102         cn=name1
1103         cn=name2
1104         cn=name3
1105
1106
1107
1108       and the following assignments:
1109
1110
1111         cname=cn
1112         (name)=(cn
1113
1114
1115
1116       creates three NIS+ entries (other attributes/columns omitted for  clar‐
1117       ity):
1118
1119
1120         cname=name1, name=name1
1121         cname=name1, name=name2
1122         cname=name1, name=name3
1123
1124
1125       Example 3 Assigning String Constants
1126
1127
1128       The following expression sets the auth_type column to LOCAL:
1129
1130
1131         auth_type=("LOCAL")
1132
1133
1134       Example 4 Splitting Column Values to Multi-Valued Attributes
1135
1136
1137       The  expansion  column  contains a comma-separated list of alias member
1138       names. In the following example, the expression assigns each such  mem‐
1139       ber name to an instance of mgrprfc822mailmember:
1140
1141
1142         (mgrprfc822mailmember)=(expansion, ",")
1143
1144
1145       Example 5 Splitting Column Values to Multiple Attributes
1146
1147
1148       The  shadow  column contains a colon-separated list of fields. The fol‐
1149       lowing assigns the value of the first field  to  shadowLastChange,  the
1150       value of the second field to shadowMin, and so forth.
1151
1152
1153         (shadowLastChange,shadowMin,shadowMax,shadowWarning,\
1154                shadowInactive,shadowExpire,shadowFlag)=(shadow, ":")
1155
1156

FILES

1158       /var/nis/NIS+LDAPmapping
1159
1160           Default mapping file used by rpc.nisd(1M).
1161
1162
1163       /var/nis/NIS+LDAPmapping.template
1164
1165           Template file covering the standard NIS+ directories and tables.
1166
1167

ATTRIBUTES

1169       See attributes(5) for descriptions of the following attributes:
1170
1171
1172
1173
1174       ┌─────────────────────────────┬─────────────────────────────┐
1175       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
1176       ├─────────────────────────────┼─────────────────────────────┤
1177       │Availability                 │SUNWnisr                     │
1178       ├─────────────────────────────┼─────────────────────────────┤
1179       │Interface Stability          │Obsolete                     │
1180       └─────────────────────────────┴─────────────────────────────┘
1181

SEE ALSO

1183       nisldapmaptest(1M),    nisserver(1M),    nissetup(1M),    rpc.nisd(1M),
1184       ber_encode(3LDAP), rpc.nisd(4), attributes(5)
1185
1186
1187       System Administration Guide: Naming and Directory Services  (DNS,  NIS,
1188       and LDAP)
1189

NOTES

1191       RFC  2307bis  is  an  IETF  informational  document in draft stage that
1192       defines an approach for using LDAP as a naming service.
1193
1194
1195
1196SunOS 5.11                        13 Feb 2003               NIS+LDAPmapping(4)
Impressum