| WIKI | FAQ | Tech FAQ | |
 http://csua.com/feed/ | |
| ||||||
| 11/23 |
| 2003/2/16-17 [Computer/SW/OS/OsX] UID:27431 Activity:kinda low |
2/15 I have three computers at home, all running some *nix (2 OS X + linux
if this matters). I would like them to have the same basic system
config. and user accounts for members of my family and friends. How
do I automate this? I know this is a very basic sys admin job but
I am just a home user and do want to spend too much time learning or
doing things to become a home sys admin of sort or buying extra
software.
\_ nis
\_ Is nis compatiable with the netinfo stuff in OS X?
\_ I'm not an apple maven but they claim it is.
\_ Depends on the version of OS X. 10.1 and earlier
included some NIS stuff that you could use to
some basic stuff running. 10.2 seems to have
removed/broken some of this stuff. For 10.2
you could use Kerberos or LDAP. Here are some
some (possibly) relevant/helpful URLs:
General OS X Auth:
http://clc.its.psu.edu/Labs/Mac/Help/authdoc
NIS and OS X:
http://www.bresink.de/osx/nis.html
LDAP and OS X:
http://www.usit.uio.no/it/mac/ldap/english/ldap.html
Kerberos and OS X:
http://www-personal.umich.edu/~arosenbl/kerb102.html
http://www.public.iastate.edu/~macosx/macosx.html
Note if you are unwilling to play around with this
stuff for a weekend or so, your best bet is to do
the following:
1. Create local users with the same username, password,
uid and gid on all of the machines. To make this
really easy, start on one of the MacOS X machines
and then create the users in the same order on the
other MacOS X machine (they should all end up with
the same uid/gid). Finally run adduser on your linux
box with the info from MacOS X.
2. Figure out which machine is going to serve the home
directories via NFS. The Linux machine is probably
going to be the easiest to configure as a NFS server.
3. Configure the other boxes as NFS clients.
Here is some info about MacOS X and NFS:
http://deaddog.duch.udel.edu/~frey/darwin/archive/DarwinAndNFS.pdf
\_ if what you say is true, then you don't want to spend anymore
time on trying to do this. Maybe you can do it for the Mac but
forget trying to have anything beyond the same local login/password
between Linux/OSX. Don't waste so much of your time.
\_ NFS mounts of home directories on OS X works
pretty well. So you could get the same files
on OS X and Linux.
\_ You are correct but miss the point. There is much
more involved. Long-term support and effort is an
issue, not whether NFS works. Think about the files
and also more thanthe files. |
| clc.its.psu.edu/Labs/Mac/Help/authdoc The page cannot be found The page you are looking for might have been removed, had its name changed, or is temporarily unavailable. Please try the following: * If you typed the page address in the Address bar, make sure that it is spelled correctly. |
| www.bresink.de/osx/nis.html Now Mac OS X freezes during startup waiting for the NIS server. As such, it can be integrated easily in a network of other Unix systems. In a computer network, the different machines have to share administrative data, like user names and access permissions. Mac OS X can use NeXT's NetInfo technology, or directory servers based on LDAP to distribute this information throughout the network. Those features are based on Apple's Open Directory architecture. Classic Unix networks however, mostly run the Network Information Service (NIS) to distribute that data. This document tries to answer questions about setting up NIS on a Mac OS X machine. This enables the machine to easily access files on Unix systems which are not using NetInfo or LDAP. For which versions of Mac OS X is this information valid? Disclaimer and Trademark Notice While reasonable efforts have been made in the preparation of this document to assure its accuracy, the author assumes no liability resulting from errors or omissions in this document, or from use of the information contained herein. Naming of particular products or brands should not be seen as endorsements. Trademarks or service marks are used for identification purposes only. Apple, Macintosh, NeXT, NEXTSTEP, OPENSTEP, and NetInfo are registered trademarks of Apple Computer, Inc. Unix is a registered trademark exclusively licensed through X/Open Company, Ltd. Sun, Sun Microsystems, Solaris, and NFS are registered trademarks of Sun Microsystems, Inc. SuSE is a registered trademark of Gesellschaft fr Software- und System-Entwicklung GmbH. Other marks or trademarks are registered trademarks of the companies with which they are associated. NIS is the Network Information Service, a technology developed by Sun Microsystems. NIS allows multiple computers in a local area network to share administrative data. This data is collected in a central database and then distributed around the network. Nearly all operating systems based on Unix use -or can use- NIS. The system instead uses NetInfo, a technology developed by NeXT, or LDAP, a network protocol that was internationally standardized to share administrative data. For an end user there isn't much difference between NetInfo, LDAP and NIS. They basically do the same job, only the implementation and some concepts are different. The first versions of NIS were called Yellow Pages (YP). Because Yellow Pages is a registered trademark for a telephone directory in some countries (in the UK, Yellow Pages is a registered trademark of British Telecom plc), Sun Microsystems was forced to give up that name. Note that all utility programs and system functions which are part of NIS still have the prefix "yp". Most system administrators use NIS to distribute user information to the machines on the network. This enables every computer to know each user's login name, his or her password, the location of the home directory and so on. NIS can also be used as an inventory, as a source for the resolution of IP addresses, or many other information that should be available to every machine of a local area network. NIS has a successor system called NIS+ or NIS Version 3. One of the main differences between NIS and NIS+ is that the latter uses data encryption to be more secure. It also offers better support for very large installations (more than 10,000 users, for example). At the time of this writing, Mac OS X cannot be used with NIS+, so only NIS is described in this document. For obvious reasons this document cannot give a complete introduction into the world of NIS. The standard text-book on NIS is Hal Stern: NFS and NIS, O'Reilly, Cambridge, 1995. Does the use of NIS restrict my rights on the Mac OS X system? If NIS is configured correctly, it is only another source of administrative data. It just provides additional information that coexists with your NetInfo database or other directory services. You can use NIS and NetInfo simultaneously without any problems. Of course you should avoid keeping contradictory or otherwise inconsistent information in the different databases. If you enable NIS on the Mac OS X system, you won't lose any local permissions you already have. For example, if you are the local system administrator (root), you will still have administrative rights on that system after NIS has been switched on. Another consequence is that your NetInfo data does not take precedence over network NIS permissions. So if you are administrator (root) on your own Mac OS X system, you won't automatically become administrator of any other machine on the network. As mentioned above, you never should have contradictory data in NetInfo and NIS. For example, if you have the user id 502 in your local NetInfo database, but a different user also has the UID 502 in NIS, this can be a source of trouble and security problems. Unix security and the organization of consistent permissions go far beyond the scope of this document, so this won't be discussed here. Basic NIS terms To better understand NIS, some specific terms have to be explained. The computer system on which the central NIS database is kept, is the NIS master server. The other computers on the network accessing the database are called NIS clients. A computer can be client and server at the same time, so it can ask itself about entries in the database. There can also be computers providing backup copies of the database. A slave server can take over the role of the master, if the master is shut down, crashes, or has network communication problems. Slave servers are also used for performance reasons: When a master server is too slow in responding to requests, an NIS client can connect to one of the slave servers to get better response times. NIS automatically makes sure that all slave servers are holding up-to-date information. The data is pushed from the master to the slave servers if changes are made in the central database, so information is always synchronized. On small networks, NIS slave servers aren't really needed. A local area network can logically be divided into different "NIS zones", where each zone uses a different database. Each domain needs its own NIS master server, but there are no restrictions which of the machines is made master for which domain. For example, you can have a machine that acts as two NIS master servers for two different domains. You only have to make sure that each NIS client knows to which NIS domain it belongs to. For that reason, each NIS domain needs to have an NIS domain name identifying it. This name is always needed, even if you have one single domain in your network only. NIS domain names have absolutely nothing to do with internet domain (DNS) names. Nevertheless, many system administrators just use the same name for NIS and DNS to avoid confusion. Other administrators just try to avoid this, to make it more difficult for network intruders (crackers) to guess the NIS domain name and steal database information. By using the NIS domain name, an NIS client searches an appropriate NIS master or slave server, usually at boot time, and establishes a connection with the server's database. The NIS database can offer different "tables" of information, for example a list of all users that can access the network, or a list of all machines that are part of the network. There are some predefined standard names that are used in every NIS implementation. A list of predefined map names that will be recognized by Mac OS X is given later in this document. Like in a standard database, the NIS administrator is free to add additional tables (NIS maps) and to choose new names for them. How to enable NIS Prerequisites You must be member of the administrator group to enable NIS on Mac OS X. You also need to know the name of the NIS domain the client should bind to (see " 41 Basis NIS Terms"). We assume the following conditions to be true: * The system has been installed completely and is physically connected to the network. Checking NIS access without modifying your system You can do a "pre-check" to see whether your system can actually connect to the NIS database. Because we do not change any file, this will be a temporary ... |
| www.usit.uio.no/it/mac/ldap/english/ldap.html After possibly authenticating again we get the following view. We uncheck use DHCP-supplied LDAP Server and click the Hide Options button. We push new and then type in the information about our LDAP-server. When this is done (and the new entry is chosen), we push the edit-button A new panel opens that looks like this. We reduce the Open/close timeouts and connection time outs to 10 seconds, instead of 120. Next we select Users and change the search base from the minimal dc=uio, dc=no to ou=users, dc=uio, dc=no. The shadowAccount contains usefull stuff, but not for us. Where you can choose between Search in: all subtrees and first level only, we have found that first level only helps on the responsiveness. We then expand Users and start deleting attributes, keeping: Attribute value RecordName uid RealName cn UniqueID uidNumber PrimaryGroupID gidNumber NFSHomeDirectory homeDirectory Password userPassword UserShell loginShell We are now back to the first panel. When we're done (but before clicking Apply) it looks like this. You can go on to choose the contacts tab and repeat the procedure there. We save the file and restart directiory services using the command /System/Library/StartuItems/DirectoryServices/DirectoryServices restart or restart the computer Result In the current version of the system this enables us to du su <username> on the command line, get the proper information when asked for in lookupd -d and other similar commands. Attempting to ssh from another computer will fail as well, gaining no output from the ssh command. What do we need At the University of Oslo (UiO) we have developed a database system covering all persons which in some way is related to the university. This database is used by everything from Oracle Financial to our homespun students database. All students, all employees are gathered in this database as persons. These users are grouped in accordance to their affiliations by netgroups. Filegroups - the normal groups - are being shunned as fast as we can replace them due to the limitation to 16 groups per user in many unix systems. Since a user can play the role of both students and employees at any number of locations the complexity of our authorizational database would be off the charts if we were to assume the single organizational spantree of users described in Apple's documentation. The first logical requirement for using MacOS X at UiO is a working LDAPv3 authentication scheme with SSL (or better) encryption. As mentioned above this is very close and only fail with a large number of users and groups in combination with SSL/TLS encryption. Granted such an authentication service is available, the next requirement is limiting this authentication. What we want is to be able to limit login on a computer to users of a specific netgroup. Limiting login the Apple way requires partitioning the user database into several OpenDirectory (OD) nodes. If we were to implement an OD node for each netgroup we would have in excess of 2000 separate user databases (with overlapping, as a user can be a member of two groups) and the problems such overlapping of user domains would bring. So the second thing we need after working LDAP authentication is DEL: filegroup :DEL netgroup support in Open Directory. Lookupd has this as far as I can see and there is no problem with mapping netgroups with the LDAPv3 plugin in Directory Access. As of yet we have not found a way to receive netgroups from our LDAP server and view them in lookupd -d. If netgroup support existed we could the go on to limiting login to given users and netgroups. What I have in mind here is alike to the behaviour in the classic /etc/passwd file where +username includes that user from NIS and +@netgroup includes or expands to all users from that netgroup. The ideal answer would be an LDAPv3 client with filters. A basis query, such as ou=users,dc=uio,dc=no would be combined with an array of allow and deny filters. A specific example of such a filter would be: deny all, allow netgroup("usit") or allow all, deny netgroup("alumni"). The simple approach to this is obviously to trust the user to know his own system and allow the user to write this filter completely on his own, with no fancy pulldown menues or lists. It would not need to be any different than the /etc/passwd file format. This is an expert mode, no regular user should need to see this. Fiddling with the NIB I created something that looks like what I think of. While I did specify that we see filters as something advanced, which the user should not necessarily see, I imagine that a GUI for this would look something like this. A Basic tab for simple matches, such as uid = macadm or uid (- sv-users with an associated action, such as accept or deny. The manual tab would be just a single large text field where the administrator would create one single large filter manually, containing all the minor filters or whatever this (hopefully knowledged) administrator wants. |
| www-personal.umich.edu/~arosenbl/kerb102.html It defaults to a realm at MIT if it cannot read the file you have added. In addition, you can set your default "favorite realm" so that loginwindow knows which realm to authenticate against. If you ran the extras installer it should be in your Applications/Utilites/ folder. Make sure the realm you want Login Windows to authenticate against is at the top of the "Favorite Realms" list on the left and click 'Done'. You can now click 'Get Tickets' in the main window of the Kerberos application. Select your sites realm in the 'Realm' popup box and type in your login and password and click 'OK'. The Kerberos application will get your Kerberos tickets. If you are successful, you will see your uniquename@REALM in the bottom part of the window and clikcing on the disclosure triangle will reveal the services your have tickets for. You can now use Kerberos to authenticate securely with applications like Mulberry. Kerberos Application The Kerberos applicaton, showing an authenticated user and the service tickers he/she currently has. Set up a Mac OS X user with the same "short name" as your Kerberos username. Change your password for that user so that it is your U of M kerberos password. If you want to only be able to type in your username and password, in the Login Options, select the "Name and password" radio button. Otherwise, check "List of users" so that you can click on your user icon. Edit the /etc/authorization file so login window will attempt to get Kerberos tickets when you log in. In the <string>switch_to_user</string> line: add krb5auth:login to the string so that it looks like: <string>switch_to_user,krb5auth:login</string> 4. Exit pico by typing 'control-X' and agree to save your changes. Next time you log into your machine, if you are connected to the network, you will get a Kerberos ticket upon login. If you are not connected to the network, you will still be able to log in. |