Date: Wed, 16 Oct 2013 16:32:58 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r42973 - head/en_US.ISO8859-1/books/handbook/network-servers Message-ID: <201310161632.r9GGWwUX031215@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Wed Oct 16 16:32:58 2013 New Revision: 42973 URL: http://svnweb.freebsd.org/changeset/doc/42973 Log: This patch finishes up the NIS section of this chapter. It does the following: - replaces NISv1 Compatibility section with a note that FreeBSD uses v2 - renames Important Things to Remember to Adding New Users and places it as a subsection of Configuring the NIS Master Server - removes the reference to auth.log which is now obsolete - general tightening and clarification A subsequent white-space patch will follow. 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 Wed Oct 16 13:19:44 2013 (r42972) +++ head/en_US.ISO8859-1/books/handbook/network-servers/chapter.xml Wed Oct 16 16:32:58 2013 (r42973) @@ -1074,6 +1074,9 @@ Exports list on foobar: configuration data and to add, remove, or modify configuration data from a single location.</para> + <para>&os; uses version 2 of the <acronym>NIS</acronym> + protocol.</para> + <sect2> <title><acronym>NIS</acronym> Terms and Processes</title> @@ -1456,7 +1459,7 @@ nis_client_flags="-S <replaceable>NIS do <para>It is advisable to remove all entries for system accounts as well as any user accounts that do not need to be propagated to the <acronym>NIS</acronym> clients, such - as the <username>root</username> accounts.</para> + as the <username>root</username> and any other administrative accounts.</para> <note><para>Ensure that the <filename>/var/yp/master.passwd</filename> is neither @@ -1506,6 +1509,28 @@ ellington has been setup as an YP master <programlisting>NOPUSH = "True"</programlisting> </sect3> + + <sect3> + <title>Adding New Users</title> + + <para>Every time a new user is created, the user account must + be added to the master <acronym>NIS</acronym> server and + the <acronym>NIS</acronym> maps rebuilt. Until this occurs, + the new user will not be able to + login anywhere except on the <acronym>NIS</acronym> + master. For example, to add the new user + <username>jsmith</username> to the + <literal>test-domain</literal> domain, run these commands on the + master server:</para> + + <screen>&prompt.root; <userinput>pw useradd jsmith</userinput> +&prompt.root; <userinput>cd /var/yp</userinput> +&prompt.root; <userinput>make test-domain</userinput></screen> + + <para>The user could also be added using + <command>adduser jsmith</command> + instead of <command>pw useradd jsmith</command>.</para> + </sect3> </sect2> <sect2> @@ -1831,37 +1856,24 @@ basie&prompt.root;</screen> <indexterm><primary>netgroups</primary></indexterm> - <para>The method shown in the previous section works reasonably - well for special rules in an environment with small numbers of - users and/or machines. On larger networks, administrators - <emphasis>will</emphasis> likely forget to bar some users from - logging onto sensitive machines, or may even have to modify - each machine separately, thus losing the main benefit of NIS: + <para>Barring specified users from logging on to individual systems + becomes unscaleable on + larger networks and quickly loses the main benefit of <acronym>NIS</acronym>: <emphasis>centralized</emphasis> administration.</para> - <para>The <acronym>NIS</acronym> developers' solution for this - problem is called <emphasis>netgroups</emphasis>. Their - purpose and semantics can be compared to the normal groups - used by &unix; file systems. The main differences are the + <para>Netgroups were developed to handle large, complex networks + with hundreds of users and machines. Their use is comparable + to &unix; groups, where the main difference is the lack of a numeric ID and the ability to define a netgroup by including both user accounts and other netgroups.</para> - <para>Netgroups were developed to handle large, complex networks - with hundreds of users and machines. On one hand, this is a - Good Thing in 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.</para> - - <para>Let us assume that the successful introduction of - <acronym>NIS</acronym> in the laboratory caught a superiors' - interest. The next task is to extend the - <acronym>NIS</acronym> 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.</para> + <para>To expand on the example used in this chapter, the + <acronym>NIS</acronym> domain will be extended to add the users + and systems shown in Tables 28.2 and 28.3:</para> + + <table frame="none" pgwide="1"> + <title>Additional Users</title> - <informaltable frame="none" pgwide="1"> <tgroup cols="2"> <thead> <row> @@ -1874,32 +1886,34 @@ basie&prompt.root;</screen> <row> <entry><username>alpha</username>, <username>beta</username></entry> - <entry>Normal employees of the IT department</entry> + <entry>IT department employees</entry> </row> <row> <entry><username>charlie</username>, <username>delta</username></entry> - <entry>The new apprentices of the IT department</entry> + <entry>IT department apprentices</entry> </row> <row> <entry><username>echo</username>, <username>foxtrott</username>, <username>golf</username>, ...</entry> - <entry>Ordinary employees</entry> + <entry>employees</entry> </row> <row> <entry><username>able</username>, <username>baker</username>, ...</entry> - <entry>The current interns</entry> + <entry>interns</entry> </row> </tbody> </tgroup> - </informaltable> + </table> + + <table frame="none" pgwide="1"> + <title>Additional Systems</title> - <informaltable frame="none" pgwide="1"> <tgroup cols="2"> <thead> <row> @@ -1915,9 +1929,8 @@ basie&prompt.root;</screen> <entry><hostid>war</hostid>, <hostid>death</hostid>, <hostid>famine</hostid>, <hostid>pollution</hostid></entry> - <entry>The most important servers deployed. Only the IT - employees are allowed to log onto these - machines.</entry> + <entry>Only IT + employees are allowed to log onto these servers.</entry> </row> <row> @@ -1925,62 +1938,47 @@ basie&prompt.root;</screen> <entry><hostid>pride</hostid>, <hostid>greed</hostid>, <hostid>envy</hostid>, <hostid>wrath</hostid>, <hostid>lust</hostid>, <hostid>sloth</hostid></entry> - <entry>Less important servers. All members of the IT + <entry>All members of the IT department are allowed to login onto these - machines.</entry> + servers.</entry> </row> <row> <entry><hostid>one</hostid>, <hostid>two</hostid>, <hostid>three</hostid>, <hostid>four</hostid>, ...</entry> - <entry>Ordinary workstations. Only the - <emphasis>real</emphasis> employees are allowed to use - these machines.</entry> + <entry>Ordinary workstations used by + employees.</entry> </row> <row> <entry><hostid>trashcan</hostid></entry> <entry>A very old machine without any critical data. - Even the intern is allowed to use this box.</entry> + Even interns are allowed to use this system.</entry> </row> </tbody> </tgroup> - </informaltable> + </table> - <para>An attempt to implement these restrictions by separately - blocking each user, would require the addition of the - <literal>-<replaceable>user</replaceable></literal> line to - each system's <filename>passwd</filename>. One line for each - user who is not allowed to login onto that system. Forgetting - just one entry could cause significant trouble. It may be - feasible to do this correctly during the initial setup; - however, eventually someone will forget to add these lines for - new users.</para> - - <para>Handling this situation with netgroups offers several - advantages. Each user need not be handled separately; they - would be assigned to one or more netgroups and logins would be - allowed or forbidden for all members of the netgroup. While + <para>When using netgroups to configure this scenario, + each user is + assigned to one or more netgroups and logins are then + allowed or forbidden for all members of the netgroup. When adding a new machine, login restrictions must be defined for - all netgroups. If a new user is added, they must be added to - one or more netgroups. Those changes are independent of each - other: no more <quote>for each combination of user and machine - do...</quote> If the <acronym>NIS</acronym> setup is + all netgroups. When a new user is added, the account must be added to + one or more netgroups. If the <acronym>NIS</acronym> setup is planned carefully, only one central configuration file needs modification to grant or deny access to machines.</para> <para>The first step is the initialization of the - <acronym>NIS</acronym> map netgroup. &os;'s &man.ypinit.8; - does not create this map by default, but its - <acronym>NIS</acronym> implementation will support it after - creation. To create an empty map, simply type</para> - - <screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen> - - <para>and begin adding content. For our example, we need at - least four netgroups: IT employees, IT apprentices, normal - employees and interns.</para> + <acronym>NIS</acronym> <literal>netgroup</literal> map. In &os;, + this map is not created by default. On the + <acronym>NIS</acronym> master server, use an editor to create + a map named <filename>/var/yp/netgroup</filename>.</para> + + <para>This example creates + four netgroups to represent IT employees, IT apprentices, + employees, and interns:</para> <programlisting>IT_EMP (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) @@ -1988,17 +1986,17 @@ USERS (,echo,test-domain) (,foxtro (,golf,test-domain) INTERNS (,able,test-domain) (,baker,test-domain)</programlisting> - <para><literal>IT_EMP</literal>, <literal>IT_APP</literal> 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:</para> + <para>Each entry configures a netgroup. The first column in an entry + is the name of the netgroup. Each set of brackets represents + either a group of one or more users or the name of another netgroup. + When specifying a user, the three comma-delimited fields inside each + group represent:</para> <orderedlist> <listitem> - <para>The name of the host(s) where the following items are + <para>The name of the host(s) where the other fields representing the user are valid. If a hostname is not specified, the entry is valid - on all hosts. If a hostname is specified, it will need to - be micro-managed within this configuration.</para> + on all hosts.</para> </listitem> <listitem> @@ -2013,38 +2011,34 @@ INTERNS (,able,test-domain) (,baker, </listitem> </orderedlist> - <para>Each of these fields may contain wildcards. See + <para>If a group contains multiple users, separate each user with + whitespace. Additionally, each field may contain wildcards. See &man.netgroup.5; for details.</para> - <note> <indexterm><primary>netgroups</primary></indexterm> <para>Netgroup names longer than 8 characters should not be - used, especially with machines running other operating - systems within the <acronym>NIS</acronym> domain. The names - are case sensitive; using capital letters for netgroup names + used. The names + are case sensitive and using capital letters for netgroup names is an easy way to distinguish between user, machine and netgroup names.</para> - <para>Some <acronym>NIS</acronym> clients (other than &os;) - cannot handle netgroups with a large number of entries. For - example, some older versions of &sunos; start to cause - trouble if a netgroup contains more than 15 - <emphasis>entries</emphasis>. This limit may be + <para>Some non-&os; <acronym>NIS</acronym> clients + cannot handle netgroups containing more than 15 + entries. This limit may be circumvented by creating several sub-netgroups with 15 users or fewer and a real netgroup consisting of the - sub-netgroups:</para> + sub-netgroups, as seen in this example:</para> <programlisting>BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3</programlisting> - <para>Repeat this process if more than 225 users will exist + <para>Repeat this process if more than 225 (15 times 15) users exist within a single netgroup.</para> - </note> - <para>Activating and distributing the new - <acronym>NIS</acronym> map is easy:</para> + <para>To activate and distribute the new + <acronym>NIS</acronym> map:</para> <screen>ellington&prompt.root; <userinput>cd /var/yp</userinput> ellington&prompt.root; <userinput>make</userinput></screen> @@ -2052,7 +2046,7 @@ ellington&prompt.root; <userinput>make</ <para>This will generate the three <acronym>NIS</acronym> maps <filename>netgroup</filename>, <filename>netgroup.byhost</filename> and - <filename>netgroup.byuser</filename>. Use &man.ypcat.1; to + <filename>netgroup.byuser</filename>. Use the map key option of &man.ypcat.1; to check if the new <acronym>NIS</acronym> maps are available:</para> @@ -2062,13 +2056,14 @@ ellington&prompt.user; <userinput>ypcat <para>The output of the first command should resemble the contents of <filename>/var/yp/netgroup</filename>. The second - command will not produce output without specified - host-specific netgroups. The third command may be used to get + command only produces output if + host-specific netgroups were created. The third command is used to get the list of netgroups for a user.</para> - <para>The client setup is quite simple. To configure the server - <hostid>war</hostid>, use &man.vipw.8; to replace the - line</para> + <para>To configure a client, use &man.vipw.8; to specify the name + of the netgroup. For example, on the server named + <hostid>war</hostid>, replace this + line:</para> <programlisting>+:::::::::</programlisting> @@ -2076,85 +2071,63 @@ ellington&prompt.user; <userinput>ypcat <programlisting>+@IT_EMP:::::::::</programlisting> - <para>Now, only the data for the users defined in the netgroup - <literal>IT_EMP</literal> is imported into - <hostid>war</hostid>'s password database and only these users - are allowed to login.</para> - - <para>Unfortunately, this limitation also applies to the - <literal>~</literal> function of the shell and all routines - converting between user names and numerical user IDs. In + <para>This specifies that only the users defined in the netgroup + <literal>IT_EMP</literal> will be imported into this system's + password database and only those users + are allowed to login to this system.</para> + + <para>This configuration also applies to the + <literal>~</literal> function of the shell and all routines which + convert between user names and numerical user IDs. In other words, <command>cd ~<replaceable>user</replaceable></command> will not work, <command>ls -l</command> will show the numerical ID - instead of the username and - <command>find . -user joe -print</command> will fail with + instead of the username, and + <command>find . -user joe -print</command> will fail with the message <errorname>No such user</errorname>. To fix this, import all - user entries <emphasis>without allowing them to login into the - servers</emphasis>.</para> - - <para>This can be achieved by adding another line to - <filename>/etc/master.passwd</filename>. This line should - contain:</para> - - <para><literal>+:::::::::/sbin/nologin</literal>, meaning - <quote>Import all entries but replace the shell with - <filename>/sbin/nologin</filename> in the imported - entries</quote>. It is possible to replace any field in the - <literal>passwd</literal> entry by placing a default value in - <filename>/etc/master.passwd</filename>.</para> + user entries without allowing them to login into the + servers. This can be achieved by adding an extra line:</para> + + <programlisting>+:::::::::/sbin/nologin</programlisting> + + <para>This line configures the client to + import all entries but to replace the shell in those entries with + <filename>/sbin/nologin</filename>.</para> <!-- Been there, done that, got the scars to prove it - ue --> - <warning> - <para>Make sure that the line - <literal>+:::::::::/sbin/nologin</literal> is placed after + <para>Make sure that extra line + is placed <emphasis>after</emphasis> <literal>+@IT_EMP:::::::::</literal>. Otherwise, all user accounts imported from <acronym>NIS</acronym> will have <filename>/sbin/nologin</filename> as their login - shell.</para> - </warning> + shell and noone will be able to login to the system.</para> - <para>After this change, the <acronym>NIS</acronym> map will - only need modification when a new employee joins the IT - department. A similar approach for the less important servers - may be used by replacing the old <literal>+:::::::::</literal> - in their local version of - <filename>/etc/master.passwd</filename> with something like - this:</para> + <para>To configure the less important servers, + replace the old <literal>+:::::::::</literal> + on the servers with these lines:</para> <programlisting>+@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin</programlisting> - <para>The corresponding lines for the normal workstations - could be:</para> + <para>The corresponding lines for the workstations + would be:</para> <programlisting>+@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin</programlisting> - <para>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. Add a - new netgroup <literal>IT_INTERN</literal>, then add the new IT - interns to this netgroup and start to change the configuration - on each and every machine. As the old saying goes: - <quote>Errors in centralized planning lead to global - mess</quote>.</para> - - <para>NIS' ability to create netgroups from other netgroups can - be used to prevent situations like these. One possibility is + <para>NIS supports the creation of netgroups from other netgroups which + can be useful if the policy regarding user access changes. One possibility is the creation of role-based netgroups. For example, one might create a netgroup called <literal>BIGSRV</literal> to define the login restrictions for the important servers, another netgroup called <literal>SMALLSRV</literal> for the less - important servers and a third netgroup called - <literal>USERBOX</literal> for the normal workstations. Each + important servers, and a third netgroup called + <literal>USERBOX</literal> for the workstations. Each of these netgroups contains the netgroups that are allowed to login onto these machines. The new entries for the - <acronym>NIS</acronym> map netgroup should look like + <acronym>NIS</acronym> <literal>netgroup</literal> map would look like this:</para> <programlisting>BIGSRV IT_EMP IT_APP @@ -2168,16 +2141,15 @@ USERBOX IT_EMP ITINTERN USERS</progra to define login restrictions on a per-machine basis is required.</para> - <para>Machine-specific netgroup definitions are the other - possibility to deal with the policy change outlined above. In + <para>Machine-specific netgroup definitions are another + possibility to deal with the policy changes. In this scenario, the <filename>/etc/master.passwd</filename> of - each box contains two lines starting with <quote>+</quote>. - The first of them adds a netgroup with the accounts allowed to - login onto this machine, the second one adds all other + each system contains two lines starting with <quote>+</quote>. + The first line adds a netgroup with the accounts allowed to + login onto this machine and the second line adds all other accounts with <filename>/sbin/nologin</filename> as shell. It - is a good idea to use the <quote>ALL-CAPS</quote> version of - the machine name as the name of the netgroup. In other words, - the lines should look like this:</para> + is recommended to use the <quote>ALL-CAPS</quote> version of + the hostname as the name of the netgroup:</para> <programlisting>+@<replaceable>BOXNAME</replaceable>::::::::: +:::::::::/sbin/nologin</programlisting> @@ -2187,8 +2159,7 @@ USERBOX IT_EMP ITINTERN USERS</progra <filename>/etc/master.passwd</filename> ever again. All further changes can be handled by modifying the <acronym>NIS</acronym> map. Here is an example of a possible - netgroup map for this scenario with some additional - goodies:</para> + <literal>netgroup</literal> map for this scenario:</para> <programlisting># Define groups of users first IT_EMP (,alpha,test-domain) (,beta,test-domain) @@ -2226,159 +2197,55 @@ ONE SECURITY TWO (,hotel,test-domain) # [...more groups to follow]</programlisting> - <para>If some kind of database is used to manage the user - accounts, it may be possible to create the first part of the - map using the database's reporting tools. This way, new users - will automatically have access to the boxes.</para> - - <para>One last word of caution: It may not always be advisable + <para>It may not always be advisable to use machine-based netgroups. When deploying a couple of - dozen or even hundreds of identical machines for student labs, + dozen or hundreds of systems, role-based netgroups instead of machine-based netgroups may be used to keep the size of the <acronym>NIS</acronym> map within reasonable limits.</para> </sect2> <sect2> - <title>Important Things to Remember</title> - - <para>There are still a couple of things administrators need to - do differently now that machines are in an NIS - environment.</para> - - <itemizedlist> - <listitem> - <para>Every time a new user is added to the lab, they must - be added to the master <acronym>NIS</acronym> server and - the <acronym>NIS</acronym> maps will need rebuilt. If - this step is omitted, the new user will not be able to - login anywhere except on the <acronym>NIS</acronym> - master. For example, if we needed to add a new user - <username>jsmith</username> to the lab, we would:</para> - - <screen>&prompt.root; <userinput>pw useradd jsmith</userinput> -&prompt.root; <userinput>cd /var/yp</userinput> -&prompt.root; <userinput>make test-domain</userinput></screen> - - <para>The user may also be added using - <command>adduser jsmith</command> - instead of <command>pw useradd jsmith</command>.</para> - </listitem> - - <listitem> - <para><emphasis>Keep the administration accounts out of the - <acronym>NIS</acronym> maps</emphasis>. This is - undesirable as it will create a security risk. These - users and passwords should not be propagated to all - machines. Especially if these machines will have users - whom should not have access to those accounts.</para> - </listitem> - - <listitem> - <para><emphasis>Keep the <acronym>NIS</acronym> master and - slave secure, and minimize their downtime</emphasis>. - If somebody either hacks or simply turns off these - machines, they have effectively rendered many people - without the ability to login to the lab.</para> - - <para>This is the chief weakness of any centralized - administration system. If the <acronym>NIS</acronym> - servers are not protected, there will be a lot of angry - users and unhappy management!</para> - </listitem> - </itemizedlist> - </sect2> - - <sect2> - <title><acronym>NIS</acronym> v1 Compatibility</title> - - <para>&os;'s <application>ypserv</application> has some support - for serving <acronym>NIS</acronym> v1 clients. &os;'s - <acronym>NIS</acronym> implementation only uses the - <acronym>NIS</acronym> v2 protocol; however, other - implementations include support for the v1 protocol for - backwards compatibility with older systems. The - <application>ypbind</application> daemons supplied with these - systems will attempt to establish a binding to an - <acronym>NIS</acronym>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 - <application>ypserv</application> does not handle v1 map - transfer requests. Additionally, it cannot be used as a - master or slave in conjunction with older - <acronym>NIS</acronym> servers that only support the v1 - protocol. Fortunately, there probably are not any such - servers still in use today.</para> - </sect2> - - <sect2> <title>Password Formats</title> <indexterm> <primary>NIS</primary> <secondary>password formats</secondary> </indexterm> - <para>One of the most common issues that people run into when - trying to implement <acronym>NIS</acronym> is password format - compatibility. If the <acronym>NIS</acronym> server is using - DES encrypted passwords, it will only support clients that are - also using DES. For example, if any &solaris; - <acronym>NIS</acronym> clients exist on the network, there is - a highly likelihood DES must be used for encrypted - passwords.</para> - - <para>To check which format the servers and clients are using, - look at <filename>/etc/login.conf</filename>. If the host is - configured to use DES encrypted passwords, then the - <literal>default</literal> class will contain an entry like - this:</para> + <para><acronym>NIS</acronym> requires that all hosts within an + <acronym>NIS</acronym> domain use the same format for encrypting passwords. + If users have trouble authenticating on an + <acronym>NIS</acronym> client, it may be due to a differing password format. + In a heterogeneous network, the format must be supported by all operating systems, where + <acronym>DES</acronym> + is the lowest common standard.</para> + + <para>To check which format a server or client is using, + look at this section of <filename>/etc/login.conf</filename>:</para> <programlisting>default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Further entries elided]</programlisting> - <para>Other possible values for the - <literal>passwd_format</literal> capability include - <literal>blf</literal> and <literal>md5</literal> (for - Blowfish and MD5 encrypted passwords, respectively).</para> - - <para>If any changes were made to - <filename>/etc/login.conf</filename>, the login capability - database must be rebuilt by running the following command as - <username>root</username>:</para> + <para>In this example, the system is using the <acronym>DES</acronym> + format. Other possible values are + <literal>blf</literal> for Blowfish and <literal>md5</literal> for + MD5 encrypted passwords.</para> + + <para>If the format on a host needs to be edited to match the one + being used in the <acronym>NIS</acronym> domain, + the login capability + database must be rebuilt after saving the change:</para> <screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen> <note> - <para>The format of passwords already in - <filename>/etc/master.passwd</filename> will not be updated - until a user changes his password for the first time + <para>The format of passwords for existing user accounts will not be updated + until each user changes their password <emphasis>after</emphasis> the login capability database is rebuilt.</para> </note> - - <para>Next, in order to ensure that passwords are encrypted with - the chosen format, check that the - <literal>crypt_default</literal> in - <filename>/etc/auth.conf</filename> gives precedence to the - chosen password format. To do this, place the chosen format - first in the list. For example, when using DES encrypted - passwords, the entry would be:</para> - - <programlisting>crypt_default = des blf md5</programlisting> - - <para>Having followed the above steps on each of the &os; based - <acronym>NIS</acronym> servers and clients, verify that they - all agree on which password format is used within the network. - If users have trouble authenticating on an - <acronym>NIS</acronym> client, this is a pretty good place to - start looking for possible problems. Remember: to deploy an - <acronym>NIS</acronym> server for a heterogeneous network, - they will probably have to use DES on all systems because it - is the lowest common standard.</para> </sect2> </sect1>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201310161632.r9GGWwUX031215>