NIS Information Mapping
The mapping of entries in NIS tables to LDAP attributes is defined in the file /etc/opt/SUNWconn/ldap/current/mapping/nis.mapping. This file is divided into sections that contain mapping information for each NIS table. At the beginning of the file, there is a Common section that contains configuration information that applies to every table.
The nis.mapping file is used by the following components:
-
The dsimport utility, to extract information from NIS files and convert it to LDAP directory entries.
-
The dsexport utility, to extract information from LDAP entries and restore the NIS files in their original format.
-
The dsservd daemon, to convert LDAP entries to NIS table entries. The dsservd daemon maintains up-to-date copies of all NIS tables held in the LDAP database to respond to synchronization requests from legacy NIS slaves.
-
The dsypxfrd daemon, to check that the tables specified in synchronization requests are supported by the mapping file.
The mapping definitions in the nis.mapping file specify the following:
-
The object class and attributes used to create an entry in the directory
-
The naming context under which the entries will be created
-
Case-sensitivity of the directory server for searches on the entries
Object Class and Attributes
The object class and attributes of an entry created from a NIS file are listed in the Import/Build section of the mapping definition for a given table. The values assigned to the LDAP attributes listed in the Build section are taken from the tokens specified in the other sections of the table definition.
A generic mapping is applied to all files listed in the NIS Makefile that do not have a specific mapping definition in the nis.mapping file. This mapping extracts the NIS key and NIS value information from any file and creates an entry based on the following generic NISobject object class, as follows:
|
cn |
nisKey (case-insensitive on LDAP searches) |
|
sunNisKey |
nisKey |
|
nisMapEntry |
nisValue |
|
nisMapName |
map name declared in makefile |
|
objectClass |
top |
|
nisSunObject |
The object classes and attributes created for all the standard NIS tables that are described in the mapping file are given below. To avoid repetition, the aliases file mapping is the only one that is commented in detail.
aliases
An entry in the aliases file is usually of the form:
aliasname: mailaddress1, mailaddress2, mailaddress3...
The mapping of this line in the nis.mapping file is shown below:
Table: mail.aliases
...
Import:
Extract:
LINE =>$aliasNameT:$aliasListT
Condense:
rfc822mailMembersT=string2instances($aliasListT,",")
trimrfc822mailMembersT=trim($rfc822mailMembersT)
objectClassT=string2instances("top nisMailAlias", " ")
Build:
dn=cn=$aliasNameT,$BASE_DN
cn=$aliasNameT
rfc822mailMember=$trimrfc822mailMembersT
objectClass=$objectClassT
In the Extract section, the keyword LINE shows the initial decomposition of a line in the aliases file. If in your aliases file you use a punctuation mark other than a colon to separate the alias name from the alias list, you must change the LINE definition to match your file format.
In the Condense section, the token definition for rfc822mailMembersT provides a further decomposition of the alias list. If in your aliases file you use a punctuation mark other than a comma to separate the elements in the alias list, you must change the token definition to match your file format.
The token definition for trimrfc822mailMemberT removes any unnecessary spaces from the result produced by the preceding string2instances operation on the alias list.
The token definition for objectClassT shows the inheritance hierarchy for the nisMailAlias object class.
In the Build section, the DN of the entry is created by concatenating the cn attribute and attribute value with the BASE_DN token. The BASE_DN token identifies the naming context under which the entry is created.
The rfc822mailMember and objectClass attributes are multi-valued. There is one occurrence of these attributes for each value resulting from the string2instances operations.
For example, the aliases file in the domain France.XYZ.com contains the following line:
dir-team: pdurand, jdupond, asantini, msmith, dphilippe, smartin
The DN of the directory entry created from this line in the aliases file is cn=dir-team, ou=Aliases, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
dir-team |
|
rfc822mailMember |
pdurand |
|
jdupond |
|
|
asantini |
|
|
msmith |
|
|
dphilippe |
|
|
smartin |
|
|
objectClass |
top |
|
nisMailAlias |
bootparams
An entry in the bootparams file is usually of the form:
hostname parameter1 parameter2 parameter3...parameterx
For example, the bootparams file in the domain France.XYZ.com contains the following line:
camembert root=server1:/export/camembert/root \ swap=server1:/export/camembert/swap \ domain=France.XYZ.com
The DN of the directory entry created from this line in the bootparams file is cn=camembert, ou=Hosts, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
camembert |
|
bootParameter |
root=server1:/export/roquefort/root |
|
swap=server1:/export/roquefort/swap |
|
|
domain=France.XYZ.com |
|
|
objectClass |
top |
|
device |
|
|
bootableDevice |
The host camembert probably also has an entry in /etc/ethers and in /etc/hosts. However, in the LDAP directory, the host camembert has just one entry, with all the attributes derived from the ethers table mapping and the hosts table mapping. The LDAP entry created for camembert has several object classes: one inherited structural object class, device, and three auxiliary object classes, bootableDevice, ieee802Device, and ipHost.
Based on the examples given in "ethers", and in "hosts", the complete entry created in the LDAP directory for host camembert is:
|
cn |
camembert |
|
bertie |
|
|
bootParameter |
root=server1:/export/roquefort/root |
|
swap=server1:/export/roquefort/swap |
|
|
domain=France.XYZ.com |
|
|
macAddress |
0:1:23:aa:bb:cc |
|
ipHostNumber |
123.456.789.1 |
|
description |
SS5 Pierre's Desktop |
|
objectClass |
top |
|
device |
|
|
bootableDevice |
|
|
ieee802Device |
|
|
ipHost |
If the entry for camembert is deleted from the bootparams file, the directory entry for camembert is updated by removing the bootableDevice object class and the bootParameter attributes which are specific to that object class.
ethers
An entry in the ethers file is usually of the form:
ethernetaddress machinename
For example, the ethers file in the domain France.XYZ.com contains the following line:
0:1:23:aa:bb:cc camembert
The DN of the directory entry created from this line in the ethers file is cn=camembert, ou=Hosts, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
camembert |
|
macAddress |
0:1:23:aa:bb:cc |
|
objectClass |
top |
|
device |
|
|
ieee802Device |
The host camembert may also have an entry in the /etc/bootparams file and the /etc/hosts file. See the example given in "bootparams" for details of the complete LDAP directory entry created from these files.
group
An entry in the group file is usually of the form:
groupname:password:groupidnumber:listofmembers
For example, the group file in the domain France.XYZ.com contains the following line:
sysadmin:yai957KJwXrjc:10:bgreen, hgrant, dbrown
The DN of the directory entry created from this line in the hosts file is cn=sysadmin, ou=Group, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
sysadmin |
|
gidNumber |
10 |
|
memberUid |
bgreen |
|
hgrant |
|
|
dbrown |
|
|
userPassword |
{crypt}yai957KJwXrjc |
|
objectClass |
top |
|
posixGroup |
hosts
An entry in the hosts file is usually of the form:
ipaddress hostname hostaliasnames #hostdescription
For example, the hosts file in the domain France.XYZ.com contains the following line:
123.456.789.1 camembert bertie # SS5 Pierre's Desktop
The DN of the directory entry created from this line in the hosts file is cn=camembert, ou=Hosts, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
camembert |
|
bertie |
|
|
ipHostNumber |
123.456.789.1 |
|
description |
SS5 Pierre's Desktop |
|
objectClass |
top |
|
device |
|
|
ipHost |
The host camembert may also have an entry in the /etc/bootparams file and the /etc/ethers file. See the example given in "bootparams" for details of the complete LDAP directory entry created from these files.
netgroup
An entry in the netgroup file is usually of the form:
netgroupname grouptriple grouptriple grouptriple grouptriple
where grouptriple is of the form (hostname, username, domainname).
For example, the netgroup file in the domain France.XYZ.com contains the following line:
printers\ (bordeaux,-,France.XYZ.com)\ (bourgogne,-,France.XYZ.com)\ (sauternes,-,France.XYZ.com)
The DN of the directory entry created from this line in the netgroup file is cn=printers, ou=netgroup, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
printers |
|
nisNetGroupTriple |
bordeaux,-,France.XYZ.com |
|
bourgogne,-,France.XYZ.com |
|
|
sauternes,-,France.XYZ.com |
|
|
objectClass |
top |
|
nisNetGroup |
networks
An entry in the networks file is usually of the form:
networkname networkaddress networkalias #description
For example, the networks file in the domain France.XYZ.com contains the following line:
XYZ-eng 123.456.789 eng #engineering subnetwork
The DN of the directory entry created from this line in the networks file is cn=XYZ-eng, ou=networks, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
XYZ-eng |
|
eng |
|
|
ipNetworkNumber |
123.456.789 |
|
description |
engineering subnetwork |
|
objectClass |
top |
|
ipNetwork |
passwd
An entry in the passwd file is usually of the form:
userid:userPasswd:uidnumber:gidnumber:gecos:homeDir:shell
When there is a shadow file associated with the passwd file, it is usually of the form:
userid:userPasswd:::::::
The user ID in the passwd file and in the shadow file are identical, but the user's password is actually stored in the shadow file and not in the passwd file.
For example, the passwd file in the domain France.XYZ.com contains the following line for Pierre Durand:
pdurand:x:12345:67:Pierre Durand - Project Manager:/home/pdurand:/bin/csh
The x instead of the user password indicates that the actual password is stored in the shadow file. The shadow file contains the following line for Pierre Durand:
pdurand:yai957KJwXrjc:::::::
The DN of the directory entry created from these lines in the passwd file and in the shadow file is uid=pdurand, ou=People, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
Pierre Durand |
|
uid |
pdurand |
|
userPassword |
{crypt}yai957KJwXrjc |
|
uidNumber |
12345 |
|
gidNumber |
67 |
|
gecos |
Pierre Durand - Project Manager |
|
homeDirectory |
/home/pdurand |
|
loginshell |
/bin/csh |
|
objectClass |
top |
|
account |
|
|
posixAccount |
protocols
An entry in the protocols file is usually of the form:
protocolname protocolnumber protocolalias #description
For example, the protocols file in the domain France.XYZ.com contains the following line:
tcp 0 TCP_Protocol #Transmission Control Protocol
The DN of the directory entry created from this line in the protocols file is cn=tcp, ou=protocols, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
tcp |
|
TCP_Protocol |
|
|
ipProtocolNumber |
0 |
|
description |
Transmission Control Protocol |
|
objectClass |
top |
|
ipProtocol |
rpc
An entry in the rpc file is usually of the form:
programname programnumber protocolalias #description
For example, the rpc file in the domain France.XYZ.com contains the following line:
yppasswdd 100123 yppasswd
The DN of the directory entry created from this line in the rpc file is cn=yppasswdd, ou=rpc, ou=Services, dc=France, dc=XYZ, dc=com. The attributes stored under that entry and their values are:
|
cn |
yppasswdd |
|
yppasswd |
|
|
oncRpcNumber |
100123 |
|
objectClass |
top |
|
oncRpc |
ypservers
In the NIS environment, the ypservers file contains a list of the NIS servers in the domain.
For example, the ypservers file in the domain France.XYZ.com contains the following list:
brie camembert emmental gorgonzola roquefort
A directory entry is created for each server listed in the file. For example, the DN of the entry created for the server brie is cn=brie, ou=ypservers, ou=Services, dc=France, dc=XYZ, dc=com. For example, the entry for the server brie contains:
|
cn |
brie |
|
objectClass |
top |
|
sunNisServer |
ACLs on NIS Information
NIS information in the LDAP directory is protected by a special set of ACLs. These are part of the dsserv.acl.conf file. The extract from this file is shown below.
# NIS ACLs
access to attrs=userPassword
by self write
by * compare
access to attrs=gecos,loginShell
by self write
By default, users have read permission on all attributes in their own entry, although they have write permission only on the userPassword, gecos, and loginShell attributes.
Configuring Naming Contexts
The naming contexts created for NIS entries during the initialization of the NIS service are specified in the nis.mapping file by the keyword BASE_DN. This base DN is the concatenation of an organizational unit (ou) specific to each map, and of a rootTree token that is usually common to several maps.
For example, the naming context for the entries created from the networks maps is defined by the following two lines in the nis.mapping file:
rootTreeT=ou=Services,$NAMING_SUFFIX||ou=Services,$DC_NAMING BASE_DN=ou=Networks,$rootTreeT
The directory entries created from the networks file are created under the ou=Networks, ou=Services naming context.
The choice of a naming structure through the NAMING_SUFFIX keyword or DC_NAMING keyword is a configuration decision. The DC_NAMING keyword contains a domain component (DC) suffix. The DNs of entries created with that naming structure have a suffix of the form dc=XYZ, dc=com. This is the default choice when you initialize the NIS service, because the import process derives A DC naming suffix from the domain name you supply during the dsypinstall process.
If you prefer to use a different suffix, you must un-comment the NAMING_SUFFIX keyword at the beginning of the nis.mapping file, under the Common section for the front-end. Change the value of the NAMING_SUFFIX keyword to specify the suffix, or naming context under which you want NIS entries to be created. The value you specify must be a valid naming context in the data store. Refer to "Creating or Modifying a Data Store" for information on creating a naming context.
Do not comment out the DOMAIN_NAME keyword in the nis.mapping file. This keyword contains the domain name that you supplied during the dsypinstall process. It is used by the server to provide the NIS service.
Case-Sensitivity
As a general rule, the directory server performs a case-sensitive search if the attribute on which the search is performed is case sensitive (ces syntax). Similarly, a search is not case sensitive if the attribute on which the search is performed is case insensitive (cis syntax).
However, it is possible to force case-sensitivity over attribute syntax by using the keyword CASE_SENSITIVE=yes in the mapping definition of a table in the nis.mapping file.
For example, the uid attribute has a cis syntax. In this case, for security reasons, it is important to force case sensitivity. Therefore, the passwd.byname definition in the nis.mapping file, includes the CASE_SENSITIVE keyword:
Table: passwd.byname Common: MAP_NAME=passwd.byname # The LDAP attribute used to store the key (uid) is case insensitive! CASE_SENSITIVE=yes
- © 2010, Oracle Corporation and/or its affiliates