System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP)

Part I About Naming and Directory Services

This part introduces the naming and directory services for the Solaris OS. It also describes the nsswitch.conf file that you use to coordinate the use of the different services.

Chapter 1 Naming and Directory Services (Overview)

This chapter provides an overview of naming and directory services used in Solaris. This chapter also briefly describes DNS, NIS, and LDAP naming services. See System Administration Guide: Naming and Directory Services (NIS+) for detailed information about NIS+.

What Is a Naming Service?

Naming services store information in a central place, which enables users, machines, and applications to communicate across the network. This information can include the following.

Without a central naming service, each machine would have to maintain its own copy of this information. Naming service information can be stored in files, maps, or database tables. If you centralize all data, administration becomes easier.

Naming services are fundamental to any computing network. Among other features, naming service provide functionality that does the following.

A network information service enables machines to be identified by common names instead of numerical addresses. This makes communication simpler because users do not have to remember and try to enter cumbersome numerical addresses like

For example, take a network of three machines that are named, pine, elm, and oak. Before pine can send a message to either elm or oak, pine must know their numerical network addresses. For this reason, pine keeps a file, /etc/hosts or /etc/inet/ipnodes, that stores the network address of every machine in the network, including itself.

Illustration shows pine, elm, and oak machines with respective
IP addresses listed on pine.

Likewise, in order for elm and oak to communicate with pine or with each other, the machines must keep similar files.

Illustration shows machines keeping all IP addresses
of machines on network in their respective /etc/hosts file.

In addition to storing addresses, machines store security information, mail data, network services information and so on. As networks offer more services, the list stored of information grows. As a result, each machine might need to keep an entire set of files which are similar to /etc/hosts or /etc/inet/ipnodes.

A network information service stores network information on a server, which can be queried by any machine.

The machines are known as clients of the server. The following figure illustrates the client-server arrangement. Whenever information about the network changes, instead of updating each client's local file, an administrator updates only the information stored by the network information service. Doing so reduces errors, inconsistencies between clients, and the sheer size of the task.

Illustration shows server and clients in client-server
computing relationship.

This arrangement, of a server providing centralized services to clients across a network, is known as client-server computing.

Although the main purpose of a network information service is to centralize information, the network information service can also simplify network names. For example, assume your company has set up a network which is connected to the Internet. The Internet has assigned your network the network number and the domain name Your company has two divisions, Sales and Manufacturing (Manf), so its network is divided into a main net and one subnet for each division. Each net has its own address.

Diagram shows and two subnets with IP addresses.

Each division could be identified by its network address, as shown above, but descriptive names made possible by naming services would be preferable.

Diagram shows and two subnets with descriptive

Instead of addressing mail or other network communications to, mail could be addressed to doc. Instead of addressing mail to or, mail could be addressed to sales.doc or manf.doc.

Names are also more flexible than physical addresses. Physical networks tend to remain stable, but company organization tends to change.

For example, assume that the network is supported by three servers, S1, S2, and S3. Assume that two of those servers, S1 and S3, support clients.

Illustration shows domain with three servers,
two of which have three clients each.

Clients C1, C2, and C3 would obtain their network information from server S1. Clients C4, C5, and C6 would obtain information from server S3. The resulting network is summarized in the following table. The table is a generalized representation of that network but does not resemble an actual network information map.

Table 1–1 Representation of network

Network Address 

Network Name 







C1, C2, C3 



C4, C5, C6 

Now, assume that you create a third division, Testing, which borrowed some resources from the other two divisions, but did not create a third subnet. The physical network would then no longer parallel the corporate structure.

Diagram shows adding third division called Test without
adding a third subnet.

Traffic for the Test Division would not have its own subnet, but would instead be split between and However, with a network information service, the Test Division traffic could have its own dedicated network.

Diagram shows Test Division with its own dedicated network.

Thus, when an organization changes, its network information service can change its mapping as shown here.

Illustration shows change in network mapping where some
clients move from one server to another.

Now, clients C1 and C2 would obtain their information from server S2. C3, C4 and C5 would obtain information from server S3.

Subsequent changes in your organization would be accommodated by changes to the network information structure without reorganizing the network structure.

Solaris Naming Services

The Solaris platform provides the following naming services.

