Name Service Switch

Overview [1]#

The name service switch is a configurable selection service that enables an administrator to specify which name information service or source to use for each type of network information. The Name Service Switch Types or services are called a database. The Name Service Switch is used by client applications that call any of the getXbyY interfaces, such as the following:
  • gethostbyname()
  • getpwuid()
  • getpwnam()
  • getaddrinfo()

Our interest in Name Service Switch is for the setup of LDAP for Linux and Unix Clients.

Each system has its own configuration in an SMF repository. Each property (Name Service Switch Types) defined in the name service switch identifies a particular database, such as a host, password, or group. The value assigned to each property lists one or more Name Service Switch Sources from which to request the information.

Sometimes, these values include guidance or options. The guidance might include how many retries to a service should be attempted, what timeout to apply, or what to do if the service fails.

Each machine, typically, has a Nsswitch.conf 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.

Name Service Switch Types#

There are 16 types (aka databases) of information used by Name Service Switch.

Name Service Switch Sources#

There are several Name Service Switch Sources that can be listed in the switch file for the Name Service Switch Types.

Name Service Switch Status Messages#

Each Name Service Switch service will return a Name Service Switch Status Messages.

Name Service Switch Action Options#

You can instruct the switch to respond to Name Service Switch Status Messages with Name Service Switch Action Options

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

Default Search Criteria#

The combination of nsswitch.conf Name Service Switch Status Messages and Name Service Switch Action Options determines what the routine does at each step. The combination of Name Service Switch Status Messages and Name Service Switch Action Options make up the search criteria.

The switch's default search criteria are the same for every source. As described in terms of the Name Service Switch Status Messages:

  • SUCCESS=return. Stop looking for the information. Proceed using the information that has been found.
  • UNAVAIL=continue. Go to the next nsswitch.conf file source and continue searching. If this source is the last or only source, return with a NOTFOUND status.
  • NOTFOUND=continue. Go to the next nsswitch.conf file source and continue searching. If this source is the last or only source, return with a NOTFOUND status.
  • TRYAGAIN=continue. Go to the next nsswitch.conf file source and continue searching. If this source is the last or only source, return with a NOTFOUND status.

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:

  • If the networks map is available, and contains the needed information, the routine returns with a SUCCESS status message.
  • If the networks map is not available, the routine returns with an UNAVAIL status message. By default, the routine continues to search the appropriate /etc file.
  • If the networks map is available and found, but the map does not contain the needed information, the routine returns with a NOTFOUND message. But, instead of continuing on to search the appropriate /etc file, which would be the default behavior, the routine stops searching.
  • If the networks map is busy, the routine returns with an TRYAGAIN status message and by default continues on to search the appropriate /etc file.

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 Example
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.

LDAP Naming Services#

When Sun introduced LDAP support for naming services through nsswitch.conf. "Native LDAP" as it is commonly called, is the replacement for NIS. A typical implementation would be most likely a transition from NIS to LDAP.

Because of their familiarity with NIS, many current customers continue to use compatibility in the nsswitch.conf, particular when using netgroups for access control.

The "compat" mode was never designed or intended for use with LDAP. As with any legacy support, the function for "compat" was for interoperability and not for performance. Since "compat" is a restriction/limitation placed on NSS, one could expect that services and application normally optimized for NSS would be impacted.

Access Control in LDAP Naming Services#

As discussions regading access control are developed when developing an Architecture for Native LDAP, many of the following concepts are explored: Search Filters in Service Search Descriptors or SSD(s).

Since client searches should be optimized in an LDAP-based environment, native LDAP clients use Service Search Descriptors in order to facilitate retrieving data from a Directory.



In this example, each posixaccount has two multivalued attrbutes:
  • hostsdeniedlogin – a listing of hosts that are denied during authentication attempts
  • hostsallowedlogin – a listing of hosts that are allowed during authentication attempts.

The String value explained:

  • The string passwd:ou=people,dc=yaddda,dc=yadda?one? Specificies the dn base and search scope;
  • The notation &(....) adds a conditional “and”
  • The string !(hostsdeniedlogin=anadbprod1) is a filter that excludes the denied host: as long as the posixaccount's hostsdeniedlogin does not contain anadbprod1, continue; otherwise search/read access to the subtree is denied;
  • The notation (|.....) adds a conditional “or”
  • The string (!(hostsallowedlogin=*))(hostsallowedlogin=anadbprod1) prevents global access from (hostsallowedlogin=*), but allows access based on the value anadbprod1 for the hostsallowedlogin attribute of the posixaccount attempting authentication.

Each ldapclient would be different for each client system to generate host level restriction. This SSD could be adjusted and created on group-based attributes for group-level SSDs.


"Authorization" can be defined as the right to attempt authentication, whereas authentication represents the actual process.

For example, Secure Shell clients can be configured for group-based authorization by populating/migrating groups in the Directory, and enforcing AllowGroups in the sshd2.config. When an Secure Shell session is invoked, the client will conduct a basic anonymous read of the groups stored in the Directory, and will allow a login attempt only if the user is a member of one of the allowed groups.

This process provides both host and user-based restrictions, and could be configured for each client system.

Pluggable Authentication Modules#

Pluggable Authentication Modules, aka PAM, was designed to be a configurable service, in where customers could write C-based functions for authentication based on specific services. In fact, several third party software vendors provide PAM libraries and modules for the pam.conf.

The Sun Blueprint LDAP in the Solaris Operating Environment contains a chapter titled "Writing a PAM Service Module."

Implementing custom PAM Service Modules is allowed in Native LDAP.


More Information#

There might be more information for this subject on one of the following: