network-nis.html

FreeBSD安装说明概述 FreeBSD 提供了一个以文字为主

<p><b>Note:</b> This path varies depending on the path specified with the <var
class="OPTION">-p</var> 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:</p>
</blockquote>
</div>

<pre class="PROGRAMLISTING">
# allow connections from local host -- mandatory
127.0.0.1     255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
# this includes the machines in the testlab
10.0.0.0      255.255.240.0
</pre>

<p>If <span class="CITEREFENTRY"><span class="REFENTRYTITLE">ypserv</span>(8)</span>
receives a request from an address that 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 <tt class="FILENAME">/var/yp/securenets</tt> file
does not exist, <tt class="COMMAND">ypserv</tt> will allow connections from any host.</p>

<p>The <tt class="COMMAND">ypserv</tt> program also has support for Wietse Venema's <b
class="APPLICATION">tcpwrapper</b> package. This allows the administrator to use the <b
class="APPLICATION">tcpwrapper</b> configuration files for access control instead of <tt
class="FILENAME">/var/yp/securenets</tt>.</p>

<div class="NOTE">
<blockquote class="NOTE">
<p><b>Note:</b> While both of these access control mechanisms provide some security,
they, like the privileged port test, are vulnerable to ``IP spoofing'' attacks. All
NIS-related traffic should be blocked at your firewall.</p>

<p>Servers using <tt class="FILENAME">/var/yp/securenets</tt> 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 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 <tt
class="FILENAME">/var/yp/securenets</tt>.</p>

<p>Using <tt class="FILENAME">/var/yp/securenets</tt> 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 your network.</p>

<p>The use of the <b class="APPLICATION">tcpwrapper</b> package increases the latency of
your 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 your
client systems suffers from these symptoms, you should convert the client systems in
question into NIS slave servers and force them to bind to themselves.</p>
</blockquote>
</div>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN27269" name="AEN27269">19.9.6. Barring Some Users from
Logging On</a></h2>

<p>In our lab, there is a machine <tt class="HOSTID">basie</tt> that is supposed to be a
faculty only workstation. We do not want to take this machine out of the NIS domain, yet
the <tt class="FILENAME">passwd</tt> file on the master NIS server contains accounts for
both faculty and students. What can we do?</p>

<p>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, all you must do is add <span class="emphasis"><i
class="EMPHASIS">-<var class="REPLACEABLE">username</var></i></span> to the end of the
<tt class="FILENAME">/etc/master.passwd</tt> file on the client machine, where <var
class="REPLACEABLE">username</var> is the username of the user you wish to bar from
logging in. This should preferably be done using <tt class="COMMAND">vipw</tt>, since <tt
class="COMMAND">vipw</tt> will sanity check your changes to <tt
class="FILENAME">/etc/master.passwd</tt>, as well as automatically rebuild the password
database when you finish editing. For example, if we wanted to bar user <span
class="emphasis"><i class="EMPHASIS">bill</i></span> from logging on to <tt
class="HOSTID">basie</tt> we would:</p>

<pre class="SCREEN">
basie<samp class="PROMPT">#</samp> <kbd class="USERINPUT">vipw</kbd>
<kbd class="USERINPUT">[add -bill to the end, exit]</kbd>
vipw: rebuilding the database...
vipw: done

basie<samp class="PROMPT">#</samp> <kbd class="USERINPUT">cat /etc/master.passwd</kbd>

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
operator:*:2:5::0:0:System &#38;:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+:::::::::
-bill

basie<samp class="PROMPT">#</samp>
</pre>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="NETWORK-NETGROUPS" name="NETWORK-NETGROUPS">19.9.7. Using
Netgroups</a></h2>

<i class="AUTHORGROUP"><span class="CONTRIB">Contributed by</span> Udo Erdelhoff.</i> 

<p>The method shown in the previous section works reasonably well if you need special
rules for a very small number of users and/or machines. On larger networks, you <span
class="emphasis"><i class="EMPHASIS">will</i></span> forget to bar some users from
logging onto sensitive machines, or you may even have to modify each machine separately,
thus losing the main benefit of NIS, <span class="emphasis"><i
class="EMPHASIS">centralized</i></span> administration.</p>