Most modern networks use two or more of these services in combination. When more than one service is used, the services are coordinated by the nsswitch.conf file which is discussed in Chapter 2, The Name Service Switch (Overview).

Description of the DNS Naming Service

DNS is the naming service provided by the Internet for TCP/IP networks. DNS was developed so that machines on the network could be identified with common names instead of Internet addresses. DNS performs naming between hosts within your local administrative domain and across domain boundaries.

The collection of networked machines that use DNS are referred to as the DNS namespace. The DNS namespace can be divided into a hierarchy of domains. A DNS domain is a group of machines. Each domain is supported by two or more name servers, a principal server and one or more secondary servers. Each server implements DNS by running the in.named daemon. On the client's side, DNS is implemented through the “resolver.” The resolver's function is to resolve users' queries. The resolver queries a name server, which then returns either the requested information or a referral to another server.

Description of the /etc Files Naming Service

The original host-based UNIX naming system was developed for standalone UNIX machines and then adapted for network use. Many old UNIX operating systems and machines still use this system, but the system is not well suited for large complex networks.

Description of the NIS Naming Service

The Network Information Service (NIS) was developed independently of DNS. DNS makes communication simpler by using machine names instead of numerical IP addresses. NIS focuses on making network administration more manageable by providing centralized control over a variety of network information. NIS stores information about the network, machine names and addresses, users, and network services. This collection of network information is referred to as the NIS namespace.

NIS namespace information is stored in NIS maps. NIS maps were designed to replace UNIX /etc files, as well as other configuration files. NIS maps store much more than names and addresses. As a result, the NIS namespace has a large set of maps. See Working With NIS Maps for more information.

NIS uses a client-server arrangement which is similar to DNS. Replicated NIS servers provide services to NIS clients. The principal servers are called master servers, and for reliability, the servers have backup, or slave servers. Both master and slave servers use the NIS retrieval software and both store NIS maps. For more information on NIS Architecture and NIS Administration, see Chapter 5, Setting Up and Configuring NIS Service and Chapter 6, Administering NIS (Tasks).

Description of the NIS+ Naming Service

The Network Information Service Plus (NIS+) is similar to NIS but with more features. However, NIS+ is not an extension of NIS.

The NIS+ naming service is designed to conform to the shape of the organization. Unlike NIS, the NIS+ namespace is dynamic because updates can occur and be put into effect at any time by any authorized user.

NIS+ enables you to store information about machine addresses, security information, mail information, Ethernet interfaces, and network services in one central location. This configuration of network information is referred to as the NIS+ namespace.

The NIS+ namespace is hierarchical. The NIS+ namespace is similar in structure to the UNIX directory file system. The hierarchical structure allows an NIS+ namespace to be configured to conform to the logical hierarchy of an organization. The namespace's layout of information is unrelated to its physical arrangement. Thus, an NIS+ namespace can be divided into multiple domains that can be administered autonomously. Clients might have access to information in domains other than their own if the clients have the appropriate permissions.

NIS+ uses a client-server model to store and have access to the information contained in an NIS+ namespace. Each domain is supported by a set of servers. The principal server is called the primary server. The backup servers are called secondary servers. The network information is stored in 16 standard NIS+ tables in an internal NIS+ database. Both primary and secondary servers run NIS+ server software and both maintain copies of NIS+ tables. Changes made to the NIS+ data on the master server are incrementally propagated automatically to the secondary servers.

NIS+ includes a sophisticated security system to protect the structure of the namespace and its information. NIS+ uses authentication and authorization to verify whether a client's request for information should be fulfilled. Authentication determines whether the information requester is a valid user on the network. Authorization determines whether a particular user is allowed to have or modify the information requested. See System Administration Guide: Naming and Directory Services (NIS+) for a more detailed description of NIS+ security.

For information on making the transition from NIS+ to LDAP, see Chapter 16, Transitioning From NIS+ to LDAP.

Description of the LDAP Naming Services

The Solaris Operating System supports LDAP (Lightweight Directory Access Protocol) in conjunction with the Sun Java System Directory Server (formerly Sun ONE Directory Server), as well as other LDAP directory servers.

For information about LDAP naming services, see Chapter 8, Introduction to LDAP Naming Services (Overview/Reference) .

