From owner-svn-doc-all@FreeBSD.ORG Wed Oct 16 16:32:58 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 CD877DC3; Wed, 16 Oct 2013 16:32:58 +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 B87082A83; Wed, 16 Oct 2013 16:32:58 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.7/8.14.7) with ESMTP id r9GGWwt3031216; Wed, 16 Oct 2013 16:32:58 GMT (envelope-from dru@svn.freebsd.org) Received: (from dru@localhost) by svn.freebsd.org (8.14.7/8.14.5/Submit) id r9GGWwUX031215; Wed, 16 Oct 2013 16:32:58 GMT (envelope-from dru@svn.freebsd.org) Message-Id: <201310161632.r9GGWwUX031215@svn.freebsd.org> From: Dru Lavigne Date: Wed, 16 Oct 2013 16:32:58 +0000 (UTC) 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 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: Wed, 16 Oct 2013 16:32:58 -0000 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. + &os; uses version 2 of the NIS + protocol. + <acronym>NIS</acronym> Terms and Processes @@ -1456,7 +1459,7 @@ nis_client_flags="-S NIS do 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 NIS clients, such - as the root accounts. + as the root and any other administrative accounts. Ensure that the /var/yp/master.passwd is neither @@ -1506,6 +1509,28 @@ ellington has been setup as an YP master NOPUSH = "True" + + + Adding New Users + + Every time a new user is created, the user account must + be added to the master NIS server and + the NIS maps rebuilt. Until this occurs, + the new user will not be able to + login anywhere except on the NIS + master. For example, to add the new user + jsmith to the + test-domain domain, run these commands on the + master server: + + &prompt.root; pw useradd jsmith +&prompt.root; cd /var/yp +&prompt.root; make test-domain + + The user could also be added using + adduser jsmith + instead of pw useradd jsmith. + @@ -1831,37 +1856,24 @@ basie&prompt.root; netgroups - 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 - will 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: + Barring specified users from logging on to individual systems + becomes unscaleable on + larger networks and quickly loses the main benefit of NIS: centralized administration. - The NIS developers' solution for this - problem is called netgroups. Their - purpose and semantics can be compared to the normal groups - used by &unix; file systems. The main differences are the + 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. - 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. - - Let us assume that the successful introduction of - NIS in the laboratory caught a superiors' - interest. The next task is to extend the - 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. + To expand on the example used in this chapter, the + NIS domain will be extended to add the users + and systems shown in Tables 28.2 and 28.3: + + + Additional Users - @@ -1874,32 +1886,34 @@ basie&prompt.root; alpha, beta - Normal employees of the IT department + IT department employees charlie, delta - The new apprentices of the IT department + IT department apprentices echo, foxtrott, golf, ... - Ordinary employees + employees able, baker, ... - The current interns + interns - +
+ + + Additional Systems - @@ -1915,9 +1929,8 @@ basie&prompt.root; war, death, famine, pollution - The most important servers deployed. Only the IT - employees are allowed to log onto these - machines. + Only IT + employees are allowed to log onto these servers. @@ -1925,62 +1938,47 @@ basie&prompt.root; pride, greed, envy, wrath, lust, sloth - Less important servers. All members of the IT + All members of the IT department are allowed to login onto these - machines. + servers. one, two, three, four, ... - Ordinary workstations. Only the - real employees are allowed to use - these machines. + Ordinary workstations used by + employees. trashcan A very old machine without any critical data. - Even the intern is allowed to use this box. + Even interns are allowed to use this system. - +
- An attempt to implement these restrictions by separately - blocking each user, would require the addition of the - -user line to - each system's passwd. 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. - - 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 + 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 for each combination of user and machine - do... If the NIS setup is + all netgroups. When a new user is added, the account must be added to + one or more netgroups. If the NIS setup is planned carefully, only one central configuration file needs modification to grant or deny access to machines. The first step is the initialization of the - NIS map netgroup. &os;'s &man.ypinit.8; - does not create this map by default, but its - NIS implementation will support it after - creation. To create an empty map, simply type - - ellington&prompt.root; vi /var/yp/netgroup - - and begin adding content. For our example, we need at - least four netgroups: IT employees, IT apprentices, normal - employees and interns. + NIS netgroup map. In &os;, + this map is not created by default. On the + NIS master server, use an editor to create + a map named /var/yp/netgroup. + + This example creates + four netgroups to represent IT employees, IT apprentices, + employees, and interns: 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) - IT_EMP, IT_APP 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: + 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: - The name of the host(s) where the following items are + 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. + on all hosts. @@ -2013,38 +2011,34 @@ INTERNS (,able,test-domain) (,baker, - Each of these fields may contain wildcards. See + If a group contains multiple users, separate each user with + whitespace. Additionally, each field may contain wildcards. See &man.netgroup.5; for details. - netgroups Netgroup names longer than 8 characters should not be - used, especially with machines running other operating - systems within the NIS 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. - Some NIS 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 - entries. This limit may be + Some non-&os; NIS 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: + sub-netgroups, as seen in this example: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - Repeat this process if more than 225 users will exist + Repeat this process if more than 225 (15 times 15) users exist within a single netgroup. - - Activating and distributing the new - NIS map is easy: + To activate and distribute the new + NIS map: ellington&prompt.root; cd /var/yp ellington&prompt.root; make @@ -2052,7 +2046,7 @@ ellington&prompt.root; makeThis will generate the three NIS maps netgroup, netgroup.byhost and - netgroup.byuser. Use &man.ypcat.1; to + netgroup.byuser. Use the map key option of &man.ypcat.1; to check if the new NIS maps are available: @@ -2062,13 +2056,14 @@ ellington&prompt.user; ypcat The output of the first command should resemble the contents of /var/yp/netgroup. 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. - The client setup is quite simple. To configure the server - war, use &man.vipw.8; to replace the - line + To configure a client, use &man.vipw.8; to specify the name + of the netgroup. For example, on the server named + war, replace this + line: +::::::::: @@ -2076,85 +2071,63 @@ ellington&prompt.user; ypcat +@IT_EMP::::::::: - Now, only the data for the users defined in the netgroup - IT_EMP is imported into - war's password database and only these users - are allowed to login. - - Unfortunately, this limitation also applies to the - ~ function of the shell and all routines - converting between user names and numerical user IDs. In + This specifies that only the users defined in the netgroup + IT_EMP will be imported into this system's + password database and only those users + are allowed to login to this system. + + This configuration also applies to the + ~ function of the shell and all routines which + convert between user names and numerical user IDs. In other words, cd ~user will not work, ls -l will show the numerical ID - instead of the username and - find . -user joe -print will fail with + instead of the username, and + find . -user joe -print will fail with the message No such user. To fix this, import all - user entries without allowing them to login into the - servers. - - This can be achieved by adding another line to - /etc/master.passwd. This line should - contain: - - +:::::::::/sbin/nologin, meaning - Import all entries but replace the shell with - /sbin/nologin in the imported - entries. It is possible to replace any field in the - passwd entry by placing a default value in - /etc/master.passwd. + user entries without allowing them to login into the + servers. This can be achieved by adding an extra line: + + +:::::::::/sbin/nologin + + This line configures the client to + import all entries but to replace the shell in those entries with + /sbin/nologin. - - Make sure that the line - +:::::::::/sbin/nologin is placed after + Make sure that extra line + is placed after +@IT_EMP:::::::::. Otherwise, all user accounts imported from NIS will have /sbin/nologin as their login - shell. - + shell and noone will be able to login to the system. - After this change, the NIS 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 +::::::::: - in their local version of - /etc/master.passwd with something like - this: + To configure the less important servers, + replace the old +::::::::: + on the servers with these lines: +@IT_EMP::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin - The corresponding lines for the normal workstations - could be: + The corresponding lines for the workstations + would be: +@IT_EMP::::::::: +@USERS::::::::: +:::::::::/sbin/nologin - 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 IT_INTERN, 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: - Errors in centralized planning lead to global - mess. - - NIS' ability to create netgroups from other netgroups can - be used to prevent situations like these. One possibility is + 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 BIGSRV to define the login restrictions for the important servers, another netgroup called SMALLSRV for the less - important servers and a third netgroup called - USERBOX for the normal workstations. Each + important servers, and a third netgroup called + USERBOX for the workstations. Each of these netgroups contains the netgroups that are allowed to login onto these machines. The new entries for the - NIS map netgroup should look like + NIS netgroup map would look like this: BIGSRV IT_EMP IT_APP @@ -2168,16 +2141,15 @@ USERBOX IT_EMP ITINTERN USERS - Machine-specific netgroup definitions are the other - possibility to deal with the policy change outlined above. In + Machine-specific netgroup definitions are another + possibility to deal with the policy changes. In this scenario, the /etc/master.passwd 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 + each system contains two lines starting with +. + The first line adds a netgroup with the accounts allowed to + login onto this machine and the second line adds all other accounts with /sbin/nologin 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: + is recommended to use the ALL-CAPS version of + the hostname as the name of the netgroup: +@BOXNAME::::::::: +:::::::::/sbin/nologin @@ -2187,8 +2159,7 @@ USERBOX IT_EMP ITINTERN USERS/etc/master.passwd 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: + netgroup map for this scenario: # 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] - 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. - - One last word of caution: It may not always be advisable + 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 NIS map within reasonable limits. - Important Things to Remember - - There are still a couple of things administrators need to - do differently now that machines are in an NIS - environment. - - - - Every time a new user is added to the lab, they must - be added to the master NIS server and - the NIS maps will need rebuilt. If - this step is omitted, 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: - - &prompt.root; pw useradd jsmith -&prompt.root; cd /var/yp -&prompt.root; make test-domain - - The user may also be added using - adduser jsmith - instead of pw useradd jsmith. - - - - Keep the administration accounts out of the - NIS maps. 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. - - - - Keep the NIS master and - slave secure, and minimize their downtime. - If somebody either hacks or simply turns off these - machines, they have effectively rendered many people - without the ability to login to the lab. - - This is the chief weakness of any centralized - administration system. If the NIS - servers are not protected, there will be a lot of angry - users and unhappy management! - - - - - - <acronym>NIS</acronym> v1 Compatibility - - &os;'s ypserv has some support - for serving NIS v1 clients. &os;'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 - ypbind daemons supplied with these - systems will attempt to establish a binding to an - NISv1 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. Additionally, 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. - - - Password Formats NIS password formats - One of the most common issues that people run into when - trying to implement NIS is password format - compatibility. If the NIS server is using - DES encrypted passwords, it will only support clients that are - also using DES. For example, if any &solaris; - NIS clients exist on the network, there is - a highly likelihood DES must be used for encrypted - passwords. - - To check which format the servers and clients are using, - look at /etc/login.conf. If the host is - configured to use DES encrypted passwords, then the - default class will contain an entry like - this: + NIS requires that all hosts within an + NIS domain use the same format for encrypting passwords. + If users have trouble authenticating on an + NIS client, it may be due to a differing password format. + In a heterogeneous network, the format must be supported by all operating systems, where + DES + is the lowest common standard. + + To check which format a server or client is using, + look at this section of /etc/login.conf: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Further entries elided] - Other possible values for the - passwd_format capability include - blf and md5 (for - Blowfish and MD5 encrypted passwords, respectively). - - If any changes were made to - /etc/login.conf, the login capability - database must be rebuilt by running the following command as - root: + In this example, the system is using the DES + format. Other possible values are + blf for Blowfish and md5 for + MD5 encrypted passwords. + + If the format on a host needs to be edited to match the one + being used in the NIS domain, + the login capability + database must be rebuilt after saving the change: &prompt.root; cap_mkdb /etc/login.conf - The format of passwords already in - /etc/master.passwd will not be updated - until a user changes his password for the first time + The format of passwords for existing user accounts will not be updated + until each user changes their password after the login capability database is rebuilt. - - Next, in order to ensure that passwords are encrypted with - the chosen format, check that the - crypt_default in - /etc/auth.conf 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: - - crypt_default = des blf md5 - - Having followed the above steps on each of the &os; based - NIS servers and clients, verify that they - all agree on which password format is used within the network. - If users have trouble authenticating on an - NIS client, this is a pretty good place to - start looking for possible problems. Remember: to deploy an - NIS server for a heterogeneous network, - they will probably have to use DES on all systems because it - is the lowest common standard.