Sun Directory Services 3.1 Administration Guide

Chapter 6 Using the Directory as an NIS Server

The Network Information System (NIS) provides a robust and reliable naming service. However, it has certain limitations that may justify migrating to the NIS server provided with the Sun Directory Services.

This chapter explains how to migrate from an NIS naming service to Sun Directory Services. It describes the Sun Directory Services daemons that provide the NIS services and the NIS-to-LDAP information mapping.

Migrating from NIS to Sun Directory Services

The NIS server provided with the Sun Directory Services overcomes some of the limitations of a classic NIS naming service, namely:

A classic NIS server propagates whole tables, not just updates
A classic NIS server cannot handle very large tables, that is, tables that hold over 50,000 to 60,000 entries

If you have a well established NIS environment, the best way to manage the transition without disrupting your naming service is outlined below in Figure 6-1, Figure 6-2 and Figure 6-3.

Figure 6-1 shows a pure NIS environment with NIS requests from clients handled by the closest NIS server on the network. The synchronization of information held on master and slave servers is handled through NIS propagation of tables.

Figure 6-1 Pure NIS Environment

Figure 6-2 shows a progressive replacement of NIS slave servers by Sun Directory servers. Replacing slave servers before master servers is the recommended approach because the change will affect just some clients and not the entire network. This gives you the opportunity to adapt your procedures to the new tools. You can then apply these procedures when you do decide to migrate your NIS master servers to Sun Directory Services.

At this stage, your local slave servers also support LDAP clients. You must still use NIS for replication.

Figure 6-2 Mixed NIS - Sun Directory Services Environment

Figure 6-3 shows an environment where all legacy NIS servers have been replaced by Sun Directory Servers. Your servers support both NIS and LDAP requests, and you should use LDAP replication between master servers and slave servers.

Figure 6-3 Sun Directory Services Environment

NIS-LDAP Functional Equivalence

Using the Sun Directory Services, you can perform the same level of service as with NIS. Table 6-1 shows how the standard NIS functions are preserved in Sun Directory Services.

Table 6-1 LDAP-to-NIS Functional Equivalence


Sun Directory Services	Classic NIS	NIS Service
dsservd	ypserv	Server process that responds to NIS requests
dsyppasswdd	rpc.yppasswdd	Daemon used to modify the NIS `passwd` tables
dsypxfrd	ypxfrd	Daemon used to transfer NIS tables to synchronize master and slave servers
dsyppush	yppush	Command used on the master server to propagate updates to slave servers
dsypxfr	ypxfr	Command used on the slave NIS server to request an update from the NIS master
dsmakedbm	makedbm	Process that builds NIS tables from standard files
dsypinit	ypinit	Process that initializes NIS clients, NIS master servers and NIS slave servers
dsyprsvd	rpc.nisd_resolv	DNS access

dsservd

The dsservd daemon receives and responds to NIS requests in the same way as the NIS daemon ypserv. It supports NIS natively. It does not convert NIS requests to LDAP requests, and LDAP responses to NIS responses.

The dsservd daemon also maintains an up-to-date copy of the NIS tables so that propagation requests can be handled rapidly. It converts directory information to NIS tables based on the mapping information provided in the /etc/opt/SUNWconn/ldap/current/mapping/nis.mapping file.

For details of how to configure the dsservd daemon, refer to the dsservd(8) man page.

Note -

The dsservd daemon is also the LDAP server.

dsyppasswdd

The dsyppasswdd daemon manages changes to the password tables stored in the LDAP directory. It runs on the master server and responds to requests from users who invoke the passwd command to change their password, full name (in the gecos field) or shell. The dsyppasswdd daemon makes updates to the LDAP database, and also to the NIS passwd file. It also updates the shadow file when there is one.

For details of how to configure the dsyppasswdd daemon, refer to the dsyppasswdd(8) man page.

dsypxfrd

The dsypxfrd daemon manages the propagation of NIS tables from master servers to slave servers in the legacy NIS environment. It does not manage LDAP replication of NIS information. This process runs only on master servers.

The dsypxfrd daemon operates in the same way as the ypxfrd daemon in the NIS environment. It waits for a request from the dsypxfr process running on the slave server, then pushes the tables requested. To speed up the process the dsservd daemon holds an up-to-date copy of all NIS tables. This means that the NIS tables do not need to be built from the information held in the LDAP directory before they can be transferred.

For details of how to configure dsypxfrd, refer to the dsypxfrd(1m) man page.

dsyppush

The dsyppush command is used on a master server to propagate updates to NIS slave servers. It is called by the NIS Makefile in /var/yp. Also, when the Autopush option is set to On in the Admin Console, it is automatically activated when modifications are made to the directory.

For details on dsyppush, refer to the dsyppush(1m) man page.

dsypxfr

The dsypxfr command is used on a slave server to request updates from the NIS master server. It calls the dsypxfrd daemon that runs on the master server to update the local database. This update is performed using standard NIS propagation.

For details of how to use dsypxfr, refer to the dsypxfr(1m) man page.