For information about transitioning from NIS to LDAP or NIS+ to LDAP, see Chapter 15, Transitioning From NIS to LDAP (Overview/Tasks) or Chapter 16, Transitioning From NIS+ to LDAP.

For information on single sign-on, as well as the setup and maintenance of Kerberos authentication services, see Part VI, Kerberos Service, in System Administration Guide: Security Services.

Naming Services: A Quick Comparison












Files/ resource records 

2 column maps 

Multi-columned tables 

Directories [varied] 




Root master/non-root master primary/secondary cache/stub 




None (root or nothing) 

Secure RPC (AUTH_DH) 


SSL, varied 











Chapter 2 The Name Service Switch (Overview)

This chapter describes the name service switch. You use the name service switch to coordinate usage of different naming services.

About the Name Service Switch

The name service switch is a file which is named, nsswitch.conf. The name service switch controls how a client machine or application obtains network information. The name service switch is used by client applications that call any of the getXbyY() interfaces such as the following.

Each machine has a switch file in its /etc directory. Each line of that file identifies a particular type of network information, such as host, password, and group, followed by one or more locations of that information.

A client can obtain naming information from one or more of the switch's sources. For example, an NIS client could obtain its hosts information from an NIS map and its password information from a local /etc file. In addition, the client could specify the conditions under which the switch must use each source. See Table 2–1.

The Solaris system automatically loads an nsswitch.conf file into every machine's /etc directory as part of the installation process. Four alternate (template) versions of the switch file are also loaded into /etc for LDAP, NIS, NIS+, or files. See The nsswitch.conf Template Files.

These four files are alternate default switch files. Each file is designed for a different primary naming service: /etc files, NIS, NIS+, or LDAP. When the Solaris software is first installed on a machine, the installer selects the machine's default naming service: NIS+, NIS, local files, or LDAP. During installation, the corresponding template file is copied to nsswitch.conf. For example, for a machine client using LDAP, the installation process copies nsswitch.ldap to nsswitch.conf. Unless you have an unusual namespace, the default template file as copied to nsswitch.conf should be sufficient for normal operation.

No default file is provided for DNS, but you can edit any of these files to use DNS. For more information see DNS and Internet Access.

If you later change a machine's primary naming service, you copy the appropriate alternate switch file to nsswitch.conf. See The nsswitch.conf Template Files. You can also change the sources of particular types of network information used by the client by editing the appropriate lines of the /etc/nsswitch.conf file. The syntax is described below, and additional instructions are provided in How to Modify the Name Service Switch.

Format of the nsswitch.conf File

The nsswitch.conf file is essentially a list of 16 types of information and the sources that getXXbyYY() routines search for that information. The 16 types of information, not necessarily in this order, are the following.

The following table provides a description of the kind of sources that can be listed in the switch file for the information types above.

Table 2–1 Switch File Information Sources

Information Sources 



A file stored in the client's /etc directory. For example, /etc/passwd


An NIS+ table. For example, the hosts table.


An NIS map. For example, the hosts map.


compat can be used for password and group information to support old-style + or - syntax in /etc/passwd, /etc/shadow, and /etc/group files.


Can be used to specify that host information be obtained from DNS. 


Can be used to specify entries be obtained from the LDAP directory. 

Search Criteria

Single Source. If an information type has only one source, such as nisplus a routine using the switch searches for the information in that source only. If the routine finds the information, the routine returns a success status message. If the routine does not find the information, the routine stops searching and returns a different status message. What the routine does with the status message varies from routine to routine.

Multiple Sources. If a table contains multiple sources for a given information type, the switch directs the routine to search in the first listed source. If the routine finds the information, the routine returns a success status message. If the routine does not find the information in the first source, the routine tries the next source. The routine searches all sources until the routine has found the information, or until the routine is halted by a return specification. If all of the listed sources are searched without finding the information, the routine stops searching and returns a non-success status message.

Switch Status Messages

If a routine finds the information, the routine returns a success status message. If the routine does not find the information, the routine returns one of three error status messages. Possible status messages are listed in the following table.

Table 2–2 Switch Search Status Messages

Status Message 

Meaning of Message 


The requested entry was found in the specified source. 


The source is either unresponsive or unavailable. In other words, neither the NIS+ table, the NIS map, nor the /etc file could be found or be accessed.


