Hello,

We have a Linux CVS server, and Windows clients running
CVS for NT.  We're using :ext: protocol and PuTTY as the
transport.

The Linux server runs the winbind PAM module, and authenticates
users against the Windows PDC.

Is it possible to connect from a Windows PC to a Linux server
using the same authentication mechanisms as Samba shares?
(Ie, and not have to reauthenticate?)

At the moment, authentication is done with ssh keys, generated
and installed by a web-based installer I wrote.  This has
some drawbacks.  In particular, valid keys are left on
people's PCs, which could be used to access the
server even if the original user is not logged in.  And when
one person logs off and another logs on, the key is the same.
This is especially a problem for Win98 users.

Also, we have found the installation and ongoing problems
of key-based SSH transport to be very painful.

What would be nice to have is a program with pipe-like
functions (like ssh) but which authenticates in the same
way as a Samba share.  In other words, given a Windows user
who has already authenticated when they logged onto their PC,
the program participates in the same challenge-response
dialog with the Linux server and the PDC, in a manner which is
invisible to the user.

I could install Kerberos 5, but that's not going to help
our Win98 users.  (Or is it?)

I have read everything relevant in the Samba docs and looked
into variations of PAM and ssh and a bunch of other things but
found no obvious candidates.  Here's something that seems to
rule out a PAM-based approach:

  http://us4.samba.org/samba/ftp/docs/htmldocs/PAM-Authentication-And-
Samba.html

> The reason is that PAM modules cannot support the
> challenge/response authentication mechanism needed
> in the presence of SMB password encryption. 

Does anyone know of such a program?  Alternatively, is
there an alternative CVS protocol which will do what
we want, instead of ":ext:"???

Here is a list of links I've found with information that
may help:

http://groups.google.com/groups?selm=32fd8664.89629329%40news.uq.edu.au

  Password authentication for Linux servers against a PDC.
  Very old.  Probably surpassed by winbind.

http://www.geocities.com/rozmanov/ntlm/ntlm.html

  Some links to pages about NTLM authentication.

http://www.squid-cache.org/Doc/FAQ/FAQ-23.html

  Talks about NTLM authentication via winbind.  Is obviously
  server-based (ie, the client is IE or similar) but the "winbind
  helper" must participate in a challenge-response dialog.

http://www.tuxedo.org/~esr/fetchmail/
http://www.codeguru.com/mfc/comments/34782.shtml

  The "fetchmail" program can do NTLM authentication, based
  apparently on code taken from Samba.

http://community.uklinux.net/pipermail/libesmtp-devel/2002q1/000055.html

  This guy has librarified the NTLM authentication from
  fetchmail.

http://perlmonks.thepen.com/60186.html
http://bushnet.demon.co.uk/software/NTLM/NTLM.3.html
http://search.cpan.org/dist/Authen-NTLM-0.20/lib/Authen/NTLM.pm

  There are two independent PERL modules for doing NTLM
  authentication.  I think they were derived from fetchmail.

http://sourceforge.net/projects/modntlm/
http://msgs.securepoint.com/cgi-bin/get/apache0209/31.html

  Apache can do NTLM authentication, via a PERL module.
  Probably close association with the above PERL module(s).

http://archives.neohapsis.com/archives/pam-list/2001-05/0005.html

  Someone asking a similar end-to-end transport using NTLM.
  No-one replied.

http://caspian.dotconf.net/menu/Software/SSHD-NT/default.php

  A free SSH server for NT, which will do NTLM authentication.

http://cb1.com/~lkcl/pam-ntdom/

  A PAM module for authenticating against an NT-domain.
  Doesn't solve the problem that if you're coming from a
  PC which is already authenticated, you'll still have to
  reauthenticate.  I think winbind does all this now.

http://www.insecure.org/sploits/NT.domain.smb.lameauth.html

  A description of CIFS SMB authentication.

ftp://ftp.microsoft.com/developr/drg/CIFS/CIFS-Auth-Spec.doc

  Microsoft's take on how CIFS authentication is done.

http://www.samba.org/samba/docs/ENCRYPTION.html

  "In the SMB call SMBsessionsetupX [...] the 24 byte response
  is returned by the client to the Samba server.  [...] server
  [...] reproduces the above calculation, using its own stored
  value of the 16 byte hashed password (read from the smbpasswd
  file - described later) and the challenge value that it kept
  from the negotiate protocol reply. It then checks to see if
  the 24 byte value it calculates matches the 24 byte value
  returned to it from the client.

  If these values match exactly, then the client knew the
  correct password [...] and is thus allowed access. If not,
  then the client did not know the correct password and is
  denied access."

  The problem with this is that it relies on smbpasswd.

Any help or pointers would be appreciated.

Thanks,

Mitch.