home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / mswindo / programm / win32 / 2806 < prev    next >
Encoding:
Text File  |  1993-01-11  |  3.3 KB  |  65 lines
  1. Newsgroups: comp.os.ms-windows.programmer.win32
  2. Path: sparky!uunet!paladin.american.edu!gatech!destroyer!news.iastate.edu!martin
  3. From: martin@iastate.edu (Martin R Calsyn)
  4. Subject: Re: NT not multiuser, then Unix is not a competing OS
  5. Message-ID: <C0p95w.7M5@news.iastate.edu>
  6. Sender: news@news.iastate.edu (USENET News System)
  7. Organization: Iowa State University, Ames, IA
  8. References: <1993Jan8.194335.21272@koko.csustan.edu> <0T5DVB1w165w@gnct.com> <1993Jan11.031254.14628@ryn.mro4.dec.com>
  9. Date: Mon, 11 Jan 1993 17:13:05 GMT
  10. Lines: 53
  11.  
  12. In article <1993Jan11.031254.14628@ryn.mro4.dec.com> Peter.Mayne@cao.mts.dec.com writes:
  13. >
  14. >In article <0T5DVB1w165w@gnct.com>, garyng@gnct.com (Gary Ng) writes:
  15. >>NT is not multiuser in the sense that it do not allow more than 1 person to
  16. >>logon and use it simultaneously(in the way one logon to unix or ibm mainframe).
  17. >
  18. >Despite the fact that telnet servers have been/are being written for NT that
  19. >allow just that?
  20.  
  21. I wouldn't be too sure about those telnet servers (telnetd) for NT.  I
  22. embarked on such a project, only to be thwarted.  If there's interest,
  23. I'll post the official reply from MicroSoft, but essentially, a crucial
  24. API call set is not available.
  25.  
  26. When you log on through WINLOGON, you get an access token which is the
  27. basis for all further security interactions with NT.  That is, WINLOGON
  28. takes your cleartext username and password and produces an access token.
  29.  
  30. In order to produce a true telnetd application giving you all of the
  31. same system, file, and network access rights, your telnetd must be able
  32. to accept a cleartext username and password and use them to obtain an
  33. access token.  WNetAddConnection2() accepts a name & password, but only
  34. gives you access to NT file shares -- it does not give you all of the
  35. security components necessary for generalized interactive computing.
  36.  
  37. This is not so much of a problem for NT<-->NT interactions since one NT
  38. system can pass security information to another based on the user
  39. authentication already performed at logon to the first system.  Named
  40. pipes, etc do this.  But, the components necessary for authenticating
  41. users originating on foreign (non-NT) systems is not available.  Using
  42. `fake' logons is not sufficient - they might get you past your telnetd
  43. logon, but you still wouldn't have the security objects you need to get
  44. anything useful done in NT.
  45.  
  46. I have campaigned MS on this issue (on CI$ forum MSWIN32) and recieved a
  47. response which indicated that MS considers it insecure to allow the
  48. calls to be made other than in a communications session layer (I'm not
  49. entirely sure what they meant by that).  The note did mention the
  50. possibility of some future extensions to the security API but was quite
  51. fuzzy and noncommital on this point.
  52.  
  53. Barring any back-door, undocumented-API efforts (I have no idea whether
  54. any would be successful), this would appear to put a serious roadblock
  55. in the way of porting/implementing telnetd, rshd, or any other service
  56. requiring acquisition of generalized access from cleartext
  57. authentication.  (ftpd is an exception -- WNetAddConnection2() is
  58. sufficient for this application)
  59.  
  60. -- 
  61. Martin R. Calsyn                                   martin@iastate.edu
  62. Software Innovations Incorporated                  voice: (515) 232-9196
  63. P.O. Box 644                                              (800) 728-1525
  64. Ames, Iowa 50010                                   fax:   (515) 233-6209
  65.