From owner-freebsd-doc Wed May 31 17:50:24 2000 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id A748B37BF39 for ; Wed, 31 May 2000 17:50:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id RAA14356; Wed, 31 May 2000 17:50:01 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from eagle.prod.itd.earthlink.net (eagle.prod.itd.earthlink.net [207.217.120.24]) by hub.freebsd.org (Postfix) with ESMTP id B813737B93D for ; Wed, 31 May 2000 17:44:23 -0700 (PDT) (envelope-from eogren@earthlink.net) Received: from rod.darktech.org (ip54.cambridge2.ma.pub-ip.psi.net [38.32.112.54]) by eagle.prod.itd.earthlink.net (8.9.3/8.9.3) with ESMTP id RAA07040 for ; Wed, 31 May 2000 17:42:51 -0700 (PDT) Received: (from eogren@localhost) by rod.darktech.org (8.10.1/8.10.1) id e510iAx90594; Wed, 31 May 2000 20:44:10 -0400 (EDT) Message-Id: <200006010044.e510iAx90594@rod.darktech.org> Date: Wed, 31 May 2000 20:44:10 -0400 (EDT) From: eogren@earthlink.net Reply-To: eogren@earthlink.net To: FreeBSD-gnats-submit@freebsd.org X-Send-Pr-Version: 3.2 Subject: docs/18926: Article regarding setup of NIS Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Number: 18926 >Category: docs >Synopsis: Submission of NIS tutorial >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Wed May 31 17:50:01 PDT 2000 >Closed-Date: >Last-Modified: >Originator: Eric Ogren >Release: FreeBSD 4.0-STABLE i386 >Organization: >Environment: FreeBSD rod.darktech.org 4.0-STABLE FreeBSD 4.0-STABLE #1: Sun May 21 04:00:32 EDT 2000 eogren@rod.darktech.org:/usr/src/sys/compile/BLUE i386 >Description: Per a couple of requests on -doc, here's a tutorial on setting up an NIS master, slave, and clients. I just pretty much copied the Makefile from an already existing one; it seems to work as far as I can tell (I can make, make install, and make clean), but it may need tweaking; I'm not too sure how our doc build system works. >How-To-Repeat: n/a >How-To-Repeat: >Fix: Create doc/en_US.ISO_8859-1/articles/nis-guide, and extract the following (below the Makefile patch) shell archive into it. Also, apply the simple Makefile patch to doc/en_US.ISO_8859-1/articles/Makefile to put nis-guide in the build. (There may be other build-related changes that I missed, but I don't think so). Index: Makefile =================================================================== RCS file: /usr/local/doctree/doc/en_US.ISO_8859-1/articles/Makefile,v retrieving revision 1.6 diff -u -r1.6 Makefile --- Makefile 2000/02/14 01:25:14 1.6 +++ Makefile 2000/05/31 19:43:23 @@ -7,6 +7,7 @@ SUBDIR+= mh SUBDIR+= multi-os SUBDIR+= new-users +SUBDIR+= nis-guide SUBDIR+= programming-tools SUBDIR+= zip-drive # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # Makefile # article.sgml # echo x - Makefile sed 's/^X//' >Makefile << 'END-of-Makefile' X# $FreeBSD$ X XDOC?= article X XFORMATS?= html X XINSTALL_COMPRESSED?=gz XINSTALL_ONLY_COMPRESSED?= X XSRCS= article.sgml X XDOC_PREFIX?= ${.CURDIR}/../../.. X X.include "${DOC_PREFIX}/share/mk/doc.project.mk" END-of-Makefile echo x - article.sgml sed 's/^X//' >article.sgml << 'END-of-article.sgml' X X X X X X
X X Setting up NIS (yp) under FreeBSD X X X Eric X Ogren X X
eogren@earthlink.net
X X X X X 2000 X Eric Ogren X X X June 1, 2000 X X X NIS is the closest thing FreeBSD has to Windows NT's domain X system; it allows you to centralize username and passwords. This X document will tell you how to set up an NIS server, as well as an X NIS client on a FreeBSD system. X This article will make several analogies between NIS and NT's X domain system; although the internal implementation of the two X aren't at all similar, the basic functionality can be compared. X X X X X Introduction to NIS X X NIS, which stands for Network Information Services, was X developed by Sun Microsystems to centralize adminstration of Unix X (originally Solaris) systems. It has now essentially become an X industry standard; all major Unices (Solaris, HP-UX, AIX, Linux, X NetBSD, OpenBSD, FreeBSD, etc) support NIS, and it is really the best X way to centralize password and group files among Unix systems. X NIS was formerly known as Yellow Pages (or yp), but due to X copyright violations, Sun was forced to change the name. X X X X NIS architechture X X X Terms/processes you should know X X There are several terms and several important user processes X that you will come across when X attempting to implement NIS on FreeBSD, whether you are trying to X create an NIS server or act an NIS client: X X X X The NIS domainname. An NIS master X server and all of its clients (including its slave servers) have X an NIS domainname. Similar to an NT domain name, the NIS X domainname does not have anything to do with DNS. Indeed, your X NIS domainname should not be the same as X your DNS domainname; this is a security problem, and will also X make it more difficult to decipher logs if you have X problems. X X X portmap. portmap X must be running in order to enable RPC (Remote Procedure Call, a X network protocol used by NIS). If portmap is X not running, it will be impossible to run an NIS server, or to X act as an NIS client. X X X ypbind. ypbind X “binds” an NIS client to its master X server. It will take the NIS domainname from the system, and X using RPC, connect to the master. ypbind is the core of X client-server communication in an NIS environment; if X ypbind dies on a client machine, it will not X be able to access the NIS server. X X X ypserv. ypserv, X which should only be running on NIS servers, is the NIS server X process itself. If ypserv dies, then the server will no longer be X able to respond to NIS requests (hopefully, there is a slave X server to take over for it). X X X rpc.yppasswdd. X rpc.yppasswdd, another process that should X only be running on NIS servers, is a daemon that will allow NIS X clients to change their NIS passwords. If this daemon is not X running, users will have to login to the NIS master server and X change their passwords there. X X X X X X X NIS machine types X There are three major types of machines in an NIS X environment: X X X X An NIS master server. X This server, analogous to a Windows X NT primary domain controller, maintains the files used by all X of the NIS clients. The passwd, X group, and other various files used by the X NIS clients live on the master server. X It is possible for one machine to be an NIS X master server for more than one NIS domain. However, this will X not be covered in this article, which assumes a relatively X small-scale NIS environment. X X X NIS slave servers. X Similar to NT's backup domain X controllers, NIS slave servers maintain copies of the NIS X master's data files. The servers sit idle (except for receiving X updates from the master) until the master server crashes, at X which point they will begin answering requests. If you are in X an environment where it is critical that availability be X maintained, you will want to have at least one NIS slave X servers. X X X NIS clients. NIS clients, like most X NT workstations, authenticate against the NIS server (or the NT X domain controller in the NT Workstation case) to logon. X X X X X X X Setting up an NIS environment X X This section will deal with setting up a sample NIS X environment. X This section assumes that you are running FreeBSD 3.3 or X later. The instructions given here will probably X work for any version of FreeBSD greater than 3.0, but there are no X guarantees that this is true. X X Let's assume that you are the administrator of a small X university lab. This lab, which consists of 15 FreeBSD machines, X currently has no centralized point of administration; each machine X has its own /etc/passwd and X /etc/master.passwd. These files are kept in sync X with each other only through manual intervention; currently, when you X add a user to the lab, you must run adduser on all X 15 machines. Clearly, this has to change, so you have decided to X convert the lab to use NIS, sacrificing two of the machines to be X used as servers. X X Therefore, the configuration of the lab now looks something X like: X X X X X X Machine name X IP address X Machine role X X X X X X ellington X 10.0.0.2 X NIS master X X X X coltrane X 10.0.0.3 X NIS slave X X X X basie X 10.0.0.4 X Faculty workstation X X X X bird X 10.0.0.5 X Client machine X X X X cli[1-11] X 10.0.0.[6-17] X Other client machines (not used in this example) X X X X X X X X Setting up the NIS master X X X Modifying configuration files X X After determining which machine is going to be the NIS master, X the first thing you have to do is determine what your NIS domainname X is going to be. For this example, assume you have chosen the name X jazz-lab. X X Now that we know what the NIS domainname is going to be, we X can begin to set up the NIS master. The first thing to do is edit X /etc/rc.conf and add the following X lines: X X X X nisdomainname="jazz-lab". This line X will set the NIS domainname to jazz-lab upon X reboot. X X X nis_server_enable="YES". This will tell X FreeBSD to start up the NIS server processes when the system is X next brought up. X X X nis_yppasswdd_enable="YES". This will X enable the rpc.yppasswdd daemon, which, as X mentioned above, will allow users to change their NIS password X from a client machine. X X X X X X Initializing the NIS maps X X The NIS maps are database files generated X from configuration files in the /etc directory X of the NIS master, with one exception: the X /etc/master.passwd file. This is for a good X reason; you don't want to propogate passwords to your root and other X administrative accounts to all the servers in the NIS X domain. Therefore, before we initialize the NIS maps, you X should: X X &prompt.root; cp /etc/master.passwd /var/yp/master.passwd X &prompt.root; cd /var/yp X &prompt.root; vi master.passwd X X X You should remove all entries regarding system accounts (bin, X tty, kmem, games, etc), as well as any accounts that you don't want X to be propogated to the NIS clients (for example root and any other X UID 0 accounts). X When you have finished, it's time to initialize the NIS maps! X FreeBSD includes a script named ypinit to do this X for you (see its man page for more information). X Note that this script is not an X industry standard; other Unix OSs are not going to have X ypinit. Because we are generating maps for an NIS X master, we are going to pass the option to X ypinit. To generate the NIS maps, assuming you X already performed the steps above, run: X X Xellington&prompt.root; ypinit -m jazz-lab XServer Type: MASTER Domain: jazz-lab XCreating an YP server will require that you answer a few questions. XQuestions will all be asked at the beginning of the procedure. XDo you want this procedure to quit on non-fatal errors? [y/n: n] n XOk, please remember to go back and redo manually whatever fails. XIf you don't, something might not work. XAt this point, we have to construct a list of this domains YP servers. Xrod.darktech.org is already known as master server. XPlease continue to add any slave servers, one per line. When you are Xdone with the list, type a <control D>. X master server : ellington X next host to add: coltrane X next host to add: ^D XThe current list of NIS servers looks like this: Xellington Xcoltrane XIs this correct? [y/n: y] y X X[..output from map generation..] X XNIS Map update completed. Xellington has been setup as an YP master server without any errors. X X X You will probably see some errors similar to "Failed to send 'clear' to X local 'ypserv'". This is to be expected; you haven't yet started X your NIS server. X X X X Editing <filename>/var/yp/Makefile</filename> X X ypinit should have created X /var/yp/Makefile from X /var/yp/Makefile.dist. When created, this file X assumes that you are operating in a single server NIS environment X with only FreeBSD machines. Since jazz-lab has X a slave server as well, you must edit X /var/yp/Makefile: X X X ellington&prompt.root; vi /var/yp/Makefile X X X You should comment out the line that says `NOPUSH = X "True"'. Although not required in this sample environment, you may X also need to uncomment the `UNSECURE = "TRUE"' line in the X Makefile. X X X X Reboot X X After this, all you need to do is reboot. Although it is not X absolutely necessary to reboot to bring an NIS master online, it's X easier: all of the NIS daemons will be started automatically, X instead of you being required to do so by hand. So, we just need X to: X X X ellington&prompt.root; shutdown -r now X X X ..and we have finished configuring the NIS master! X X X X X Setting up the slave server X X Setting up a slave server is not much different from setting X up the NIS master. Logon to the slave server and edit the X /etc/rc.conf as you X did before. The only difference is that we now must use the X option when running X ypinit. The option requires X the name of the NIS master be passed to it as well, so our command X line looks like: X X X coltrane&prompt.root; ypinit -s ellington jazz-lab X X X Then reboot as before. X X X X Setting up the clients X X Setting up machines to act as NIS clients is not that X difficult, but it does require you to edit X /etc/master.passwd and X /etc/group. As always when editing important X system files, we strongly recommend that you take a backup before X you attempt to do this! X X X To enable a machine as an NIS client, the first thing you X must do is edit its X /etc/rc.conf file. Add the following X lines: X X X X nisdomainname="jazz-lab". As it does on X the NIS master and slaves, this tells FreeBSD to set the NIS X domainname to jazz-lab. X X X nis_client_enable="YES". This will X instruct FreeBSD to start ypbind upon X bootup. As explained above, ypbind is the X process used to communicate to the master NIS server. X X X X Next, we need to tell FreeBSD to import all user account and X group names from the NIS server: X X X someclient&prompt.root; echo +::::::::: >> /etc/master.passwd X someclient&prompt.root; echo +:*:: >> /etc/group X someclient&prompt.root; pwd_mkdb /etc/master.passwd X X X You can also use vipw to add the entry to X /etc/master.passwd, which means you will not X have to run pwd_mkdb. X X Reboot the client. Again, although you do not have to reboot X in order to enable NIS, this means you do not have to set the NIS X domainname or start the daemons manually. X X X X X Testing NIS X X Once you have setup your NIS servers and client, logon to one X of the client machines, and do: X X X someclient&prompt.user; ypcat passwd X X X If everything is configured correctly, you should be able to X see the master server's passwd file, with the X passwords asterisked out. If you run ypcat as X root, you should be able to see the (encrypted) passwords. X X The next task is to actually logon as someone only present in X the NIS database. In our test lab environment, using X vipw on the client, we would remove X a user account that is present both on the client and the NIS X master. We would then try to login as this user account. The client X should pull the user record from the NIS master, and the login should X be successful. X X If the first test worked, and this one doesn't, X make sure you put the correct entries in the client's X /etc/master.passwd file (make sure you count the X number of colons). X X X X Post-installation tasks X X After you have a working NIS installation, there are still a X couple more things you can do. This section will describe X them. X X X Making NIS a little more secure X X If you followed the steps above, anybody X who guesses your NIS domainname and who is running FreeBSD will be X able to access your NIS server and pull down its maps. If they have X root access on this machine, they, like any other of your client X machines, will be able to get the master's (slightly edited) X master.passwd file. This is obviously not X desirable. There is a file you can create to stop this from X happening, however: /var/yp/securenets. X X /var/yp/securenets is simply a file with X a list of IPs and netmasks that are allowed to access the NIS X server. If /var/yp/securenets is not present, X then anybody who wants to can access the server. In our environemnt, X /var/yp/securenets would probably look X something like: X X X# Allow localhost to connect. !!MANDATORY!! X127.0.0.1 255.255.255.255 X X# Machines in the testlab X10.0.0.2 255.255.255.0 X X X...assuming that the lab has 10.0.0.* to itself. If it doesn't, Xeach machine in the lab would be listed in Xsecurenets, with a netmask of 255.255.255.255. X X X Barring some users from logging on X X In our lab, there is a machine basie that is X supposed to be a faculty only workstation. We don't want to take this X machine out of the NIS domain, yet the passwd X file on the master NIS server contains accounts for both faculty and X students. What can we do? X X There is a way to bar specific users from logging on to a X machine, even if they are present in the NIS database. To do this, X all you must do is add X -username to the end of X the /etc/master.passwd file on the client X machine, where username is the username of X the user you wish to bar from logging in. This should preferably be X done using vipw, since vipw X will sanity check your changes to X /etc/master.passwd, as well as X automatically rebuild the password database when you X finish editing. For example, if we wanted to bar user X bill from logging on to basie X we would: X X X basie&prompt.root; vipw X [add -bill to the end, exit] X vipw: rebuilding the database... X vipw: done X X basie&prompt.root; cat /etc/master.passwd X Xroot:[password]:0:0::0:0:The super-user:/root:/bin/csh Xtoor:[password]:0:0::0:0:The other super-user:/root:/bin/sh Xdaemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin Xoperator:*:2:5::0:0:System &:/:/sbin/nologin Xbin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin Xtty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin Xkmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin Xgames:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin Xnews:*:8:8::0:0:News Subsystem:/:/sbin/nologin Xman:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin Xbind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin Xuucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico Xxten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin Xpop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin Xnobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin X+::::::::: X-bill X Xbasie&prompt.root; X X X X X X X Important things to remember X X There are still a couple of things that you will need to do X differently now that you are in an NIS environment. X X X Every time you wish to add a user to the lab, you X must add it to the master NIS server only, and X you must remember to rebuild the NIS maps. If X you forget to do this, the new user will not be able to login X anywhere except on the NIS master. For example, if we needed to add X a new user “jsmith” to the lab, we would: X X X &prompt.root; pw useradd jsmith X &prompt.root; cd /var/yp X &prompt.root; make jazz-lab X X X You could also run adduser jsmith instead X of pw useradd jsmith. X X X Keep the administration accounts out of the NIS X maps. You don't want to be propogating administrative X accounts and passwords to machines that will have users that X shouldn't have access to those accounts. X X X Keep the NIS master and slave X secure, and minimize their downtime. X If somebody either hacks or simply turns off X these machines, they have effectively rendered many people without X the ability to login to the lab. X This is the chief weakness of any centralized administration X system, and it is probably the most important weakness. If you do X not protect your NIS servers, you will have a lot of angry X users! X X X X X X
X END-of-article.sgml exit >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-doc" in the body of the message