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.
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-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-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.
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 |
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.
The dsservd daemon is also the LDAP server.
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.
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.
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.
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.
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.
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.
Do not use dsypinit to initialize the NIS service. Use dsypinstall, as described in "To Initialize the NIS Service".
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.
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.
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.
# /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".
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.
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.
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.
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.
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.
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.
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.
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 |
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.
This tree structure can be configured to suit your needs by modifying the mapping file /etc/opt/SUNWconn/ldap/current/mapping/nis.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
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.
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 |
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.
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.
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 |
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.
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 |
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 |
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 |
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 |
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 |
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 |
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.
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.
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