home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / protocol / kerberos / 684 < prev    next >
Encoding:
Text File  |  1992-09-09  |  1.7 KB  |  43 lines
  1. Newsgroups: comp.protocols.kerberos
  2. Path: sparky!uunet!stanford.edu!ATHENA.MIT.EDU!bjaspan
  3. From: bjaspan@ATHENA.MIT.EDU ("Barry Jaspan")
  4. Subject: Re:  Existing authentication mechanisms have a deficiency
  5. Message-ID: <9209091759.AA09057@portnoy.MIT.EDU>
  6. Sender: news@shelby.stanford.edu (USENET News System)
  7. Organization: Internet-USENET Gateway at Stanford University
  8. Date: Wed, 9 Sep 1992 17:59:59 GMT
  9. Lines: 32
  10.  
  11.  
  12.    Date: Wed, 9 Sep 92 09:14:34 PDT
  13.    From: nessett@ocfmail.ocf.llnl.gov (Danny Nessett)
  14.  
  15.    One could imagine a system configured so that all on-machine
  16.    authentication requests contacted the appropriate server, say the
  17.    Kerberos server ...
  18.  
  19. Yes, that is part of what Kerberos does, for all the reasons you
  20. mentioned.
  21.  
  22.    ... my suggestion about modifying su to contact the appropriate
  23.    server to perform authentication was along these lines.
  24.  
  25. And that is *exactly* what ksu does.  It uses a central authentication
  26. service, Kerberos, to determine the identity of a user, and then a
  27. local authorization service, the /.klogin file, to determine whether
  28. or not to allow the authenticated individual to become root on the
  29. local host.  The /etc/passwd file is not consulted for authentication
  30. or authorization information.
  31.  
  32. Hmmm.. Are suggesting that a modified su should request a tgt for the
  33. Kerberos principal root (as opposed to the Unix user root) and allow
  34. root access if the correct Kerberos password is provided?  That's a
  35. possibility (given the caveats in the Kerberos FAQ question #9), but
  36. it seems much less flexible to define one "root password" for all
  37. machines on the network instead of allowing each machine to specify
  38. its own set of "root users".
  39.  
  40. In short, I do not understand what you think should be changed.
  41.  
  42. Barry
  43.