<p>The NIS developers' solution for this problem is called <span class="emphasis"><i
class="EMPHASIS">netgroups</i></span>. Their purpose and semantics can be compared to the
normal groups used by <span class="TRADEMARK">UNIX</span> file systems. The main
differences are the lack of a numeric id and the ability to define a netgroup by
including both user accounts and other netgroups.</p>

<p>Netgroups were developed to handle large, complex networks with hundreds of users and
machines. On one hand, this is a Good Thing if you are forced to deal with such a
situation. On the other hand, this complexity makes it almost impossible to explain
netgroups with really simple examples. The example used in the remainder of this section
demonstrates this problem.</p>

<p>Let us assume that your successful introduction of NIS in your laboratory caught your
superiors' interest. Your next job is to extend your NIS domain to cover some of the
other machines on campus. The two tables contain the names of the new users and new
machines as well as brief descriptions of them.</p>

<div class="INFORMALTABLE"><a id="AEN27309" name="AEN27309"></a>
<table border="1" class="CALSTABLE">
<col />
<col />
<thead>
<tr>
<th>User Name(s)</th>
<th>Description</th>
</tr>
</thead>

<tbody>
<tr>
<td>alpha, beta</td>
<td>Normal employees of the IT department</td>
</tr>

<tr>
<td>charlie, delta</td>
<td>The new apprentices of the IT department</td>
</tr>

<tr>
<td>echo, foxtrott, golf, ...</td>
<td>Ordinary employees</td>
</tr>

<tr>
<td>able, baker, ...</td>
<td>The current interns</td>
</tr>
</tbody>
</table>
</div>

<div class="INFORMALTABLE"><a id="AEN27328" name="AEN27328"></a>
<table border="1" class="CALSTABLE">
<col />
<col />
<thead>
<tr>
<th>Machine Name(s)</th>
<th>Description</th>
</tr>
</thead>

<tbody>
<tr>
<td>war, death, famine, pollution</td>
<td>Your most important servers. Only the IT employees are allowed to log onto these
machines.</td>
</tr>

<tr>
<td>pride, greed, envy, wrath, lust, sloth</td>
<td>Less important servers. All members of the IT department are allowed to login onto
these machines.</td>
</tr>

<tr>
<td>one, two, three, four, ...</td>
<td>Ordinary workstations. Only the <span class="emphasis"><i
class="EMPHASIS">real</i></span> employees are allowed to use these machines.</td>
</tr>

<tr>
<td>trashcan</td>
<td>A very old machine without any critical data. Even the intern is allowed to use this
box.</td>
</tr>
</tbody>
</table>
</div>

<p>If you tried to implement these restrictions by separately blocking each user, you
would have to add one -<var class="REPLACEABLE">user</var> line to each system's <tt
class="FILENAME">passwd</tt> for each user who is not allowed to login onto that system.
If you forget just one entry, you could be in trouble. It may be feasible to do this
correctly during the initial setup, however you <span class="emphasis"><i
class="EMPHASIS">will</i></span> eventually forget to add the lines for new users during
day-to-day operations. After all, Murphy was an optimist.</p>

<p>Handling this situation with netgroups offers several advantages. Each user need not
be handled separately; you assign a user to one or more netgroups and allow or forbid
logins for all members of the netgroup. If you add a new machine, you will only have to
define login restrictions for netgroups. If a new user is added, you will only have to
add the user to one or more netgroups. Those changes are independent of each other; no
more ``for each combination of user and machine do...'' If your NIS setup is planned
carefully, you will only have to modify exactly one central configuration file to grant
or deny access to machines.</p>

<p>The first step is the initialization of the NIS map netgroup. FreeBSD's <span
class="CITEREFENTRY"><span class="REFENTRYTITLE">ypinit</span>(8)</span> does not create
this map by default, but its NIS implementation will support it once it has been created.
To create an empty map, simply type</p>

