network-nis.html

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

<pre class="PROGRAMLISTING">
+:::::::::
</pre>

<p>with</p>

<pre class="PROGRAMLISTING">
+@IT_EMP:::::::::
</pre>

<p>Now, only the data for the users defined in the netgroup <var
class="REPLACEABLE">IT_EMP</var> is imported into <var class="REPLACEABLE">war</var>'s
password database and only these users are allowed to login.</p>

<p>Unfortunately, this limitation also applies to the ~ function of the shell and all
routines converting between user names and numerical user IDs. In other words, <tt
class="COMMAND">cd ~<var class="REPLACEABLE">user</var></tt> will not work, <tt
class="COMMAND">ls -l</tt> will show the numerical id instead of the username and <tt
class="COMMAND">find . -user joe -print</tt> will fail with ``<tt class="ERRORNAME">No
such user</tt>''. To fix this, you will have to import all user entries <span
class="emphasis"><i class="EMPHASIS">without allowing them to login onto your
servers</i></span>.</p>

<p>This can be achieved by adding another line to <tt
class="FILENAME">/etc/master.passwd</tt>. This line should contain:</p>

<p><var class="LITERAL">+:::::::::/sbin/nologin</var>, meaning ``Import all entries but
replace the shell with <tt class="FILENAME">/sbin/nologin</tt> in the imported entries''.
You can replace any field in the passwd entry by placing a default value in your <tt
class="FILENAME">/etc/master.passwd</tt>.</p>

<div class="WARNING">
<blockquote class="WARNING">
<p><b>Warning</b>Make sure that the line <var
class="LITERAL">+:::::::::/sbin/nologin</var> is placed after <var
class="LITERAL">+@IT_EMP:::::::::</var>. Otherwise, all user accounts imported from NIS
will have /sbin/nologin as their login shell.</p>
</blockquote>
</div>

<p>After this change, you will only have to change one NIS map if a new employee joins
the IT department. You could use a similar approach for the less important servers by
replacing the old <var class="LITERAL">+:::::::::</var> in their local version of <tt
class="FILENAME">/etc/master.passwd</tt> with something like this:</p>

<pre class="PROGRAMLISTING">
+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin
</pre>

<p>The corresponding lines for the normal workstations could be:</p>

<pre class="PROGRAMLISTING">
+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin
</pre>

<p>And everything would be fine until there is a policy change a few weeks later: The IT
department starts hiring interns. The IT interns are allowed to use the normal
workstations and the less important servers; and the IT apprentices are allowed to login
onto the main servers. You add a new netgroup IT_INTERN, add the new IT interns to this
netgroup and start to change the config on each and every machine... As the old saying
goes: ``Errors in centralized planning lead to global mess''.</p>

<p>NIS' ability to create netgroups from other netgroups can be used to prevent
situations like these. One possibility is the creation of role-based netgroups. For
example, you could create a netgroup called <var class="REPLACEABLE">BIGSRV</var> to
define the login restrictions for the important servers, another netgroup called <var
class="REPLACEABLE">SMALLSRV</var> for the less important servers and a third netgroup
called <var class="REPLACEABLE">USERBOX</var> for the normal workstations. Each of these
netgroups contains the netgroups that are allowed to login onto these machines. The new
entries for your NIS map netgroup should look like this:</p>

<pre class="PROGRAMLISTING">
BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP  ITINTERN
USERBOX   IT_EMP  ITINTERN USERS
</pre>

<p>This method of defining login restrictions works reasonably well if you can define
groups of machines with identical restrictions. Unfortunately, this is the exception and
not the rule. Most of the time, you will need the ability to define login restrictions on
a per-machine basis.</p>

<p>Machine-specific netgroup definitions are the other possibility to deal with the
policy change outlined above. In this scenario, the <tt
class="FILENAME">/etc/master.passwd</tt> of each box contains two lines starting with
``+''. The first of them adds a netgroup with the accounts allowed to login onto this
machine, the second one adds all other accounts with <tt
class="FILENAME">/sbin/nologin</tt> as shell. It is a good idea to use the ALL-CAPS
version of the machine name as the name of the netgroup. In other words, the lines should
look like this:</p>

<pre class="PROGRAMLISTING">
+@<var class="REPLACEABLE">BOXNAME</var>:::::::::
+:::::::::/sbin/nologin
</pre>

<p>Once you have completed this task for all your machines, you will not have to modify
the local versions of <tt class="FILENAME">/etc/master.passwd</tt> ever again. All
further changes can be handled by modifying the NIS map. Here is an example of a possible
netgroup map for this scenario with some additional goodies.</p>

