Put in remaining pages and wiki contents.
[ikiwiki.git] / docs / handbook / handbook-network-nis.mdwn
1 \r
2 \r
3 ## 19.9 NIS/YP \r
4 \r
5 ***Written by Bill Swingle. ******Enhanced by Eric Ogren and Udo Erdelhoff. ***\r
6 \r
7 ### 19.9.1 What Is It? \r
8 \r
9 NIS, which stands for Network Information Services, was developed by Sun Microsystems to centralize administration of UNIX® (originally SunOS™) systems. It has now essentially become an industry standard; all major UNIX like systems (Solaris™, HP-UX, AIX®, Linux, NetBSD, OpenBSD, FreeBSD, DragonFly, etc.) support NIS.\r
10 \r
11 NIS was formerly known as Yellow Pages, but because of trademark issues, Sun changed the name. The old term (and yp) is still often seen and used.\r
12 \r
13 It is a RPC-based client/server system that allows a group of machines within an NIS domain to share a common set of configuration files. This permits a system administrator to set up NIS client systems with only minimal configuration data and add, remove or modify configuration data from a single location.\r
14 \r
15 It is similar to the Windows NT® domain system; although the internal implementation of the two are not at all similar, the basic functionality can be compared.\r
16 \r
17 ### 19.9.2 Terms/Processes You Should Know \r
18 \r
19 There are several terms and several important user processes that you will come across when attempting to implement NIS on DragonFly, whether you are trying to create an NIS server or act as an NIS client:\r
20 \r
21 [[!table  data="""
22 | Term | Description 
23  NIS domainname | An NIS master server and all of its clients (including its slave servers) have a NIS domainname. Similar to an Windows NT domain name, the NIS domainname does not have anything to do with DNS. 
24  portmap | Must be running in order to enable RPC (Remote Procedure Call, a network protocol used by NIS). If `portmap` is not running, it will be impossible to run an NIS server, or to act as an NIS client. 
25  ypbind | ***Binds*** an NIS client to its NIS server. It will take the NIS domainname from the system, and using RPC, connect to the server. `ypbind` is the core of client-server communication in an NIS environment; if `ypbind` dies on a client machine, it will not be able to access the NIS server. 
26  ypserv | Should only be running on NIS servers; this is the NIS server process itself. If [ypserv(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ypserv&section8) dies, then the server will no longer be able to respond to NIS requests (hopefully, there is a slave server to take over for it). There are some implementations of NIS (but not the DragonFly one), that do not try to reconnect to another server if the server it used before dies. Often, the only thing that helps in this case is to restart the server process (or even the whole server) or the `ypbind` process on the client. 
27  rpc.yppasswdd | Another process that should only be running on NIS master servers; this is a daemon that will allow NIS clients to change their NIS passwords. If this daemon is not running, users will have to login to the NIS master server and change their passwords there. |\r
28 """]]\r
29 ### 19.9.3 How Does It Work? \r
30 \r
31 There are three types of hosts in an NIS environment: master servers, slave servers, and clients. Servers act as a central repository for host configuration information. Master servers hold the authoritative copy of this information, while slave servers mirror this information for redundancy. Clients rely on the servers to provide this information to them.\r
32 \r
33 Information in many files can be shared in this manner. The `master.passwd`, `group`, and `hosts` files are commonly shared via NIS. Whenever a process on a client needs information that would normally be found in these files locally, it makes a query to the NIS server that it is bound to instead.\r
34 \r
35 #### 19.9.3.1 Machine Types \r
36 \r
37
38 * A ***NIS master server***. This server, analogous to a Windows NT primary domain controller, maintains the files used by all of the NIS clients. The `passwd`, `group`, and other various files used by the NIS clients live on the master server.\r
39    **Note:** It is possible for one machine to be an NIS master server for more than one NIS domain. However, this will not be covered in this introduction, which assumes a relatively small-scale NIS environment.\r
40
41 * ***NIS slave servers***. Similar to the Windows NT backup domain controllers, NIS slave servers maintain copies of the NIS master's data files. NIS slave servers provide the redundancy, which is needed in important environments. They also help to balance the load of the master server: NIS Clients always attach to the NIS server whose response they get first, and this includes slave-server-replies.\r
42
43 * ***NIS clients***. NIS clients, like most Windows NT workstations, authenticate against the NIS server (or the Windows NT domain controller in the Windows NT Workstation case) to log on.\r
44 \r
45 ### 19.9.4 Using NIS/YP \r
46 \r
47 This section will deal with setting up a sample NIS environment.\r
48 \r
49 #### 19.9.4.1 Planning \r
50 \r
51 Let us assume that you are the administrator of a small university lab. This lab, which consists of 15 DragonFly machines, currently has no centralized point of administration; each machine has its own `/etc/passwd` and `/etc/master.passwd`. These files are kept in sync with each other only through manual intervention; currently, when you add a user to the lab, you must run `adduser` on all 15 machines. Clearly, this has to change, so you have decided to convert the lab to use NIS, using two of the machines as servers.\r
52 \r
53 Therefore, the configuration of the lab now looks something like:\r
54 \r
55 [[!table  data="""
56 | Machine name | IP address | Machine role 
57  `ellington` | `10.0.0.2` | NIS master 
58  `coltrane` | `10.0.0.3` | NIS slave 
59  `basie` | `10.0.0.4` | Faculty workstation 
60  `bird` | `10.0.0.5` | Client machine 
61  `cli[1-11]` | `10.0.0.[6-17]` | Other client machines |\r
62 """]]\r
63 If you are setting up a NIS scheme for the first time, it is a good idea to think through how you want to go about it. No matter what the size of your network, there are a few decisions that need to be made.\r
64 \r
65 ##### 19.9.4.1.1 Choosing a NIS Domain Name \r
66 \r
67 This might not be the ***domainname*** that you are used to. It is more accurately called the ***NIS domainname***. When a client broadcasts its requests for info, it includes the name of the NIS domain that it is part of. This is how multiple servers on one network can tell which server should answer which request. Think of the NIS domainname as the name for a group of hosts that are related in some way.\r
68 \r
69 Some organizations choose to use their Internet domainname for their NIS domainname. This is not recommended as it can cause confusion when trying to debug network problems. The NIS domainname should be unique within your network and it is helpful if it describes the group of machines it represents. For example, the Art department at Acme Inc. might be in the ***acme-art*** NIS domain. For this example, assume you have chosen the name ***test-domain***.\r
70 \r
71 However, some operating systems (notably SunOS) use their NIS domain name as their Internet domain name. If one or more machines on your network have this restriction, you ***must*** use the Internet domain name as your NIS domain name.\r
72 \r
73 ##### 19.9.4.1.2 Physical Server Requirements \r
74 \r
75 There are several things to keep in mind when choosing a machine to use as a NIS server. One of the unfortunate things about NIS is the level of dependency the clients have on the server. If a client cannot contact the server for its NIS domain, very often the machine becomes unusable. The lack of user and group information causes most systems to temporarily freeze up. With this in mind you should make sure to choose a machine that will not be prone to being rebooted regularly, or one that might be used for development. The NIS server should ideally be a stand alone machine whose sole purpose in life is to be an NIS server. If you have a network that is not very heavily used, it is acceptable to put the NIS server on a machine running other services, just keep in mind that if the NIS server becomes unavailable, it will affect ***all*** of your NIS clients adversely.\r
76 \r
77 #### 19.9.4.2 NIS Servers \r
78 \r
79 The canonical copies of all NIS information are stored on a single machine called the NIS master server. The databases used to store the information are called NIS maps. In DragonFly, these maps are stored in `/var/yp/[domainname]` where `[domainname]` is the name of the NIS domain being served. A single NIS server can support several domains at once, therefore it is possible to have several such directories, one for each supported domain. Each domain will have its own independent set of maps.\r
80 \r
81 NIS master and slave servers handle all NIS requests with the `ypserv` daemon. `ypserv` is responsible for receiving incoming requests from NIS clients, translating the requested domain and map name to a path to the corresponding database file and transmitting data from the database back to the client.\r
82 \r
83 ##### 19.9.4.2.1 Setting Up a NIS Master Server \r
84 \r
85 Setting up a master NIS server can be relatively straight forward, depending on your needs. DragonFly comes with support for NIS out-of-the-box. All you need is to add the following lines to `/etc/rc.conf`, and DragonFly will do the rest for you.\r
86 \r
87       1. \r
88       nisdomainname="test-domain"\r
89   \r
90    This line will set the NIS domainname to ***test-domain*** upon network setup (e.g. after reboot).\r
91       1. \r
92       nis_server_enable="YES"\r
93   \r
94    This will tell DragonFly to start up the NIS server processes when the networking is next brought up.\r
95       1. \r
96       nis_yppasswdd_enable="YES"\r
97   \r
98    This will enable the `rpc.yppasswdd` daemon which, as mentioned above, will allow users to change their NIS password from a client machine.\r
99 \r
100  **Note:** Depending on your NIS setup, you may need to add further entries. See the [network-nis.html#NETWORK-NIS-SERVER-IS-CLIENT section about NIS servers that are also NIS clients], below, for details.\r
101 \r
102 Now, all you have to do is to run the command `/etc/netstart` as superuser. It will set up everything for you, using the values you defined in `/etc/rc.conf`.\r
103 \r
104 ##### 19.9.4.2.2 Initializing the NIS Maps \r
105 \r
106 The ***NIS maps*** are database files, that are kept in the `/var/yp` directory. They are generated from configuration files in the `/etc` directory of the NIS master, with one exception: the `/etc/master.passwd` file. This is for a good reason; you do not want to propagate passwords to your `root` and other administrative accounts to all the servers in the NIS domain. Therefore, before we initialize the NIS maps, you should:\r
107 \r
108     \r
109     # cp /etc/master.passwd /var/yp/master.passwd\r
110     # cd /var/yp\r
111     # vi master.passwd\r
112 \r
113 \r
114 You should remove all entries regarding system accounts (`bin`, `tty`, `kmem`, `games`, etc), as well as any accounts that you do not want to be propagated to the NIS clients (for example `root` and any other UID 0 (superuser) accounts).\r
115 \r
116  **Note:** Make sure the `/var/yp/master.passwd` is neither group nor world readable (mode 600)! Use the `chmod` command, if appropriate.\r
117 \r
118 When you have finished, it is time to initialize the NIS maps! DragonFly includes a script named `ypinit` to do this for you (see its manual page for more information). Note that this script is available on most UNIX Operating Systems, but not on all. On Digital UNIX/Compaq Tru64 UNIX it is called `ypsetup`. Because we are generating maps for an NIS master, we are going to pass the `-m` option to `ypinit`. To generate the NIS maps, assuming you already performed the steps above, run:\r
119 \r
120     \r
121     ellington# ypinit -m test-domain\r
122     Server Type: MASTER Domain: test-domain\r
123     Creating an YP server will require that you answer a few questions.\r
124     Questions will all be asked at the beginning of the procedure.\r
125     Do you want this procedure to quit on non-fatal errors? [y/n: n] n\r
126     Ok, please remember to go back and redo manually whatever fails.\r
127     If you don't, something might not work.\r
128     At this point, we have to construct a list of this domains YP servers.\r
129     rod.darktech.org is already known as master server.\r
130     Please continue to add any slave servers, one per line. When you are\r
131     done with the list, type a <control D>.\r
132     master server   :  ellington\r
133     next host to add:  coltrane\r
134     next host to add:  ^D\r
135     The current list of NIS servers looks like this:\r
136     ellington\r
137     coltrane\r
138     Is this correct?  [y/n: y] y\r
139     \r
140     [..output from map generation..]\r
141     \r
142     NIS Map update completed.\r
143     ellington has been setup as an YP master server without any errors.\r
144 \r
145 \r
146 `ypinit` should have created `/var/yp/Makefile` from `/var/yp/Makefile.dist`. When created, this file assumes that you are operating in a single server NIS environment with only DragonFly machines. Since ***test-domain*** has a slave server as well, you must edit `/var/yp/Makefile`:\r
147 \r
148     \r
149     ellington# vi /var/yp/Makefile\r
150 \r
151 \r
152 You should comment out the line that says\r
153 \r
154     \r
155     NOPUSH = "True"\r
156 \r
157 \r
158 (if it is not commented out already).\r
159 \r
160 ##### 19.9.4.2.3 Setting up a NIS Slave Server \r
161 \r
162 Setting up an NIS slave server is even more simple than setting up the master. Log on to the slave server and edit the file `/etc/rc.conf` as you did before. The only difference is that we now must use the `-s` option when running `ypinit`. The `-s` option requires the name of the NIS master be passed to it as well, so our command line looks like:\r
163 \r
164     \r
165     coltrane# ypinit -s ellington test-domain\r
166     \r
167     Server Type: SLAVE Domain: test-domain Master: ellington\r
168     \r
169     Creating an YP server will require that you answer a few questions.\r
170     Questions will all be asked at the beginning of the procedure.\r
171     \r
172     Do you want this procedure to quit on non-fatal errors? [y/n: n]  n\r
173     \r
174     Ok, please remember to go back and redo manually whatever fails.\r
175     If you don't, something might not work.\r
176     There will be no further questions. The remainder of the procedure\r
177     should take a few minutes, to copy the databases from ellington.\r
178     Transferring netgroup...\r
179     ypxfr: Exiting: Map successfully transferred\r
180     Transferring netgroup.byuser...\r
181     ypxfr: Exiting: Map successfully transferred\r
182     Transferring netgroup.byhost...\r
183     ypxfr: Exiting: Map successfully transferred\r
184     Transferring master.passwd.byuid...\r
185     ypxfr: Exiting: Map successfully transferred\r
186     Transferring passwd.byuid...\r
187     ypxfr: Exiting: Map successfully transferred\r
188     Transferring passwd.byname...\r
189     ypxfr: Exiting: Map successfully transferred\r
190     Transferring group.bygid...\r
191     ypxfr: Exiting: Map successfully transferred\r
192     Transferring group.byname...\r
193     ypxfr: Exiting: Map successfully transferred\r
194     Transferring services.byname...\r
195     ypxfr: Exiting: Map successfully transferred\r
196     Transferring rpc.bynumber...\r
197     ypxfr: Exiting: Map successfully transferred\r
198     Transferring rpc.byname...\r
199     ypxfr: Exiting: Map successfully transferred\r
200     Transferring protocols.byname...\r
201     ypxfr: Exiting: Map successfully transferred\r
202     Transferring master.passwd.byname...\r
203     ypxfr: Exiting: Map successfully transferred\r
204     Transferring networks.byname...\r
205     ypxfr: Exiting: Map successfully transferred\r
206     Transferring networks.byaddr...\r
207     ypxfr: Exiting: Map successfully transferred\r
208     Transferring netid.byname...\r
209     ypxfr: Exiting: Map successfully transferred\r
210     Transferring hosts.byaddr...\r
211     ypxfr: Exiting: Map successfully transferred\r
212     Transferring protocols.bynumber...\r
213     ypxfr: Exiting: Map successfully transferred\r
214     Transferring ypservers...\r
215     ypxfr: Exiting: Map successfully transferred\r
216     Transferring hosts.byname...\r
217     ypxfr: Exiting: Map successfully transferred\r
218     \r
219     coltrane has been setup as an YP slave server without any errors.\r
220     Don't forget to update map ypservers on ellington.\r
221 \r
222 \r
223 You should now have a directory called `/var/yp/test-domain`. Copies of the NIS master server's maps should be in this directory. You will need to make sure that these stay updated. The following `/etc/crontab` entries on your slave servers should do the job:\r
224 \r
225     \r
226     20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname\r
227     21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid\r
228 \r
229 \r
230 These two lines force the slave to sync its maps with the maps on the master server. Although these entries are not mandatory, since the master server attempts to ensure any changes to its NIS maps are communicated to its slaves and because password information is vital to systems depending on the server, it is a good idea to force the updates. This is more important on busy networks where map updates might not always complete.\r
231 \r
232 Now, run the command `/etc/netstart` on the slave server as well, which again starts the NIS server.\r
233 \r
234 #### 19.9.4.3 NIS Clients \r
235 \r
236 An NIS client establishes what is called a binding to a particular NIS server using the `ypbind` daemon. `ypbind` 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 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 and begin broadcasting again in the hopes of locating another server.\r
237 \r
238 ##### 19.9.4.3.1 Setting Up a NIS Client \r
239 \r
240 Setting up a DragonFly machine to be a NIS client is fairly straightforward.\r
241 \r
242   1. Edit the file `/etc/rc.conf` and add the following lines in order to set the NIS domainname and start `ypbind` upon network startup:\r
243       \r
244       nisdomainname="test-domain"\r
245       nis_client_enable="YES"\r
246   \r
247   1. To import all possible password entries from the NIS server, remove all user accounts from your `/etc/master.passwd` file and use `vipw` to add the following line to the end of the file:\r
248       \r
249       +:::::::::\r
250   \r
251    **Note:** This line will afford anyone with a valid account in the NIS server's password maps an account. There are many ways to configure your NIS client by changing this line. See the [network-nis.html#NETWORK-NETGROUPS netgroups section] below for more information. For more detailed reading see O'Reilly's book on `Managing NFS and NIS`.\r
252    **Note:** You should keep at least one local account (i.e. not imported via NIS) in your `/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.\r
253   1. To import all possible group entries from the NIS server, add this line to your `/etc/group` file:\r
254       \r
255       +:*::\r
256   \r
257 \r
258 After completing these steps, you should be able to run `ypcat passwd` and see the NIS server's passwd map.\r
259 \r
260 ### 19.9.5 NIS Security \r
261 \r
262 In general, any remote user can issue an RPC to [ypserv(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ypserv&section8) and retrieve the contents of your NIS maps, provided the remote user knows your domainname. To prevent such unauthorized transactions, [ypserv(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=ypserv&section=8) supports a feature called securenets which can be used to restrict access to a given set of hosts. At startup, [ypserv(8)](http://leaf.dragonflybsd.org/cgi/web-man?command=ypserv&section=8) will attempt to load the securenets information from a file called `/var/yp/securenets`.\r
263 \r
264  **Note:** This path varies depending on the path specified with the `-p` 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:\r
265 \r
266     \r
267     # allow connections from local host -- mandatory\r
268     127.0.0.1     255.255.255.255\r
269     # allow connections from any host\r
270     # on the 192.168.128.0 network\r
271     192.168.128.0 255.255.255.0\r
272     # allow connections from any host\r
273     # between 10.0.0.0 to 10.0.15.255\r
274     # this includes the machines in the testlab\r
275     10.0.0.0      255.255.240.0\r
276 \r
277 \r
278 If [ypserv(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ypserv&section8) 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 `/var/yp/securenets` file does not exist, `ypserv` will allow connections from any host.\r
279 \r
280 The `ypserv` program also has support for Wietse Venema's  **tcpwrapper**  package. This allows the administrator to use the  **tcpwrapper**  configuration files for access control instead of `/var/yp/securenets`.\r
281 \r
282  **Note:** 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.\r
283 \r
284 Servers using `/var/yp/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 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`.\r
285 \r
286 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 your network.\r
287 \r
288 The use of the  **tcpwrapper**  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.\r
289 \r
290 ### 19.9.6 Barring Some Users from Logging On \r
291 \r
292 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 NIS server contains accounts for both faculty and students. What can we do?\r
293 \r
294 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 ***-`***username***`*** to the end of the `/etc/master.passwd` file on the client machine, where `***username***` is the username of the user you wish to bar from logging in. This should preferably be done using `vipw`, since `vipw` will sanity check your changes to `/etc/master.passwd`, as well as automatically rebuild the password database when you finish editing. For example, if we wanted to bar user ***bill*** from logging on to `basie` we would:\r
295 \r
296     \r
297     basie# vipw\r
298     [add -bill to the end, exit]\r
299     vipw: rebuilding the database...\r
300     vipw: done\r
301     \r
302     basie# cat /etc/master.passwd\r
303     \r
304     root:[password]:0:0::0:0:The super-user:/root:/bin/csh\r
305     toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh\r
306     daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin\r
307     operator:*:2:5::0:0:System &:/:/sbin/nologin\r
308     bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin\r
309     tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin\r
310     kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin\r
311     games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin\r
312     news:*:8:8::0:0:News Subsystem:/:/sbin/nologin\r
313     man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin\r
314     bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin\r
315     uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico\r
316     xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin\r
317     pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin\r
318     nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin\r
319     +:::::::::\r
320     -bill\r
321     \r
322     basie#\r
323 \r
324 \r
325 ### 19.9.7 Using Netgroups \r
326 \r
327 ***Contributed by Udo Erdelhoff. ***\r
328 \r
329 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 ***will*** 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, ***centralized*** administration.\r
330 \r
331 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 lack of a numeric id and the ability to define a netgroup by including both user accounts and other netgroups.\r
332 \r
333 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.\r
334 \r
335 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.\r
336 \r
337 [[!table  data="""
338 | User Name(s) | Description 
339  alpha, beta | Normal employees of the IT department 
340  charlie, delta | The new apprentices of the IT department 
341  echo, foxtrott, golf, ... | Ordinary employees 
342  able, baker, ... | The current interns |\r
343 """]]\r
344 [[!table  data="""
345 | Machine Name(s) | Description 
346  war, death, famine, pollution | Your most important servers. Only the IT employees are allowed to log onto these machines. 
347  pride, greed, envy, wrath, lust, sloth | Less important servers. All members of the IT department are allowed to login onto these machines. 
348  one, two, three, four, ... | Ordinary workstations. Only the ***real*** employees are allowed to use these machines. 
349  trashcan | A very old machine without any critical data. Even the intern is allowed to use this box. |\r
350 """]]\r
351 If you tried to implement these restrictions by separately blocking each user, you would have to add one -`***user***` line to each system's `passwd` 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 ***will*** eventually forget to add the lines for new users during day-to-day operations. After all, Murphy was an optimist.\r
352 \r
353 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.\r
354 \r
355 The first step is the initialization of the NIS map netgroup. DragonFly's [ypinit(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ypinit&section8) 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\r
356 \r
357     \r
358     ellington# vi /var/yp/netgroup\r
359 \r
360 \r
361 and start adding content. For our example, we need at least four netgroups: IT employees, IT apprentices, normal employees and interns.\r
362 \r
363     \r
364     IT_EMP  (,alpha,test-domain)    (,beta,test-domain)\r
365     IT_APP  (,charlie,test-domain)  (,delta,test-domain)\r
366     USERS   (,echo,test-domain)     (,foxtrott,test-domain) \\r
367             (,golf,test-domain)\r
368     INTERNS (,able,test-domain)     (,baker,test-domain)\r
369 \r
370 \r
371 `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:\r
372 \r
373   1. 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.\r
374   1. The name of the account that belongs to this netgroup.\r
375   1. 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.\r
376 \r
377 Each of these fields can contain wildcards. See [netgroup(5)](http://leaf.dragonflybsd.org/cgi/web-man?command#netgroup&section5) for details.\r
378 \r
379  **Note:** 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.\r
380 \r
381 Some NIS clients (other than DragonFly) 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***. 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:\r
382 \r
383     \r
384     BIGGRP1  (,joe1,domain)  (,joe2,domain)  (,joe3,domain) [...]\r
385     BIGGRP2  (,joe16,domain)  (,joe17,domain) [...]\r
386     BIGGRP3  (,joe31,domain)  (,joe32,domain)\r
387     BIGGROUP  BIGGRP1 BIGGRP2 BIGGRP3\r
388 \r
389 \r
390 You can repeat this process if you need more than 225 users within a single netgroup.\r
391 \r
392 Activating and distributing your new NIS map is easy:\r
393 \r
394     \r
395     ellington# cd /var/yp\r
396     ellington# make\r
397 \r
398 \r
399 This will generate the three NIS maps `netgroup`, `netgroup.byhost` and `netgroup.byuser`. Use [ypcat(1)](http://leaf.dragonflybsd.org/cgi/web-man?command#ypcat&section1) to check if your new NIS maps are available:\r
400 \r
401     \r
402     ellington% ypcat -k netgroup\r
403     ellington% ypcat -k netgroup.byhost\r
404     ellington% ypcat -k netgroup.byuser\r
405 \r
406 \r
407 The output of the first command should resemble the contents of `/var/yp/netgroup`. 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.\r
408 \r
409 The client setup is quite simple. To configure the server `***war***`, you only have to start [vipw(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#vipw&section8) and replace the line\r
410 \r
411     \r
412     +:::::::::\r
413 \r
414 \r
415 with\r
416 \r
417     \r
418     +@IT_EMP:::::::::\r
419 \r
420 \r
421 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.\r
422 \r
423 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, `cd ~`***user****** will not work, `ls -l` will show the numerical id instead of the username and `find . -user joe -print` will fail with ***`No such user`***. To fix this, you will have to import all user entries ***without allowing them to login onto your servers***.\r
424 \r
425 This can be achieved by adding another line to `/etc/master.passwd`. This line should contain:\r
426 \r
427 `+:::::::::/sbin/nologin`, meaning ***Import all entries but replace the shell with `/sbin/nologin` in the imported entries***. You can replace any field in the passwd entry by placing a default value in your `/etc/master.passwd`.\r
428 \r
429  **Warning:** Make sure that the line `+:::::::::/sbin/nologin` is placed after `+@IT_EMP:::::::::`. Otherwise, all user accounts imported from NIS will have /sbin/nologin as their login shell.\r
430 \r
431 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 `+:::::::::` in their local version of `/etc/master.passwd` with something like this:\r
432 \r
433     \r
434     +@IT_EMP:::::::::\r
435     +@IT_APP:::::::::\r
436     +:::::::::/sbin/nologin\r
437 \r
438 \r
439 The corresponding lines for the normal workstations could be:\r
440 \r
441     \r
442     +@IT_EMP:::::::::\r
443     +@USERS:::::::::\r
444     +:::::::::/sbin/nologin\r
445 \r
446 \r
447 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***.\r
448 \r
449 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 `***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 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:\r
450 \r
451     \r
452     BIGSRV    IT_EMP  IT_APP\r
453     SMALLSRV  IT_EMP  IT_APP  ITINTERN\r
454     USERBOX   IT_EMP  ITINTERN USERS\r
455 \r
456 \r
457 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.\r
458 \r
459 Machine-specific netgroup definitions are the other possibility to deal with the policy change outlined above. 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 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:\r
460 \r
461     \r
462     +@`***BOXNAME***`:::::::::\r
463     +:::::::::/sbin/nologin\r
464 \r
465 \r
466 Once you have completed this task for all your machines, you will not have to modify the local versions of `/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.\r
467 \r
468     \r
469     # Define groups of users first\r
470     IT_EMP    (,alpha,test-domain)    (,beta,test-domain)\r
471     IT_APP    (,charlie,test-domain)  (,delta,test-domain)\r
472     DEPT1     (,echo,test-domain)     (,foxtrott,test-domain)\r
473     DEPT2     (,golf,test-domain)     (,hotel,test-domain)\r
474     DEPT3     (,india,test-domain)    (,juliet,test-domain)\r
475     ITINTERN  (,kilo,test-domain)     (,lima,test-domain)\r
476     D_INTERNS (,able,test-domain)     (,baker,test-domain)\r
477     #\r
478     # Now, define some groups based on roles\r
479     USERS     DEPT1   DEPT2     DEPT3\r
480     BIGSRV    IT_EMP  IT_APP\r
481     SMALLSRV  IT_EMP  IT_APP    ITINTERN\r
482     USERBOX   IT_EMP  ITINTERN  USERS\r
483     #\r
484     # And a groups for a special tasks\r
485     # Allow echo and golf to access our anti-virus-machine\r
486     SECURITY  IT_EMP  (,echo,test-domain)  (,golf,test-domain)\r
487     #\r
488     # machine-based netgroups\r
489     # Our main servers\r
490     WAR       BIGSRV\r
491     FAMINE    BIGSRV\r
492     # User india needs access to this server\r
493     POLLUTION  BIGSRV  (,india,test-domain)\r
494     #\r
495     # This one is really important and needs more access restrictions\r
496     DEATH     IT_EMP\r
497     #\r
498     # The anti-virus-machine mentioned above\r
499     ONE       SECURITY\r
500     #\r
501     # Restrict a machine to a single user\r
502     TWO       (,hotel,test-domain)\r
503     # [...more groups to follow]\r
504 \r
505 \r
506 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.\r
507 \r
508 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.\r
509 \r
510 ### 19.9.8 Important Things to Remember \r
511 \r
512 There are still a couple of things that you will need to do differently now that you are in an NIS environment.\r
513 \r
514
515 * Every time you wish to add a user to the lab, you must add it to the master NIS server ***only***, and ***you must remember to rebuild the NIS maps***. 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:\r
516       \r
517       # pw useradd jsmith\r
518       # cd /var/yp\r
519       # make test-domain\r
520   \r
521   You could also run `adduser jsmith` instead of `pw useradd jsmith`.\r
522
523 * ***Keep the administration accounts out of the NIS maps***. 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.\r
524
525 * ***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.\r
526   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!\r
527 \r
528 ### 19.9.9 NIS v1 Compatibility \r
529 \r
530 DragonFly's  **ypserv**  has some support for serving NIS v1 clients. DragonFly'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 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.\r
531 \r
532 ### 19.9.10 NIS Servers That Are Also NIS Clients \r
533 \r
534 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.\r
535 \r
536 You can force a host to bind to a particular server by running `ypbind` with the `-S` 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 `/etc/rc.conf`:\r
537 \r
538     \r
539     nis_client_enable="YES"     # run client stuff as well\r
540     nis_client_flags="-S `***NIS domain***`,`***server***`"\r
541 \r
542 \r
543 See [ypbind(8)](http://leaf.dragonflybsd.org/cgi/web-man?command#ypbind&section8) for further information.\r
544 \r
545 ### 19.9.11 Password Formats \r
546 \r
547 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 Solaris NIS clients in your network, then you will almost certainly need to use DES encrypted passwords.\r
548 \r
549 To check which format your 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:\r
550 \r
551     \r
552     default:\\r
553         :passwd_format=des:\\r
554         :copyright=/etc/COPYRIGHT:\\r
555         [Further entries elided]\r
556 \r
557 \r
558 Other possible values for the `passwd_format` capability include `blf` and `md5` (for Blowfish and MD5 encrypted passwords, respectively).\r
559 \r
560 If you have made changes to `/etc/login.conf`, you will also need to rebuild the login capability database, which is achieved by running the following command as `root`:\r
561 \r
562     \r
563     # cap_mkdb /etc/login.conf\r
564 \r
565 \r
566  **Note:** The format of passwords already in `/etc/master.passwd` will not be updated until a user changes their password for the first time ***after*** the login capability database is rebuilt.\r
567 \r
568 Next, in order to ensure that passwords are encrypted with the format that you have chosen, you should also check that the `crypt_default` in `/etc/auth.conf` 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:\r
569 \r
570     \r
571     crypt_default       =       des blf md5\r
572 \r
573 \r
574 Having followed the above steps on each of the DragonFly 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.\r
575 \r
576 \r
577 \r
578 CategoryHandbook\r
579 CategoryHandbook-advancednetworking\r