<pre class="SCREEN">
ellington<samp class="PROMPT">#</samp> <kbd class="USERINPUT">vi /var/yp/netgroup</kbd>
</pre>

<p>and start adding content. For our example, we need at least four netgroups: IT
employees, IT apprentices, normal employees and interns.</p>

<pre class="PROGRAMLISTING">
IT_EMP  (,alpha,test-domain)    (,beta,test-domain)
IT_APP  (,charlie,test-domain)  (,delta,test-domain)
USERS   (,echo,test-domain)     (,foxtrott,test-domain) \
        (,golf,test-domain)
INTERNS (,able,test-domain)     (,baker,test-domain)
</pre>

<p><var class="LITERAL">IT_EMP</var>, <var class="LITERAL">IT_APP</var> etc. are the
names of the netgroups. Each bracketed group adds one or more user accounts to it. The
three fields inside a group are:</p>

<ol type="1">
<li>
<p>The name of the host(s) where the following items are valid. If you do not specify a
hostname, the entry is valid on all hosts. If you do specify a hostname, you will enter a
realm of darkness, horror and utter confusion.</p>
</li>

<li>
<p>The name of the account that belongs to this netgroup.</p>
</li>

<li>
<p>The NIS domain for the account. You can import accounts from other NIS domains into
your netgroup if you are one of the unlucky fellows with more than one NIS domain.</p>
</li>
</ol>

<p>Each of these fields can contain wildcards. See <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">netgroup</span>(5)</span> for details.</p>

<div class="NOTE">
<blockquote class="NOTE">
<p><b>Note:</b> Netgroup names longer than 8 characters should not be used, especially if
you have machines running other operating systems within your NIS domain. The names are
case sensitive; using capital letters for your netgroup names is an easy way to
distinguish between user, machine and netgroup names.</p>

<p>Some NIS clients (other than FreeBSD) cannot handle netgroups with a large number of
entries. For example, some older versions of <span class="TRADEMARK">SunOS</span> start
to cause trouble if a netgroup contains more than 15 <span class="emphasis"><i
class="EMPHASIS">entries</i></span>. You can circumvent this limit by creating several
sub-netgroups with 15 users or less and a real netgroup that consists of the
sub-netgroups:</p>

<pre class="PROGRAMLISTING">
BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]
BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]
BIGGRP3  (,joe31,domain)  (,joe32,domain)
BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3
</pre>

<p>You can repeat this process if you need more than 225 users within a single
netgroup.</p>
</blockquote>
</div>

<p>Activating and distributing your new NIS map is easy:</p>

<pre class="SCREEN">
ellington<samp class="PROMPT">#</samp> <kbd class="USERINPUT">cd /var/yp</kbd>
ellington<samp class="PROMPT">#</samp> <kbd class="USERINPUT">make</kbd>
</pre>

<p>This will generate the three NIS maps <tt class="FILENAME">netgroup</tt>, <tt
class="FILENAME">netgroup.byhost</tt> and <tt class="FILENAME">netgroup.byuser</tt>. Use
<span class="CITEREFENTRY"><span class="REFENTRYTITLE">ypcat</span>(1)</span> to check if
your new NIS maps are available:</p>

<pre class="SCREEN">
ellington<samp class="PROMPT">%</samp> <kbd class="USERINPUT">ypcat -k netgroup</kbd>
ellington<samp class="PROMPT">%</samp> <kbd
class="USERINPUT">ypcat -k netgroup.byhost</kbd>
ellington<samp class="PROMPT">%</samp> <kbd
class="USERINPUT">ypcat -k netgroup.byuser</kbd>
</pre>

<p>The output of the first command should resemble the contents of <tt
class="FILENAME">/var/yp/netgroup</tt>. The second command will not produce output if you
have not specified host-specific netgroups. The third command can be used to get the list
of netgroups for a user.</p>

<p>The client setup is quite simple. To configure the server <var
class="REPLACEABLE">war</var>, you only have to start <span class="CITEREFENTRY"><span
class="REFENTRYTITLE">vipw</span>(8)</span> and replace the line</p>