edward@csvaxa.UUCP (Edward Wilkinson) (07/02/88)
We're planning to connect over a thousand PCs to a central Unix server in the near future and have a couple of questions regarding this. 1 - in such a system which may have over a thousand users in /etc/passwd, how does one choose usernames? Try to be meaningful or just use a sequential number or something? What do sites out there in the real world do? Should we run YP? Any descriptions of experience in any of these areas would be gladly welcomed. 2 - In an NFS environment where a user might operate from more than a single PC/workstation, how does one control access when /etc/exports only restricts access on a per machine basis? Any relevent ideas/case histories appreciated. Thanks in advance. -- Ed Wilkinson @ Computer Centre, Massey University, Palmerston North, NZ uucp: {uunet,watmath!cantuar}!vuwcomp!csvaxa!edward DTE: 530163000005 Janet/Greybook: E.Wilkinson@nz.ac.massey Phone: +64 63 69099 x8587 CSnet/ACSnet/Internet: E.Wilkinson@massey.ac.nz New Zealand = GMT+12
mar@athena.mit.edu (Mark A. Rosenstein) (07/06/88)
At MIT's Project Athena, we have addressed these issues, and found solutions that work for us with ~1000 workstations and 10000 accounts. We don't use an /etc/passwd file. Login has been modified to use a nameserver to retrieve account information. Our nameserver is called Hesiod, and is built as a layer on top of the internet domain name system. We found yellow pages to not be a satisfactory nameserver for our needs. In addition to the nameserver for account information, we use a separate authentication server, called Kerberos, for password verification and other security issues. Thus the nameservice does not need to be secure. Hesiod also serves information about filesystems, service locations, groups, printers, and various ID mappings. Users are allowed to choose their own login names. We suggest [first initial, middle initial, last name] as a username, but allow people to choose any username that is not already taken, subject to the constraints: lowercase letters & numbers only, 3 to 8 characters. When a user loses his account, the name and ID numbers are held for a period of time before they can be reused. We control NFS access not per machine, but per user. A user sitting at the console of a unix workstation, or even just a PC, has complete control over that machine. Thus it is necessary to control access based on the identity of the user of that machine, since anyone can sit at any machine. By the Athena model of computation, all workstations should be equivalent. We have integrated kerberos authentication into the NFS mount request. Through kerberos the user proves to the NFS server who he is, and the server looks in a credentials file to determine what access to grant this user. The same service management system that feeds account information to the nameserver keeps these credentials files up-to-date. For more information on the Athena environment, see the papers from the Winter '88 Usenix proceedings. Source code to Hesiod is available now, Kerberos is in beta test, and SMS (the service management system) will be available in the future. For more information, send mail to info-athena@athena.mit.edu. -Mark Rosenstein Project Athena Systems Development