The source responded with “No such entry.” In other words, the table, map, or file was accessed but the needed information was not found. 


The source is busy. The source might respond next time. In other words, the table, map, or file was found, but could not respond to the query. 

Switch Action Options

You can instruct the switch to respond to status messages with either of the two actions shown in the following table.

Table 2–3 Responses to Switch Status Messages




Stop looking for the information. 


Try the next source. 

Default Search Criteria

The combination of nsswitch.conf file status message and action option determines what the routine does at each step. The combination of status and action make up the search criteria.

The switch's default search criteria are the same for every source. As described in terms of the status messages listed above, see the following.

You can change default search criteria by explicitly specifying some other criteria by using the STATUS=action syntax shown above. For example, the default action for a NOTFOUND condition is to continue the search to the next source. For example, to specify for networks, the search should stop in a NOTFOUND condition, edit the networks line of the switch file. The line would read as follows.

networks: nis [NOTFOUND=return] files

The networks: nis [NOTFOUND=return] files line specifies a nondefault criterion for the NOTFOUND status. Nondefault criteria are delimited by square brackets.

In this example, the search routine behaves as follows:

Note –

Lookups in the nsswitch.conf file are done in the order in which items are listed. However, password updates are done in reverse order, unless otherwise specified by using the passwd -r repository command. See The Switch File and Password Information for more information.

What if the Syntax is Wrong?

Client library routines contain compiled-in default entries that are used if an entry in the nsswitch.conf file is either missing or syntactically incorrect. These entries are the same as the switch file's defaults.

The name service switch assumes that the table and source names are spelled correctly. If you misspell a table or source name, the switch uses default values.

Auto_home and Auto_master

The switch search criteria for the auto_home and auto_master tables and maps is combined into one category, which is called automount.

Timezone and the Switch File

The timezone table does not use the switch, so the table is not included in the switch file's list.

Comments in nsswitch.conf Files