<pre class="PROGRAMLISTING">
# Define groups of users first
IT_EMP    (,alpha,test-domain)    (,beta,test-domain)
IT_APP    (,charlie,test-domain)  (,delta,test-domain)
DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)
DEPT2     (,golf,test-domain)     (,hotel,test-domain)
DEPT3     (,india,test-domain)    (,juliet,test-domain)
ITINTERN  (,kilo,test-domain)     (,lima,test-domain)
D_INTERNS (,able,test-domain)     (,baker,test-domain)
#
# Now, define some groups based on roles
USERS     DEPT1   DEPT2     DEPT3
BIGSRV    IT_EMP  IT_APP
SMALLSRV  IT_EMP  IT_APP    ITINTERN
USERBOX   IT_EMP  ITINTERN  USERS
#
# And a groups for a special tasks
# Allow echo and golf to access our anti-virus-machine
SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)
#
# machine-based netgroups
# Our main servers
WAR       BIGSRV
FAMINE    BIGSRV
# User india needs access to this server
POLLUTION  BIGSRV  (,india,test-domain)
#
# This one is really important and needs more access restrictions
DEATH     IT_EMP
#
# The anti-virus-machine mentioned above
ONE       SECURITY
#
# Restrict a machine to a single user
TWO       (,hotel,test-domain)
# [...more groups to follow]
</pre>

<p>If you are using some kind of database to manage your user accounts, you should be
able to create the first part of the map with your database's report tools. This way, new
users will automatically have access to the boxes.</p>

<p>One last word of caution: It may not always be advisable to use machine-based
netgroups. If you are deploying a couple of dozen or even hundreds of identical machines
for student labs, you should use role-based netgroups instead of machine-based netgroups
to keep the size of the NIS map within reasonable limits.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN27462" name="AEN27462">19.9.8. Important Things to
Remember</a></h2>

<p>There are still a couple of things that you will need to do differently now that you
are in an NIS environment.</p>

<ul>
<li>
<p>Every time you wish to add a user to the lab, you must add it to the master NIS server
<span class="emphasis"><i class="EMPHASIS">only</i></span>, and <span class="emphasis"><i
class="EMPHASIS">you must remember to rebuild the NIS maps</i></span>. If you forget to
do this, the new user will not be able to login anywhere except on the NIS master. For
example, if we needed to add a new user ``jsmith'' to the lab, we would:</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">pw useradd jsmith</kbd>
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">cd /var/yp</kbd>
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">make test-domain</kbd>
</pre>

<p>You could also run <tt class="COMMAND">adduser jsmith</tt> instead of <tt
class="COMMAND">pw useradd jsmith</tt>.</p>
</li>

<li>
<p><span class="emphasis"><i class="EMPHASIS">Keep the administration accounts out of the
NIS maps</i></span>. You do not want to be propagating administrative accounts and
passwords to machines that will have users that should not have access to those
accounts.</p>
</li>

<li>
<p><span class="emphasis"><i class="EMPHASIS">Keep the NIS master and slave secure, and
minimize their downtime</i></span>. If somebody either hacks or simply turns off these
machines, they have effectively rendered many people without the ability to login to the
lab.</p>

<p>This is the chief weakness of any centralized administration system. If you do not
protect your NIS servers, you will have a lot of angry users!</p>
</li>
</ul>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN27488" name="AEN27488">19.9.9. NIS v1 Compatibility</a></h2>

<p>FreeBSD's <b class="APPLICATION">ypserv</b> has some support for serving NIS v1
clients. FreeBSD's NIS implementation only uses the NIS v2 protocol, however other
implementations include support for the v1 protocol for backwards compatibility with
older systems. The <b class="APPLICATION">ypbind</b> daemons supplied with these systems
will try to establish a binding to an NIS v1 server even though they may never actually
need it (and they may persist in broadcasting in search of one even after they receive a
response from a v2 server). Note that while support for normal client calls is provided,
this version of ypserv does not handle v1 map transfer requests; consequently, it cannot
be used as a master or slave in conjunction with older NIS servers that only support the
v1 protocol. Fortunately, there probably are not any such servers still in use today.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="NETWORK-NIS-SERVER-IS-CLIENT"
name="NETWORK-NIS-SERVER-IS-CLIENT">19.9.10. NIS Servers That Are Also NIS
Clients</a></h2>

