Community hub
0 subscribers7 pages, 0 posts
Recent from talks
All channels
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Welcome to the community hub built to collect knowledge and have discussions related to Network Information Service.
Nothing was collected or created yet.
Network Information Service
View on Wikipediafrom Wikipedia
 | This article needs additional citations for verification. (January 2019) |
The Network Information Service, or NIS (originally called Yellow Pages or YP), is a client–server directory service protocol for distributing system configuration data such as user and host names between computers on a computer network. Sun Microsystems developed the NIS; the technology is licensed to virtually all other Unix vendors.
Because British Telecom PLC owned the name "Yellow Pages" as a registered trademark in the United Kingdom for its paper-based, commercial telephone directory, Sun changed the name of its system to NIS, though all the commands and functions still start with "yp".[1]
A NIS/YP system maintains and distributes a central directory of user and group information, hostnames, e-mail aliases and other text-based tables of information in a computer network. For example, in a common UNIX environment, the list of users for identification is placed in /etc/passwd and secret authentication hashes in /etc/shadow. NIS adds another "global" user list which is used for identifying users on any client of the NIS domain.
Administrators have the ability to configure NIS to serve password data to outside processes to authenticate users using various versions of the Unix crypt(3) hash algorithms. However, in such cases, any NIS(0307) client can retrieve the entire password database for offline inspection.
Successor technologies
[edit]The original NIS design was seen to have inherent limitations, especially in the areas of scalability and security, so other technologies have come to replace it.
Sun introduced NIS+ as part of Solaris 2 in 1992, with the intention for it to eventually supersede NIS. NIS+ features much stronger security and authentication features, as well as a hierarchical design intended to provide greater scalability and flexibility. However, it was also more cumbersome to set up and administer, and was more difficult to integrate into an existing NIS environment than many existing users wished. NIS+ was removed from Solaris 11.[2]
As a result, many users choose to remain with NIS, and over time other modern and secure distributed directory systems, most notably Lightweight Directory Access Protocol (LDAP), came to replace it. For example, slapd (the standalone LDAP daemon) generally runs as a non-root user, and SASL-based encryption of LDAP traffic is natively supported.
On large LANs, DNS servers may provide better nameserver functionality than NIS or LDAP can provide, leaving just site-wide identification information for NIS master and slave systems to serve. However, some functions—such as the distribution of netmask information to clients, as well as the maintenance of e-mail aliases—may still be performed by NIS or LDAP. NIS maintains an NFS database information file as well as so called maps.
See also
[edit]- Dynamic Host Configuration Protocol (DHCP)
- Hesiod (name service)
- Name Service Switch (NSS)
- Network information system, for a broader use of NIS to manage other system and networks
References
[edit]- ^ David N. Blank-Edelman (2009). Automating System Administration with Perl: Tools to Make You More Efficient. O'Reilly Media. p. 151. ISBN 9780596555634.
- ^ "End of Feature Notices for Oracle Solaris 11". Oracle Corporation. 2012-12-20.
External links
[edit]- Thorsten Kukuk (2003-07-01). "The Linux NIS(YP)/NYS/NIS+ HOWTO". Linux Documentation Project.
- Van Emery (2005-04-15). "Distributed Authentication System (DAS) Handbook". Archived from the original on 2006-07-15.
- Kristy Westphal (2001-01-22). "NFS and NIS Security". Symantec.
- "Red Hat Enterprise Linux 6: 2.2.3. Securing NIS". Red Hat.
- Frédéric Raynal (2001-06-29). "Yellow Pages, part 1". ibiblio.
- RHEL 9 will remove support for NIS Alexander Bokovoy, Sr. Principal Software Engineer slide show
| Hardware |
|  | ||||||
|---|---|---|---|---|---|---|---|---|
| Software | ||||||||
| Storage | ||||||||
| Performance | ||||||||
| Research | ||||||||
| Education | ||||||||
| Acquisitions | ||||||||
| Slogans | ||||||||
| Community |
| |||||||
Network Information Service
View on Grokipediafrom Grokipedia
The Network Information Service (NIS), formerly known as the Yellow Pages (YP), is a distributed naming service that centralizes the management and distribution of administrative data, such as user accounts, passwords, hostnames, IP addresses, and POSIX groups, across networks of Unix-like systems.[1][2] Developed by Sun Microsystems in the 1980s and integrated into systems like Solaris and various Linux distributions, NIS replaces localized files (such as those in directory on both master and slave servers, optimizing for fast lookups in a client-server model.[2][21]
Common map types include "byname" variants, which allow lookups by human-readable names (e.g., passwd.byname maps usernames to password entries), and "byaddr" variants for reverse lookups by numeric identifiers (e.g., hosts.byaddr maps IP addresses to hostnames).[2][21] Special maps address niche data, such as ethers.byaddr, which derives from /etc/ethers to map Ethernet (MAC) addresses to machine names, supporting network hardware identification.[21][22] Other examples encompass bootparams.byname for boot file paths and ypservers for listing domain servers.[2]
The master-slave architecture ensures map consistency and availability, with the master server maintaining authoritative copies updated directly from the ASCII source files.[2] After modifications to sources, the master rebuilds maps using the makedbm utility, a process automated by a Makefile in /var/yp that handles compilation for the entire domain.[2] Updated maps are then pushed to slave servers via the yppush command, while slaves can also pull changes periodically using ypxfr to maintain synchronization.[2][20] This replication mechanism supports redundancy and load distribution without requiring clients to rebind during updates.[19]
to pull initial maps.[27] Finally, start the services with commands like service ypserv start, service ypxfrd start (for map transfers to slaves), and service yppasswdd start, enabling them via chkconfig for boot persistence, while adjusting firewall rules to allow RPC ports such as 111, 834, and 835.[27]
On the client side, installation involves packages like ypbind, which handles binding to an NIS server.[28] Set the domain name using domainname or by editing /etc/defaultdomain, then configure binding in /etc/yp.conf with entries like domain mynisdom server nismaster to specify the server explicitly, avoiding broadcast discovery for reliability.[29] To enable NIS lookups, modify /etc/nsswitch.conf to include nis after files for relevant databases, such as passwd: files nis or group: files nis, which can be achieved by copying a template like cp /etc/nsswitch.nis /etc/nsswitch.conf or using tools like authconfig --enablenis.[28] Start the ypbind daemon with ypbind -broadcast for automatic server discovery or via service ypbind start, verifying binding with ypwhich to confirm the active server.[28]
Several command-line tools facilitate NIS management and querying. The ypcat command dumps the contents of an entire map, such as ypcat passwd to display all user entries, useful for verification.[30] ypmatch queries specific keys within a map, for example ypmatch username passwd to retrieve details for a user, supporting pattern matching for targeted lookups.[30] yppush propagates map updates from the master to slaves after changes, invoked automatically by make in /var/yp but runnable manually as yppush passwd to push the passwd map.[31] The rpc.yppasswdd daemon runs on the master server to handle remote password changes via yppasswd, updating the passwd map and pushing revisions while enforcing policies like minimum length.[32]
NIS integrates with the Name Service Switch (NSS) framework in glibc through the libnss_nis module, which implements the nis backend for ordered database lookups as defined in /etc/nsswitch.conf.[33] This module, formerly embedded in glibc and now standalone for IPv6 and TI-RPC support, allows applications to query local files first (e.g., /etc/passwd) before falling back to NIS maps, ensuring compatibility without replacing system files.[33] For instance, configuring passwd: compat files nis enables shadow password support alongside NIS, with libnss_nis handling the RPC calls to the bound server.[34]
/etc) with a uniform set of databases called maps, enabling consistent access to shared information without manual synchronization on each machine.[2][3]
NIS functions through a client-server architecture, where master servers maintain authoritative copies of maps—two-column tables in ndbm format storing key-value pairs (e.g., passwd.byname for username-to-password mappings)—and propagate updates to slave servers for redundancy and load balancing.[2] Clients bind to available servers using the ypbind daemon, either via broadcast discovery or a predefined server list, and query the RPC-based ypserv daemon on servers to retrieve data, often in conjunction with portmap for service location.[2][3] Key maps include standard ones like hosts.byaddr for IP-to-hostname resolution and bootparams for diskless client booting, supporting a flat namespace without hierarchical structure, though it can integrate with DNS for broader Internet connectivity.[2]
While effective for small to medium-sized networks, NIS has notable limitations, particularly in security: it transmits data, including password hashes, unencrypted over the network and lacks host authentication, making it vulnerable to eavesdropping and spoofing attacks.[1][3] Mitigation options include restricting access via the /var/yp/securenets file to trusted IP addresses and using firewalls, but modern deployments often favor more secure alternatives like LDAP (per RFC 2307) or SSSD for identity management.[2][1] Despite its legacy status, NIS remains in use for compatibility in certain Unix environments, with tools like ypset for manual server selection (though discouraged due to risks) and rpc.yppasswdd for remote password updates.[3]
Overview
Definition
The Network Information Service (NIS) is a client-server directory service protocol designed for distributing system configuration data, such as user accounts, group memberships, hostnames, and email aliases, across networks of Unix-like operating systems.[4] Originally known as Yellow Pages (YP), it was renamed NIS in the early 1990s following a trademark dispute with British Telecom, which held rights to the "Yellow Pages" name in the United Kingdom. Developed by Sun Microsystems in the 1980s, NIS was licensed to virtually all major Unix vendors, establishing it as a de facto standard for centralized administration in networked Unix environments during that era and into the 1990s.[4][5] At its core, NIS operates through a centralized server that maintains databases of shared information, which clients query remotely to retrieve data traditionally stored in local files, such as /etc/passwd for user accounts or /etc/hosts for hostnames, thereby enabling consistent configuration across multiple systems without manual synchronization.[6][7]Purpose and Use Cases
The Network Information Service (NIS) primarily enables centralized management of user authentication, hostname resolution, and other configuration data across multi-machine environments, thereby avoiding duplication and inconsistency in administrative files.[2] By distributing databases known as maps from a master server to slave servers, NIS ensures that updates to information such as user credentials and host addresses are propagated uniformly throughout the network.[8] This centralized approach simplifies administration in homogeneous Unix networks, where maintaining synchronized local files like/etc/passwd and /etc/hosts on each machine would otherwise be labor-intensive.[9]
In practice, NIS facilitates seamless user login across networked systems by sharing user accounts, making it particularly useful in environments like university computer labs or enterprise Unix clusters.[10] For instance, in a lab setup with multiple client machines, administrators can add or modify user accounts on a single master server, with changes automatically distributed to all clients for consistent authentication.[10] Similarly, NIS distributes host and network information to support services such as Network File System (NFS) mounting, allowing clients to resolve hostnames and IP addresses from a shared database without local modifications.[2]
NIS integrates with Unix authentication mechanisms by augmenting local files, enabling standard library calls like getpwent() to retrieve remote data from NIS maps such as passwd.byname.[8] In the pre-LDAP era, this provided significant benefits for Unix networks by reducing the need for manual file synchronization and enabling scalable administration of growing clusters, though it has since been largely supplanted by more secure alternatives.[9]
History
Development by Sun Microsystems
The Network Information Service (NIS), originally known as Yellow Pages (YP), was developed by Sun Microsystems in the mid-1980s as a key component of their Unix-based workstation ecosystem to enable networked computing environments.[11] This development occurred amid the rapid expansion of local area networks in academic and research settings, where Sun's workstations were increasingly deployed.[12] The service was introduced in SunOS 2.0, released in May 1985, marking a foundational advancement in distributed system management.[13] The primary motivation for creating NIS stemmed from the need to address administrative challenges in sharing configuration data—such as user accounts, hostnames, and network services—across expanding SunOS-based networks.[5] Prior to NIS, maintaining consistent system information required manual synchronization on each machine, which became inefficient as network sizes grew beyond a handful of nodes.[14] Building on Sun's earlier innovations like Remote Procedure Call (RPC) technology, introduced in 1984, NIS leveraged a client-server model to centralize authentication and authorization, promoting interoperability in heterogeneous Unix environments.[11] The initial implementation was led by Sun's engineering team, who designed NIS to integrate seamlessly with the emerging client-server paradigms that defined Sun's computing vision.[12] Upon release, NIS commands retained the "yp" prefix to honor its Yellow Pages origins, reflecting the analogy to a centralized directory for quick lookups.[5] This naming persisted even after a later rebranding due to trademark issues, underscoring the service's roots in Sun's networked Unix architecture.[14]Name Change and Adoption
In the late 1980s, Sun Microsystems renamed its Yellow Pages (YP) directory service to Network Information Service (NIS) following a legal dispute over the "Yellow Pages" trademark held by British Telecom in the United Kingdom.[15] Despite the rebranding, the underlying functionality remained unchanged, and legacy elements such as command-line binaries and manual pages retained the "yp" prefix to maintain compatibility.[15] This name change was necessary to avoid infringement, as "Yellow Pages" was a registered trademark for British Telecom's telephone directory services, prompting Sun to adopt a neutral, descriptive term for global distribution.[16] Sun Microsystems further promoted NIS adoption by open-sourcing the software and licensing it freely to other vendors, which facilitated its integration into various Unix-like systems starting in the late 1980s.[17] A key enabler was the publication of the Yellow Pages Protocol Specification in 1986, which detailed the YP/NIS protocol built on Sun's Remote Procedure Call (RPC) framework and allowed porting to non-Sun platforms.[18] This specification enabled implementations in Berkeley Software Distribution (BSD) variants, early Linux distributions, and commercial Unix systems, standardizing centralized management of user accounts, hostnames, and other configuration data across heterogeneous networks.[17] By the 1990s, NIS had achieved peak adoption as the primary directory service in enterprise and academic environments, becoming a standard feature in major Unix operating systems including Sun's Solaris, IBM's AIX, Hewlett-Packard's HP-UX, and BSD derivatives like FreeBSD.[12] Its widespread inclusion—supported in virtually all Linux distributions and Unix variants of the era—streamlined administration in large-scale networks, though it was eventually supplemented by more secure alternatives.[12]Architecture
Client-Server Model
The Network Information Service (NIS) employs a client-server architecture to distribute administrative data across a network, where servers maintain centralized databases and clients query them for information such as user accounts and host configurations.[8] In this model, servers act as authoritative sources, while clients rely on binding mechanisms to access the data dynamically.[5] The design emphasizes simplicity and reliability for local area networks, using Remote Procedure Call (RPC) for communication, though the protocol details are handled transparently.[12] NIS servers run the ypserv daemon, which manages and serves the databases known as maps to client requests.[2] Each NIS domain designates one master server responsible for updating and propagating the maps, ensuring consistency across the network.[8] To enhance redundancy, slave servers replicate the full set of maps from the master via automated push mechanisms, allowing them to handle client queries independently and distribute load during high demand.[2] Both master and slave servers also function as clients to bind to themselves for internal queries.[12] On the client side, the ypbind daemon establishes and maintains a binding to an available NIS server within the client's domain, enabling seamless data retrieval.[2] Clients use utility commands such as ypcat for retrieving entire maps or ypmatch for querying specific keys, which interact with ypbind to forward requests to the bound server.[5] If the bound server becomes unresponsive, ypbind rebinds by broadcasting RPC requests or consulting a server list, ensuring continuous availability.[8] The communication flow begins with a client initiating a request through ypbind, which identifies a server and routes the query specifying the domain and desired map or key.[12] The ypserv process on the server processes the request by accessing the corresponding flat-file database and returns the relevant data—such as key-value pairs—directly to the client via RPC.[5] This stateless interaction supports efficient, on-demand access without persistent connections.[2] NIS's client-server model is optimized for small to medium-sized networks, typically supporting up to a few hundred hosts through master-slave replication for fault tolerance.[8] Beyond basic replication, it lacks built-in hierarchical structures or advanced load balancing, limiting scalability in larger environments where a single point of failure at the master could propagate delays.[2]Domains and Maps
In the Network Information Service (NIS), domains serve as logical groupings of machines to scope and isolate name service information across administrative boundaries.[19] An NIS domain consists of a collection of systems that share a common set of maps, identified by a unique domain name such as "acme-art" or "test-domain," which is unrelated to DNS domains.[2][20] This structure enables centralized management of configuration data while preventing overlap between different groups of hosts.[19] Clients bind to a single domain at boot time, with the domain name specified in the /etc/defaultdomain file to determine the scope of queries.[2] NIS maps form the fundamental data structures, functioning as two-column key-value databases that store system configuration information in a distributed manner.[2] These maps are compiled on the server from flat ASCII source files, such as /etc/passwd for user accounts or /etc/hosts for host addresses, replacing direct reliance on local /etc files for networked environments.[2][20] The resulting databases are stored in ndbm (New DBM) format as .dbm files within the /var/yp/Protocols and Implementation
RPC Integration
The Network Information Service (NIS), originally known as Yellow Pages (YP), relies on Sun's Open Network Computing (ONC) Remote Procedure Call (RPC) protocol for client-server communication, enabling distributed queries across networked systems.[23] NIS procedures are defined under RPC program number 100004, supporting versions 1 (YPVERS_ORIG) and 2 (YPVERS), which allow compatibility between different implementations while maintaining core functionality for map lookups and domain management.[24] This integration leverages ONC RPC's external data representation (XDR) for encoding requests and responses, ensuring portability across heterogeneous Unix-like environments.[23] Service discovery in NIS begins with the portmapper daemon, which operates on TCP and UDP port 111 to map RPC program numbers to dynamic or fixed server ports, a mechanism fundamental to ONC RPC operations.[23] The ypserv daemon, responsible for handling NIS queries, typically binds to dynamic ports but is often configured to a fixed port such as UDP/TCP 834 to facilitate firewall rules and consistent access.[25] These ports enable clients to locate and invoke NIS services after initial portmapper consultation, supporting both broadcast and directed RPC calls. Core NIS procedures over RPC include YPPROC_DOMAIN (procedure 1), which checks if a server handles a specific domain and returns a boolean indicating non-membership if unsupported; YPPROC_MATCH (procedure 3), used for retrieving a value associated with a given key in a map; YPPROC_FIRST (procedure 4), which initiates iteration by returning the first key-value pair in a map; and YPPROC_NEXT (procedure 5), which retrieves subsequent pairs during traversal.[24] These procedures facilitate stateless request-response interactions, primarily over UDP for efficiency, with fallback to TCP for larger transfers or reliability needs, as per ONC RPC specifications.[23] The protocol details for YP version 1 are outlined in Sun Microsystems' YP Protocol Specification, with RPC foundations in the ONC RPC version 2 document.[26]Configuration and Tools
Configuring an NIS server on Unix-like systems typically begins with installing the necessary packages, such as ypserv, which provides the core daemon for serving NIS maps.[27] Administrators then define the NIS domain by setting the NISDOMAIN variable in /etc/sysconfig/network (e.g., NISDOMAIN=mynisdom) and configure access controls in files like /etc/ypserv.conf for allowed hosts and /var/yp/securenets for network permissions (e.g., 255.255.255.0 192.168.1.0 to permit a subnet).[27] To specify the maps to build, such as passwd, group, and hosts, edit /var/yp/Makefile under the all: target (e.g., all: passwd group hosts auto.master), optionally setting flags like MERGE_PASSWD=false for custom integrations.[27] The ypinit utility is then executed as the master server with /usr/lib64/yp/ypinit -m, prompting for slave server hostnames to initialize the domain subdirectory in /var/yp, build the maps, and configure replication; for slave servers, use ypinit -sSecurity
Vulnerabilities
The Network Information Service (NIS) suffers from several fundamental security flaws stemming from its design, which prioritizes convenience over protection in distributed Unix environments. These vulnerabilities expose sensitive data and enable unauthorized access, making NIS unsuitable for untrusted networks.[35] A primary weakness is the exposure of password information, as NIS clients can retrieve the entire passwd map, including encrypted passwords hashed with weak algorithms like DES via the crypt(3) function. For instance, commands such asypcat passwd.byname allow any authorized client to dump the full list of usernames and hashed passwords to a file, facilitating offline cracking attacks using tools like Crack, especially since NIS often merges /etc/passwd and /etc/shadow without robust shadow support across platforms. This unencrypted transmission of hashes over the network further amplifies the risk, as intercepted data can be subjected to dictionary or brute-force attacks.[35][36][37]
NIS relies on Remote Procedure Call (RPC) protocols that lack built-in authentication mechanisms, permitting unauthenticated queries and responses. Clients verify servers only by domain name, without cryptographic validation, allowing attackers on the network to spoof NIS servers and impersonate legitimate ones via man-in-the-middle (MITM) attacks. This enables the injection of falsified maps, such as altered passwd entries granting unauthorized privileges, and exposes the system to denial-of-service (DoS) disruptions by overwhelming RPC ports.[38][35][37]
Early NIS implementations used network broadcasts for server discovery, inadvertently revealing domain names and server details to passive listeners using sniffers like tcpdump or snoop. Even in unicast configurations, the plaintext RPC traffic remains interceptable in shared or untrusted segments, compounding risks in environments without segment isolation.[35]
Historical exploits have demonstrated these flaws in practice, including tools like ypx for remotely extracting and cracking password maps, and custom programs such as ypfake to spoof UDP-based NIS responses and insert malicious user entries before legitimate replies arrive. Buffer overflows in related RPC services have also been targeted, though vendor patches addressed some instances; overall, these issues have rendered NIS insecure for internet-facing deployments, with successors like NIS+ introducing authentication to mitigate core problems.[38][36][35]