dsmakedbm

The dsmakedbm command builds the NIS tables from the information held in the NIS source files. It is slightly different from the standard NIS makedbm command because it calls the dsimport utility to create NIS entries in the directory.

dsypinit

The dsypinit command is used to declare and initialize an NIS server as a master server or slave server. This command can also be used instead of the NIS standard ypinit command to initialize NIS clients.

For details of how to use dsypinit, refer to the dsypinit(1m) man page.

Note -

Do not use dsypinit to initialize the NIS service. Use dsypinstall, as described in "To Initialize the NIS Service".

dsyprsvd

The dsyprsvd daemon contacts the DNS server when the requested host information cannot be found in the NIS entries in the directory. This daemon runs only when the NIS server is configured to run in DNS interoperability mode. The NIS initialization script, dsypinstall, prompts you for this information.

For more information on dsyprsvd, refer to the dsyprsvd(1m) man page.

Initializing the Sun Directory Services NIS Service

The NIS service provided by Sun Directory Services preserves your existing NIS environment. It takes into account the customizations you may have made to the standard NIS environment. The initialization process modifies your existing NIS Makefile so that the make process calls dsmakedbm and dsimport instead of the standard NIS makedbm command. It also changes the yppush command to use dsyppush.

The NIS service provided by Sun Directory Services allows you to map NIS domain names to the LDAP directory tree by using a domain component (dc) naming structure. For example, information relative to the domain sales.XYZ.com can be stored in the LDAP directory under the subtree dc=sales, dc=XYZ, dc=com.

To Initialize the NIS Service

Install and license Sun Directory Services.

These tasks are described in the installation instructions.

When the package installation is complete, a message indicates that you must run the dsypinstall script to initialize the NIS service. However, before you do, you must perform the configuration steps described in this procedure.

Start the Admin Console.

This procedure is described in "Displaying the Admin Console".

Create the naming contexts that you will use to store NIS information.

You must create a naming context that is an appropriate domain component (DC) tree suffix for the domain that the server will manage. The initialization script will derive the naming contexts for NIS entries from the NIS domain name that you specify. For example, if you specify the domain name sales.XYZ.com, you must have a naming context of the form dc=XYZ, dc=com.

Alternatively, you can modify the nis.mapping file to specify a different naming structure from the default DC structure derived from the NIS domain name. For information, refer to "Configuring Naming Contexts".

To create a naming context, see "To Create a Data Store".

Backup your current NIS files and database.

As root, run dsypinstall:
```
# /opt/SUNWconn/sbin/dsypinstall
```
The dsypinstall script assumes that your Makefile is located in /var/yp. It also assumes that the source files for NIS tables are all located in the directory that you specify when prompted, except for the aliases file which is assumed to be in /etc/mail.

You are prompted to enter the name of the NIS domain managed by the server and to specify whether you want to enable DNS interoperability.

When the dsypinstall script has successfully finished, the NIS server is initialized and the LDAP directory database contains the information extracted from the NIS tables.

Check the NIS status displayed in the Admin Console.

If the Admin Console was running before you ran the dsypinstall script, in the Status section, click Check Status to display the current status.

In the Status section, the NIS service should be listed as Running, and automatic restart should be Enabled. In the NIS section, the NIS functional role should be shown as "NIS master server" or "NIS slave server" depending on how you declared the server during the dsypinstall initialization. The NIS section also shows the list of all the NIS maps supported by the server.

Run dejasync on the server. As root type:
```
# /opt/SUNWconn/ldap/sbin/dejasync
```
For details on the options of the dejasync(1m) command, refer to the man page. You must run dejasync if you want to use the Deja tool to modify NIS entries in the directory.

For details on how NIS information is imported and stored in the LDAP directory, refer to "NIS Information in the LDAP Directory".

Configuring the NIS Service

From the Admin Console, you can configure the following parameters for your NIS service:

The NIS domain name
The distinguished name of the subtree that will hold NIS administrative entries. These entries are maintained automatically by the server.
Whether or not you want to use standard NIS replication
Whether or not you want to include all directory entries: this option enables you to regenerate NIS maps to include entries present in the directory before the NIS service was initialized for the first time. These entries are not included in the import operation which takes place when the NIS service is initialized. You also need to use this option to regenerate an NIS map in the directory when the mapping configuration defined in the nis.mapping file has been modified.
Which maps are supported on the server
Whether you want updated information to be pushed automatically to slave servers when changes are made to NIS entries on this server, and the delay. To use this option, you must enable standard NIS replication.

To configure these parameters, go to the NIS section of the Admin Console main window.

Updating NIS Tables

Once you have populated the directory in this way for the first time, you have two options for data maintenance:

Make updates to the NIS files, and run make in the /var/yp directory
Make updates to the entries in the directory, for example using the Deja tool

Making updates to the entries in the directory is the most efficient method of maintaining NIS information, however the directory content will no longer be synchronized with the contents of the NIS files. If you want to resynchronize, you can export the NIS entries held in the directory to the corresponding NIS files by using dsexport. For details, see the dsexport(1m) man page.

The NIS maps are regenerated periodically from the entries stored in the directory. However, you can rebuild a map at any time from the Admin Console using the Regenerate Map function. This function will only take into account the entries stored in the directory, not the NIS source files. To regenerate an NIS map from the directory entries:

In the NIS section of the Admin Console, highlight a map in the map list.

Optionally, set the Include All Directory Entries option to yes.

This is useful if you want to regenerate a map immediately following the initialization of the NIS service, or if you have changed the mapping definition for that particular map in the nis.mapping file.

Click the Regenerate Map button.

Note -
When you include in the NIS maps maintained by the directory server the entries that were present before you initialized the NIS service, you must ensure that these entries do not create a security risk for your NIS service. For example, because users have write access to their own directory entry, it is possible for a user to change the uid attribute to become root user.

Propagating NIS Tables

There are two methods of propagating NIS tables between master servers and slave servers. Between two Sun Directory Services servers, choose LDAP replication. Between a Sun Directory Services server and a legacy NIS server, you must use standard NIS replication.

Note -

Do not use both LDAP replication and standard NIS replication on the same subtrees or individual entries. As a general rule, use only one replication method between two servers.

Standard NIS Replication

If you make updates to your NIS files rather than to NIS entries in the directory, when you run make to rebuild the NIS tables, the dsyppush command is automatically executed.

LDAP Replication

If you make updates to NIS entries in the directory, you can enable automatic pushes of all maps to take place using the Admin Console. Alternatively, you can use the Synchronize Replicas button at any time to push just the maps you select.

For information on configuring LDAP replication, see Chapter 9, Implementing Replication.

NIS Information in the LDAP Directory

The NIS information imported into the LDAP directory is extracted from standard NIS files, and from customers' proprietary files. Sun Directory Services provides a mapping of standard NIS information to LDAP attributes. The default nis.mapping file explicitly describes the information mapping for the following NIS files:

aliases
bootparams
ethers
group
hosts
netgroup
networks
passwd
protocols
rpc
ypservers

Mapping definitions for the following standard NIS files, and for proprietary NIS files listed in the NIS makefile, are not present in the default nis.mapping file. Mapping definitions for these files are created automatically when you run dsypinstall to initialize the NIS service:

auto_home
auto_master
netid
netmasks
publickey
services
timezone

The mapping definition for these files and any proprietary files is generic, and is identical for every map. The only difference is the map name.

Table 6-2 gives a summary of the type and location of LDAP entries for each NIS map. For details on configuring the mapping definition in the nis.mapping file, refer to "NIS Information Mapping".

Table 6-2 NIS/LDAP Mapping Summary


NIS Source File	NIS Maps	Object Class of Entries Created	Naming Context of entries created
`/etc/mail/aliases`	mail.aliases, mail.byaddr	nisMailAlias	ou=Aliases, ou=Services
`/etc/bootparams`	bootparams	bootableDevice	ou=Hosts, ou=Services
`/etc/ethers`	ethers.byaddr, ethers.byname	ieee802Device	ou=Hosts, ou=Services
`/etc/group`	group,byname, group.bygid	posixGroup	ou=Group, ou=Services
`/etc/hosts`	hosts.byaddr, hosts.byname	ipHost	ou=Hosts, ou=Services
`/etc/netgroup`	netgroup	nisNetGroup	ou=Netgroup, ou=Services
	netgroup.byhost	nisObject	ou=netgroup.byhost, ou=Services
	netgroup.byuser	nisObject	ou=netgroup.byuser, ou=Services
`/etc/networks`	networks.byname, networks.byaddr	ipNetwork	ou=Networks, ou=Services
`/etc/passwd`	passwd.byname, passwd.byuid	posixAccount	ou=People
`/etc/protocols`	protocols.byname, protocols.bynumber	ipProtocol	ou=Protocols, ou=Services
`/etc/rpc`	rpc.bynumber	oncRpc	ou=rpc, ou=Services
`/var/yp/binding/domainName`	ypservers	sunNisServer	ou=ypservers, ou=Services
All other maps listed in `makefile`	`mapName`	nisObject	ou=`mapName`, ou=Services

NIS Naming Contexts

During the NIS initialization phase, the information imported into the LDAP directory is organized according to the tree structure shown in Figure 6-4. In this figure, ou=mapName represents any map not defined in the default nis.mapping file, for example services.byname.

Figure 6-4 Tree Structure for NIS Information

This tree structure can be configured to suit your needs by modifying the mapping file /etc/opt/SUNWconn/ldap/current/mapping/nis.mapping.

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
objectClass	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
objectClass	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
cn	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
objectClass	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
cn	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
objectClass	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
cn	eng
ipNetworkNumber	123.456.789
description	engineering subnetwork
objectClass	top
objectClass	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
cn	TCP_Protocol
ipProtocolNumber	0
description	Transmission Control Protocol
objectClass	top
objectClass	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
cn	yppasswd
oncRpcNumber	100123
objectClass	top
objectClass	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
objectClass	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