From owner-svn-doc-all@FreeBSD.ORG Tue Oct 15 22:03:05 2013 Return-Path: Delivered-To: svn-doc-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79B36CBB; Tue, 15 Oct 2013 22:03:05 +0000 (UTC) (envelope-from dru@FreeBSD.org) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 59CEF2BAD; Tue, 15 Oct 2013 22:03:05 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r9FM356g046648; Tue, 15 Oct 2013 22:03:05 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r9FM359V046645; Tue, 15 Oct 2013 22:03:05 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201310152203.r9FM359V046645@svn.freebsd.org> From: Dru Lavigne Date: Tue, 15 Oct 2013 22:03:05 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42970 - head/en_US.ISO8859-1/books/handbook/network-servers X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Oct 2013 22:03:05 -0000 Author: dru Date: Tue Oct 15 22:03:04 2013 New Revision: 42970 URL: http://svnweb.freebsd.org/changeset/doc/42970 Log: This patch provides general tightening and clarification of the sections NIS Slave Servers through NIS Security. Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Tue Oct 15 21:03:04 2013 (r42969) +++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Tue Oct 15 22:03:04 2013 (r42970) @@ -1517,14 +1517,16 @@ ellington has been setup as an YP master NIS slave server - Setting up an NIS slave server is - simpler than setting up the master. Log on to + To set up an NIS slave server, log on to the slave server and edit - /etc/rc.conf as before. This - time, include - when running - ypinit. This option - requires the name of the NIS master, as + /etc/rc.conf as for the master server. + Do not generate any NIS maps, as these + already exist on the master server. When running + ypinit on the slave server, use + (for slave) instead of + (for master). This option + requires the name of the NIS master in + addition to the domain name, as seen in this example: coltrane&prompt.root; ypinit -s ellington test-domain @@ -1584,56 +1586,51 @@ ypxfr: Exiting: Map successfully transfe coltrane has been setup as an YP slave server without any errors. Remember to update map ypservers on ellington. - There should be a directory called - /var/yp/test-domain. Copies of the - NIS master server's maps should be in - this directory. These files must always be up to date. - The following /etc/crontab entries on - the slave servers should do the job: + This will generate a directory on the slave server called + /var/yp/test-domain which contains copies of the + NIS master server's maps. + Adding these /etc/crontab entries on each + slave server will force the slaves to sync their maps with + the maps on the master server: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid - These two lines force the slave to sync its maps with - the maps on the master server. These entries are not + These entries are not mandatory because the master server automatically attempts - to push any map changes to its slaves; however, due to - the importance of correct password information on other - clients depending on the slave server, it is recommended - to specifically force the password map updates frequently. + to push any map changes to its slaves. However, since clients may + depend upon the slave server to provide correct password information, + it is recommended + to force frequent password map updates. This is especially important on busy networks where map updates might not always complete. - Now, run the command /etc/netstart - on the slave server as well, which again starts the NIS - server. + To finish the configuration, run /etc/netstart + on the slave server in order to start the NIS + services. - Setting Up a <acronym>NIS</acronym> Client + Setting Up an <acronym>NIS</acronym> Client - An NIS client establishes what is - called a binding to a particular NIS - server using the ypbind daemon. The - ypbind command checks the system's - default domain (as set by the - domainname command), and begins - broadcasting RPC requests on the local network. These - requests specify the name of the domain for which - ypbind is attempting to establish a - binding. If a server that has been configured to serve the - requested domain receives one of the broadcasts, it will - respond to ypbind, which will record the - server's address. If there are several servers available (a - master and several slaves, for example), - ypbind will use the address of the first - one to respond. From that point on, the client system will + An NIS client binds + to an NIS + server using &man.ypbind.8;. This + daemon + broadcasts RPC requests on the local network. These + requests specify the domain name configured on the client. + If an NIS server in the same domain + receives one of the broadcasts, it will + respond to ypbind, which will record the + server's address. If there are several servers available, + the client will use the address of the first + server to respond and will direct all of its NIS requests to that - server. ypbind will occasionally - ping the server to make sure it is still up - and running. If it fails to receive a reply to one of its - pings within a reasonable amount of time, - ypbind will mark the domain as unbound + server. The client will automatically + ping the server on a regular basis to make sure it is still + available. If it fails to receive a reply + within a reasonable amount of time, + ypbind will mark the domain as unbound and begin broadcasting again in the hopes of locating another server. @@ -1641,16 +1638,15 @@ Remember to update map ypservers on elli client configuration - Setting up a &os; machine to be a - NIS client is fairly - straightforward. + To configure a &os; machine to be an + NIS client: Edit /etc/rc.conf and add the following lines in order to set the NIS domain name and start - ypbind during network + &man.ypbind.8; during network startup: nisdomainname="test-domain" @@ -1659,40 +1655,34 @@ nis_client_enable="YES" To import all possible password entries from the - NIS server, remove all user - accounts from the - /etc/master.passwd file and use - vipw to add the following line to + NIS server, use + vipw to remove all user + accounts except one from + /etc/master.passwd. When removing + the accounts, keep in mind that at least one local account + should remain and this + account should be a member of + wheel. If there is a problem + with NIS, this local account can be used to log in + remotely, become the superuser, and fix + the problem. Before saving the edits, add the following line to the end of the file: +::::::::: - - This line will afford anyone with a valid + This line configures the client to provide anyone with a valid account in the NIS server's - password maps an account. There are many ways to - configure the NIS - client by changing this line. See the - netgroups - section below for more information. For - more detailed reading see O'Reilly's book on - Managing NFS and NIS. - - - - Keep in mind that at least one local account - (i.e. not imported via NIS) must exist in - /etc/master.passwd and this - account should also be a member of the group - wheel. If there is something - wrong with NIS, this account can be used to log in - remotely, become root, and fix - things. - + password maps an account on the client. There are many ways to + configure the NIS + client by modifying this line. One method is described in + . For + more detailed reading, refer to the book + Managing NFS and NIS, published by + O'Reilly Media. - To import all possible group entries from the NIS + To import all possible group entries from the NIS server, add this line to /etc/group: @@ -1707,32 +1697,27 @@ nis_client_enable="YES" &prompt.root; /etc/netstart &prompt.root; service ypbind start - After completing these steps, the command, - ypcat passwd, should show the - server's passwd map. + After completing these steps, running + ypcat passwd on the client should show the + server's passwd map. <acronym>NIS</acronym> Security - In general, any remote user may issue an RPC to - &man.ypserv.8; and retrieve the contents of the - NIS maps, provided the remote user knows - the domain name. To prevent such unauthorized transactions, + Since RPC is a broadcast-based service, + any system running ypbind within the same domain + can retrieve the contents of the + NIS maps. To prevent unauthorized transactions, &man.ypserv.8; supports a feature called securenets which can be used to restrict access - to a given set of hosts. At startup, &man.ypserv.8; will - attempt to load the securenets information from a file called - /var/yp/securenets. - - - This path varies depending on the path specified with - the option. This file contains entries - that consist of a network specification and a network mask - separated by white space. Lines starting with - # are considered to be comments. A sample - securenets file might look like this: - + to a given set of hosts. By default, this information is stored in + /var/yp/securenets, unless &man.ypserv.8; is started with + and an alternate path. This file contains entries + that consist of a network specification and a network mask + separated by white space. Lines starting with + # are considered to be comments. A sample + securenets might look like this: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 @@ -1748,89 +1733,64 @@ nis_client_enable="YES" matches one of these rules, it will process the request normally. If the address fails to match a rule, the request will be ignored and a warning message will be logged. If the - /var/yp/securenets file does not exist, + securenets does not exist, ypserv will allow connections from any host. - The ypserv program also has support for - Wietse Venema's TCP Wrapper - package. This allows the administrator to use the - TCP Wrapper configuration files for + is + an alternate mechanism for providing access control instead of - /var/yp/securenets. - - - While both of these access control mechanisms provide - some security, they, like the privileged port test, are + securenets. While either access control mechanism adds + some security, they are both vulnerable to IP spoofing attacks. All - NIS-related traffic should be blocked at the + NIS-related traffic should be blocked at the firewall. - Servers using /var/yp/securenets + Servers using securenets may fail to serve legitimate NIS clients with archaic TCP/IP implementations. Some of these implementations set all host bits to zero when doing - broadcasts and/or fail to observe the subnet mask when + broadcasts or fail to observe the subnet mask when calculating the broadcast address. While some of these problems can be fixed by changing the client configuration, - other problems may force the retirement of the client - systems in question or the abandonment of - /var/yp/securenets. - - Using /var/yp/securenets on a - server with such an archaic implementation of TCP/IP is a - really bad idea and will lead to loss of - NIS functionality for large parts of the - network. + other problems may force the retirement of these client + systems or the abandonment of + securenets. - TCP Wrappers + TCP Wrapper The use of TCP Wrapper increases the latency of the NIS server. The additional delay may be long enough to cause timeouts in - client programs, especially in busy networks or with slow - NIS servers. If one or more of the client systems suffers - from these symptoms, convert the client systems in question + client programs, especially in busy networks with slow + NIS servers. If one or more clients suffer + from latency, convert those clients into NIS slave servers and force them to bind to themselves. - - - - Barring Some Users from Logging On + + Barring Some Users - In our lab, there is a machine basie that - is supposed to be a faculty only workstation. We do not want - to take this machine out of the NIS domain, - yet the passwd file on the master + In this example, the basie system + is a faculty workstation within the NIS domain. + The passwd map on the master NIS server contains accounts for both - faculty and students. What can we - do? + faculty and students. This section demonstrates how to allow + faculty logins on this system while refusing student logins. - There is a way to bar specific users from logging on to a - machine, even if they are present in the - NIS database. To do this, add + To prevent specified users from logging on to a + system, even if they are present in the + NIS database, use vipw to add -username with - the correct number of colons like other entries to the end of - the /etc/master.passwd file on the client - machine, where username is the - username of the user to bar from logging in. The line with + the correct number of colons towards the end of + /etc/master.passwd on the client, + where username is the + username of a user to bar from logging in. The line with the blocked user must be before the + line - for allowing NIS users. This should - preferably be done using - vipw, since vipw will - sanity check the changes to - /etc/master.passwd, as well as - automatically rebuild the password database after editing. - For example, to bar user bill from + that allows NIS users. + In this example, bill is barred from logging on to basie: - basie&prompt.root; vipw -[add -bill::::::::: to the end, exit] -vipw: rebuilding the database... -vipw: done - -basie&prompt.root; cat /etc/master.passwd - + basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin @@ -1850,6 +1810,7 @@ nobody:*:65534:65534::0:0:Unprivileged u +::::::::: basie&prompt.root; +