Any nsswitch.conf file line beginning with a comment character (#) is interpreted as a comment line. A comment line is ignored by routines that search the file.

Characters preceding a comment mark are interpreted by routines that search the nsswitch.conf file. Characters to the right of the comment mark are interpreted as comments and ignored.

Table 2–4 Switch File Comment Examples

Type of Line 


Comment line. 

# hosts: nisplus [NOTFOUND=return] files 

Interpreted line. 

hosts: nisplus [NOTFOUND=return] file 

Partially interpreted line. The files element is not interpreted.

hosts: nisplus [NOTFOUND=return] # files 

Keyserver and publickey Entry in the Switch File

Caution – Caution –

You must restart the keyserver after you make a change to nsswitch.conf.

The keyserver reads the publickey entry in the name service switch configuration file only when the keyserver is started. If you change the switch configuration file, the keyserver does not register the changes until the keyserver is restarted.

The nsswitch.conf Template Files

Four switch template files are provided with the Solaris system to accommodate different naming services. Each file provides a different default set of information sources.

The four template files are the following.

Copy the template file that most closely meets your requirements to the nsswitch.conf configuration file and then modify the file as needed.

For example, to use the LDAP template file, you would type the following command.

mymachine# cp /etc/nsswitch.ldap /etc/nsswitch.conf

The Default Switch Template Files

The following switch files are supplied with the Solaris product.

Example 2–1 NIS+ Switch File Template: nsswitch.nisplus

# /etc/nsswitch.nisplus:
# An example file that could be copied over to /etc/nsswitch.conf;
# it uses NIS+ (NIS Version 3) in conjunction with files.
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet"
# transports.
# the following two lines obviate the "+" entry in /etc/passwd 
# and /etc/group.
passwd: files nisplus
group: files nisplus
# consult /etc "files" only if nisplus is down. 
hosts: nisplus [NOTFOUND=return] files
# Uncomment the following line, and comment out the above, to use 
# both DNS and NIS+. You must also set up the /etc/resolv.conf 
# file for DNS name server lookup. See resolv.conf(4).
# hosts: nisplus dns [NOTFOUND=return] files
services: nisplus [NOTFOUND=return] files
networks: nisplus [NOTFOUND=return] files
protocols: nisplus [NOTFOUND=return] files
rpc: nisplus [NOTFOUND=return] files
ethers: nisplus [NOTFOUND=return] files
netmasks: nisplus [NOTFOUND=return] files	
bootparams: nisplus [NOTFOUND=return] files
publickey: nisplus
netgroup: nisplus
automount: files nisplus
aliases: files nisplus
sendmailvars: files nisplus

Note –

For the publickey entry, the nisplus value must be first in the list of values. For example, publickey: nisplus files is the correct entry for an nsswitch.conf file that multiple NIS+ domains consult.

Example 2–2 NIS Switch File Template

# /etc/nsswitch.nis:
# An example file that could be copied over to /etc/nsswitch.conf;
# it uses NIS (YP) in conjunction with files.
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet"
# transports.
# the following two lines obviate the "+" entry in /etc/passwd
# and /etc/group.
passwd: files nis
group: files nis
# consult /etc "files" only if nis is down. 
hosts: nis [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
protocols: nis [NOTFOUND=return] files
rpc: nis [NOTFOUND=return] files
ethers: nis [NOTFOUND=return] files
netmasks: nis [NOTFOUND=return] files	
bootparams: nis [NOTFOUND=return] files
publickey: nis [NOTFOUND=return] files
netgroup: nis
automount: files nis
aliases: files nis
# for efficient getservbyname() avoid nis
services: files nis
sendmailvars: files

Example 2–3 Files Switch File Template

# /etc/nsswitch.files:
# An example file that could be copied over to /etc/nsswitch.conf;
# it does not use any naming service.
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet"
# transports.
passwd: files
group: files
hosts: files
networks: files
protocols: files
rpc: files
ethers: files
netmasks: files	
bootparams: files
publickey: files
# At present there isn't a 'files' back end for netgroup;
# the system will figure it out pretty quickly, and will notuse
# netgroups at all.
netgroup: files
automount: files
aliases: files
services: files
sendmailvars: files

Example 2–4 LDAP Switch File Template

# /etc/nsswitch.ldap:
# An example file that could be copied over to /etc/nsswitch.conf; it
# uses LDAP in conjunction with files.
# "hosts:" and "services:" in this file are used only if the
# /etc/netconfig file has a "-" for nametoaddr_libs of "inet" transports.

# the following two lines obviate the "+" entry in /etc/passwd 
and /etc/group.
passwd:     files ldap
group:      files ldap

hosts:      ldap [NOTFOUND=return] files

networks:   ldap [NOTFOUND=return] files
protocols:  ldap [NOTFOUND=return] files
rpc:        ldap [NOTFOUND=return] files
ethers:     ldap [NOTFOUND=return] files
netmasks:   ldap [NOTFOUND=return] files
bootparams: ldap [NOTFOUND=return] files
publickey:  ldap [NOTFOUND=return] files

netgroup:   ldap

automount:  files ldap
aliases:    files ldap

# for efficient getservbyname() avoid ldap
services:   files ldap
sendmailvars:   files

The nsswitch.conf File

The default nsswitch.conf file that is installed with the Solaris software is determined by which naming service you select during the installation process. Each line identifies a particular type of network information, such as host, password, and group, along with the information source, such as NIS+ tables, NIS maps, the DNS hosts table, or local /etc. When you chose a naming service, the switch template file for that service is copied to create the new nsswitch.conf file. For example, if you choose NIS, the nsswitch.nis file is copied to create a new nsswitch.conf file.

An nsswitch.conf file is automatically loaded into every machine's /etc directory by the Solaris 9 release software, along with the following alternate (template) versions.

These alternate template files contain the default switch configurations used by the NIS+ and NIS services, local files, and LDAP. No default file is provided for DNS, but you can edit any of these files to use DNS. When the Solaris software is first installed on a machine, the installer selects the machine's default naming service. During installation, the corresponding template file is copied to /etc/nsswitch.conf. For example, for a machine client using NIS, the installation process copies nsswitch.nis to nsswitch.conf.

If your network is connected to the Internet and users must access Internet hosts using DNS, you must enable DNS forwarding.

Unless you have an unusual namespace, the default template file as copied to nsswitch.conf should be sufficient for normal operation.

Selecting a Different Configuration File

When you change a machine's naming service, you need to modify that machine's switch file accordingly. For example, if you change a machine's naming service from files to NIS, you need to install a switch file appropriate for NIS. You change switch files by copying the appropriate template file to nsswitch.conf.

If you are installing NIS+ on a machine using the NIS+ installation scripts, the NIS+ template script is copied to nsswitch.conf for you. In this case, you do not have to configure the switch file unless you want to customize.

Before proceeding to change switch files, make sure the sources listed in the file are properly set up. In other words, if you are going to select the NIS version, the client must eventually have access to NIS service. If you select the local files version, those files must be properly set up on the client.

ProcedureHow to Modify the Name Service Switch

To change to a switch file, follow these steps.

Note –

In order to use LDAP naming services, you must also properly configure all LDAP client machines, in addition to modifying the nsswitch.conf. See Chapter 12, Setting Up LDAP Clients (Tasks) for more information.

  1. Become superuser or assume an equivalent role.

    Roles contain authorizations and privileged commands. For more information about roles, see Chapter 9, Using Role-Based Access Control (Tasks), in System Administration Guide: Security Services.

  2. Copy the appropriate alternate file for the machine's naming service over the nsswitch.conf file.

    NIS+ Version (done automatically for you by NIS+ scripts)

    client1# cd /etc
    client1# cp nsswitch.nisplus nsswitch.conf

    NIS Version

    client1# cd /etc
    client1# cp nsswitch.nis nsswitch.conf

    Local /etc Files Version

    client1# cd /etc
    client1# cp nsswitch.files nsswitch.conf
  3. Reboot the machine.

    The nscd daemon caches switch information. See the nscd(1M) man page for information.

    Some library routines do not periodically check the nsswitch.conf file to see whether the file has been changed. You must reboot the machine to make sure that the daemon and those routines have the latest information in the file.

DNS and Internet Access

The nsswitch.conf file also controls DNS forwarding for clients as described in the following subsections. DNS forwarding grants Internet access to clients. For information on how to set DNS forwarding for NIS+ with NIS compatibility, see System Administration Guide: Naming and Directory Services (NIS+).

IPv6 and Solaris Naming Services

NIS, NIS+ and LDAP support storing IPv6 data, as well as using IPv6 transports for protocol traffic. Beginning with BIND version 8.3.3, DNS on the Solaris OS supports the use of IPv6 transports on the client side. As of BIND version 8.4.2, DNS provides a complete client-server solution over IPv6 networks on Solaris.

The nsswitch.conf file controls search criteria for IPv6 addresses. IPv6 increases the IP address size from 32 bits to 128 bits to support more levels of addressing hierarchy. A larger address size provides a greater number of addressable nodes. For more information about IPv6, its configuration and implementation, see System Administration Guide: IP Services.

Use the new ipnodes source for IPv6 addresses. The /etc/inet/ipnodes file stores both IPv4 and IPv6 addresses. The /etc/inet/ipnodes file uses the same format convention as the /etc/hosts file.

IPv6 aware naming services use the new ipnodes source for its search forwarding. For instance, if LDAP is aware of IPv6 addresses, specify the following.

ipnodes: ldap [NOTFOUND=return] files

Caution – Caution –

Potential delay issues:

Ensuring Compatibility With +/- Syntax

If +/- is used in /etc/passwd, /etc/shadow, and /etc/group files, you need to modify the nsswitch.conf file to insure compatibility.

The Switch File and Password Information

It is possible to include and access password information in multiple repositories, such as files and nisplus. You can use the nsswitch.conf file to establish the lookup order for that information.

Caution – Caution –

files must be the first source in the nsswitch.conf file for passwd information.

In an NIS+ environment, the passwd line of the nsswitch.conf file should list the repositories in the following order.

passwd: files nisplus

In an NIS environment, the passwd line of the nsswitch.conf file should list the repositories in the following order.

passwd: files nis

Tip –

Listing files first allows root to log in, under most circumstances, even when the system encounters some network or naming services issues.

Maintaining multiple repositories for the same user is not recommended. By maintaining centralized password management in a single repository for each user, you reduce the possibilities of confusion and error. If you choose to maintain multiple repositories per user, update password information by using the passwd -r command.

passwd -r repository

If no repository is specified with the -r option, passwd updates the repositories listed in nsswitch.conf in reverse order.