<p>Care must be taken when running ypserv in a multi-server domain where the server
machines are also NIS clients. It is generally a good idea to force the servers to bind
to themselves rather than allowing them to broadcast bind requests and possibly become
bound to each other. Strange failure modes can result if one server goes down and others
are dependent upon it. Eventually all the clients will time out and attempt to bind to
other servers, but the delay involved can be considerable and the failure mode is still
present since the servers might bind to each other all over again.</p>

<p>You can force a host to bind to a particular server by running <tt
class="COMMAND">ypbind</tt> with the <var class="OPTION">-S</var> flag. If you do not
want to do this manually each time you reboot your NIS server, you can add the following
lines to your <tt class="FILENAME">/etc/rc.conf</tt>:</p>

<pre class="PROGRAMLISTING">
nis_client_enable="YES"    # run client stuff as well
nis_client_flags="-S <var class="REPLACEABLE">NIS domain</var>,<var
class="REPLACEABLE">server</var>"
</pre>

<p>See <span class="CITEREFENTRY"><span class="REFENTRYTITLE">ypbind</span>(8)</span> for
further information.</p>
</div>

<div class="SECT2">
<h2 class="SECT2"><a id="AEN27507" name="AEN27507">19.9.11. Password Formats</a></h2>

<p>One of the most common issues that people run into when trying to implement NIS is
password format compatibility. If your NIS server is using DES encrypted passwords, it
will only support clients that are also using DES. For example, if you have <span
class="TRADEMARK">Solaris</span> NIS clients in your network, then you will almost
certainly need to use DES encrypted passwords.</p>

<p>To check which format your servers and clients are using, look at <tt
class="FILENAME">/etc/login.conf</tt>. If the host is configured to use DES encrypted
passwords, then the <var class="LITERAL">default</var> class will contain an entry like
this:</p>

<pre class="PROGRAMLISTING">
default:\
    :passwd_format=des:\
    :copyright=/etc/COPYRIGHT:\
    [Further entries elided]
</pre>

<p>Other possible values for the <var class="LITERAL">passwd_format</var> capability
include <var class="LITERAL">blf</var> and <var class="LITERAL">md5</var> (for Blowfish
and MD5 encrypted passwords, respectively).</p>

<p>If you have made changes to <tt class="FILENAME">/etc/login.conf</tt>, you will also
need to rebuild the login capability database, which is achieved by running the following
command as <tt class="USERNAME">root</tt>:</p>

<pre class="SCREEN">
<samp class="PROMPT">#</samp> <kbd class="USERINPUT">cap_mkdb /etc/login.conf</kbd>
</pre>

<div class="NOTE">
<blockquote class="NOTE">
<p><b>Note:</b> The format of passwords already in <tt
class="FILENAME">/etc/master.passwd</tt> will not be updated until a user changes their
password for the first time <span class="emphasis"><i class="EMPHASIS">after</i></span>
the login capability database is rebuilt.</p>
</blockquote>
</div>

<p>Next, in order to ensure that passwords are encrypted with the format that you have
chosen, you should also check that the <var class="LITERAL">crypt_default</var> in <tt
class="FILENAME">/etc/auth.conf</tt> gives precedence to your chosen password format. To
do this, place the format that you have chosen first in the list. For example, when using
DES encrypted passwords, the entry would be:</p>

<pre class="PROGRAMLISTING">
crypt_default  =   des blf md5
</pre>

<p>Having followed the above steps on each of the FreeBSD based NIS servers and clients,
you can be sure that they all agree on which password format is used within your network.
If you have trouble authenticating on an NIS client, this is a pretty good place to start
looking for possible problems. Remember: if you want to deploy an NIS server for a
heterogenous network, you will probably have to use DES on all systems because it is the
lowest common standard.</p>
</div>
</div>

<div class="NAVFOOTER">
<hr align="LEFT" width="100%" />
<table summary="Footer navigation table" width="100%" border="0" cellpadding="0"
cellspacing="0">
<tr>
<td width="33%" align="left" valign="top"><a href="network-isdn.html"
accesskey="P">Prev</a></td>
<td width="34%" align="center" valign="top"><a href="index.html"
accesskey="H">Home</a></td>
<td width="33%" align="right" valign="top"><a href="network-dhcp.html"
accesskey="N">Next</a></td>
</tr>

<tr>
<td width="33%" align="left" valign="top">ISDN</td>
<td width="34%" align="center" valign="top"><a href="advanced-networking.html"
accesskey="U">Up</a></td>
<td width="33%" align="right" valign="top">DHCP</td>
</tr>
</table>
</div>
</body>
</html>