1NIS+LDAPmapping(4) File Formats NIS+LDAPmapping(4)
2
6 NIS+LDAPmapping - configuration file for mapping between NIS+ and LDAP
7
9 /var/nis/NIS+LDAPmapping
10
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 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 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
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 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 2. The NIS+ objects for which the rpc.nisd is a master are
46 mapped both to and from LDAP.
47 3. Those NIS+ objects for which the rpc.nisd is a replica are
49 mapped from LDAP.
50 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 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 6. The default values for TTLs and LDAP container locations and
59 object classes are valid.
60 7. The LDAP server supports RFC 2307bis. You want to use the
62 RFC 2307bis object classes and attributes. See Notes
63 8. The nisplusObject attribute, the nisplusObjectContainer
65 object class, and the ou=nisPlus container have been cre‐
66 ated.
67 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 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 user-or-host.my.dom.ain.
82 and
84 unix.uid-or-host@my.dom.ain
86 respectively.
88 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 If one or more of the assumptions are false, do the following:
98 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 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 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 For client_info:
120 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 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 For the ou=ClientInfo container, substitute your actual
148 search base for searchBase):
149 dn: ou=ClientInfo,searchBase
151 ou: ClientInfo
152 objectClass: top
153 objectClass: organizationalUnit
154 For timezone:
156 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 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 For the ou=Timezone container:
175 dn: ou=Timezone,searchBase
177 ou: Timezone
178 objectClass: top
179 objectClass: organizationalUnit
180 Uncomment the mapping attributes for timezone and
182 client_info in the mapping file, and restart the
183 rpc.nisd(1M) daemon.
184 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 To disable read mapping, remove the readObjectSpec, leaving
191 the database id, two colons, and the writeObjectSpec value.
192 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 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 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 nisplusLDAPconfigProxyUser
210 nisplusLDAPproxyUser
211 The bind-DN to use for authentication.
213 nisplusLDAPconfigProxyPassword
216 nisplusLDAPproxyPassword
217 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 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 6. To change the TTLs, edit the nisplusLDAPentryTtl for the
230 appropriate database id.
231 To change LDAP container locations or object classes, edit
233 the nisplusLDAPobjectDN value for the appropriate database
234 id.
235 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 8. Refer to your LDAP server documentation for how to create
243 attributes and object classes, and set up the following:
244 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 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 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 dn: ou=nisPlus,dc=some,dc=domain
268 ou: nisPlus
269 objectClass: top
270 objectClass: organizationalUnit
271 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 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 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 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 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 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 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 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 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 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 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 LDAP Multi-valued attributes, where each value corresponds to one
368 database id.
369 File One line, which may be continued, for each value (database
372 id). The line starts with the name of the attribute
373 Command -x option for each value (database id).
376 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 nisplusLDAPdatabaseIdMapping
384 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 databaseId ":" objectspec
391 where
393 databaseId Label identifying a subset of a NIS+ object for map‐
395 ping purposes.
396 objectspec objectname | "[" indexlist "]" tablename
399 objectname The name of a NIS+ object (including tables)
402 tablename The name of a NIS+ table
405 indexlist colspec ["," colspec]
408 colspec colname "=" colvalue
411 colname The name of a column in the table
414 colvalue colvaluestring | \" colvaluestring \"
417 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 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 The following example shows how to associate the passwd database id
436 with the passwd.org_dir table:
437 passwd:passwd.org_dir
439 The following example shows how to associate the LOCAL entries in
441 the cred.org_dir table with the credlocal database id:
442 credlocal:[auth_type=LOCAL]cred.org_dir
444 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 creduser:[auth_type="D*",auth_name="unix.[0-9]*"]cred.org_dir
451 nisplusLDAPentryTtl
455 Establish TTLs for NIS+ entries derived from LDAP. The syntax of
457 the value is:
458 databaseId ":" initialTTLlo ":" initialTTLhi ":" runningTTL
460 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 initialTTLhi The upper limit for the initial TTL. If left empty,
474 it defaults to 5400.
475 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 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 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 hosts:7200:10800:14400
500 nisplusLDAPobjectDN
504 Specifies the connection between a databaseId and the LDAP direc‐
506 tory. The syntax of the value is:
507 databaseId ":" objectDN *( ";" objectDN )
509 objectDN readObjectSpec [":"[writeObjectSpec]]
512 readObjectSpec [baseAndScope [filterAttrValList]]
515 writeObjectSpec [baseAndScope [attrValList [":" deleteDisp]]]
518 baseAndScope [baseDN] ["?" [scope]]
521 filterAttrValList ["?" [filter | attrValList]]
524 scope "base" | "one" | "sub"
527 attrValList attribute "=" value *("," attribute "=" value)
530 deleteDisp "always" | perDbId | "never"
533 perDbId "dbid" "=" delDatabaseId
536 delDatabaseId database id per nisplusLDAPdatabaseIdMapping
539 above.
540 The baseDN defaults to the value of the defaultSearchBase
542 attribute. If the baseDN ends in a comma, the defaultSearchBase is
543 appended.
544 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 objectClass=posixAccount,objectClass=shadowAccount
554 is converted to the filter:
556 (&(objectClass=posixAccount)(objectClass=shadowAccount))
558 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 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 Note that writes only are attempted by a master server for the
570 mapped NIS+ object. Replicas silently ignore any writeObjectSpec:s.
571 The deleteDisp specifies how NIS+ object deletion should be
573 reflected in LDAP. The following values are recognized:
574 always Always attempt to remove the LDAP entry. This
576 is the default.
577 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 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 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 ipnodes:ou=Hosts,?one?objectClass=ipHost:
607 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 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 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 passwd:ou=People,?one?objectClass=shadowAccount,\
627 objectClass=posixAccount::\
628 dbid=passwd_delete
629 where nisplusLDAPattributeFromColumn for passwd_delete could be:
631 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 nisplusLDAPcolumnFromAttribute
651 Specifies how a NIS+ table and column value is derived from LDAP
653 attribute values. The syntax is:
654 databaseId ":" colattrspec *("," colattrspec)
656 The format of colattrspec is shown below in the discussion of the
658 column and attribute conversion syntax.
659 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 addr=ipHostNumber
665 Formats for the column and attribute conversion syntax are dis‐
667 cussed below, including examples of complex attribute to column
668 conversions..
669 There are four special pseudo-columns that are used to indicate
671 non-column entry object data:
672 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 zo_group The NIS+ group owner of the entry object. By default,
679 the zo_group value is inherited from the table.
680 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 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 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 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 nisplusLDAPattributeFromColumn
713 Specifies how an LDAP attribute value is derived from NIS+ table
715 and column values. The syntax is:
716 databaseId ":" colattrspec *("," colattrspec )
718 The format of colattrspec is shown below in the discussion of the
720 column and attribute conversion syntax.
721 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 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 ipHostNumber=addr
730 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 Column and Attribute Conversion Syntax
737 The general format of a colattrspec is:
738 colattrspec = lhs "=" rhs
740 lhs = lval | namespeclist
741 rhs = rval | [namespec]
742 namespeclist = namespec | "(" namespec *("," namespec) ")"
743 The lval and rval syntax are defined below at Values. The format of a
747 namespec is:
748 namespec ["ldap:"] attrspec [searchTriple] | ["nis+:"] colspec
750 [objectspec]
751 colspec column | "(" column ")"
754 attrspec attribute | "(" attribute ")"
757 searchTriple ":" [baseDN] ["?" [scope] ["?" [filter]]]
760 baseDN Base DN for search
763 filter LDAP search filter
766 objectspec objectspec per nisplusLDAPdatabaseIdMapping
769 The repository specification in a namespec defaults as follows:
773 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 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 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 For columns, the (colname) syntax is used to map multiple attribute
791 instances to multiple NIS+ entries.
792 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 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 scope one
803 filter Empty
806 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 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 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 ldap:ipHostNumber:?one?("cn=%s", (cname, "%s.*"))
828 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 ("%s", namespec)
836 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 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 Wildcards
858 Where wildcard support is available, it is of the following limited
859 form:
860 * Matches any number of characters.
862 [x] Matches the character x.
865 [x-y] Matches any character in the range x to y, inclusive..
868 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 Substring Extraction
875 substringextract = "(" namespec "," matchspec ")"
876 name = column or attribute name
877 matchspec =
878 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 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 For example, if the column cname has the value user.some.domain.name.,
894 the value of the expression:
895 (cname, "%s.*")
897 is user, which can be used to extract the user name from a NIS+ princi‐
901 pal name.
902 Similarly, use this expression to extract the third of the colon-sepa‐
905 rated fields of the shadow column:
906 (shadow, "*:*:%s:*")
908 This form can be used to extract all of the shadow fields. However, a
912 simpler way to specify that special case is:
913 (shadow, ":")
915 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 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 The following ber_printf() format characters are recognized:
940 b i B n o s
942 If there are too few format specifiers, the format string may be
946 repeated as needed.
947 When used as an lval, there is a combination of pattern matching and
950 assignment, possibly to multiple columns or attributes.
951 For example, in an assignment to an attribute, if the value of the addr
954 column is 1.2.3.4, the rval:
955 ("ipNetworkNumber=%s,", addr)
957 produces the value ipNetworkNumber=1.2.3.4,, while:
961 ("(%s,%s,%s)", host, user, domain)
963 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 ("%s,", (mgrprfc822mailmember), ",")
971 concatenates all mgrprfc822mailmember values into one comma-separated
975 string, and then elides the final trailing comma. Thus, for
976 mgrprfc822mailmember=usera
978 mgrprfc822mailmember=userb
979 mgrprfc822mailmember=userc
980 the value would be usera,userb,userc.
984 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 ("%i", intval)
990 produces a value suitable for assignment to an integer-valued
994 attribute.
995 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 ("{%s}%s", auth_type, public_data)
1004 As a special case, to combine an LHS extraction with an RHS implicit
1008 list creates multiple entries and values. For example,
1009 ("(%s,%s,%s)", host, user, domain)=(nisNetgroupTriple)
1011 creates one NIS+ entry for each nisNetgroupTriple value.
1015 Assignments
1017 The assignment syntax, also found at Column and Attribute Conversion
1018 Syntax, is as follows:
1019 colattrspec = lhs "=" rhs
1021 lhs = lval | namespeclist
1022 rhs = rval | namespec
1023 namespeclist = namespec | "(" namespec *("," namespec) ")"
1024 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 ("%s", colname)=("%s", attrname)
1031 As a convenient short-hand, this can also be written as:
1035 colname=attrname
1037 A list specification, which is a name enclosed in parenthesis, can be
1041 used to make many-to-many assignments. The expression:
1042 (colname)=(attrname)
1044 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 (attrname)=(colname) Equivalent to attrname=colname
1053 attrname=(colname) Equivalent to attrname=colname
1056 (colname)=attrname Equivalent to colname=attrname
1059 colname=(attrname) Equivalent to colname=attrname
1062 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 Finally, the LHS might be an explicit list of columns or attributes,
1073 such as:
1074 (name1,name2,name3)
1076 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
1085 Example 1 Assigning an Attribute Value to a Column
1086 The following example illustrates how to assign the value of the
1089 ipHostNumber attribute to the addr column
1090 addr=ipHostNumber
1093 Example 2 Creating Multiple NIS+ Entries from Multi-Valued LDAP
1096 Attributes
1097 An LDAP entry with:
1100 cn=name1
1103 cn=name2
1104 cn=name3
1105 and the following assignments:
1109 cname=cn
1112 (name)=(cn
1113 creates three NIS+ entries (other attributes/columns omitted for clar‐
1117 ity):
1118 cname=name1, name=name1
1121 cname=name1, name=name2
1122 cname=name1, name=name3
1123 Example 3 Assigning String Constants
1126 The following expression sets the auth_type column to LOCAL:
1129 auth_type=("LOCAL")
1132 Example 4 Splitting Column Values to Multi-Valued Attributes
1135 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 (mgrprfc822mailmember)=(expansion, ",")
1143 Example 5 Splitting Column Values to Multiple Attributes
1146 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 (shadowLastChange,shadowMin,shadowMax,shadowWarning,\
1154 shadowInactive,shadowExpire,shadowFlag)=(shadow, ":")
1155
1158 /var/nis/NIS+LDAPmapping
1159 Default mapping file used by rpc.nisd(1M).
1161 /var/nis/NIS+LDAPmapping.template
1164 Template file covering the standard NIS+ directories and tables.
1166
1169 See attributes(5) for descriptions of the following attributes:
1170 ┌─────────────────────────────┬─────────────────────────────┐
1175 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
1176 ├─────────────────────────────┼─────────────────────────────┤
1177 │Availability │SUNWnisr │
1178 ├─────────────────────────────┼─────────────────────────────┤
1179 │Interface Stability │Obsolete │
1180 └─────────────────────────────┴─────────────────────────────┘
1181
1183 nisldapmaptest(1M), nisserver(1M), nissetup(1M), rpc.nisd(1M),
1184 ber_encode(3LDAP), rpc.nisd(4), attributes(5)
1185 System Administration Guide: Naming and Directory Services (DNS, NIS,
1188 and LDAP)
1189
1191 RFC 2307bis is an IETF informational document in draft stage that
1192 defines an approach for using LDAP as a naming service.
1193SunOS 5.11 13 Feb 2003 NIS+LDAPmapping(4)