Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Tony Hoyle wrote:
> Brian Smith wrote:
>
>> Well, maybe this is confusion on my part. I know there is an option to
>> have AcceptSecurityContext use a special "Negotiate" security SSP where
>> it does this automatically. But, I thought you had said earlier that
>> NT4.0 doesn't support negotiation so :sspi: was going to be NTLM-only.
>> Also, all of the functions in sspi.c are prefixed with "NTLM" so I
>> thought was further evidence that :sspi: was going to be NTLM-only.
>
> I've never tried it... Perhaps booting an NT4 image under VMWare to
> test it would be a good idea.
Only Windows 2000/XP support the "negotiate" SSP (I just checked).
> With the protocol changes I'm putting in SSPI Just sending 'Negotiate,
> NTLM' to an NT4 server should allow it to gracefully downgrade itself.
This sounds like an excellent idea.
> That would be great if it could be made to work.
:sspi: and :gserver: using the Microsoft Kerberos SSP are both working
on my current tree. I have briefly tested the following configurations.
In each of the :gserver: cases, I tested with "cvs -x" and "cvs -a" and
without either "-a or -x".
:gserver:
========================================================================
client: Linux stock VS 1.11.1p1 server: CVSNT patched (SSPI)
client: CVSNT patched (SSPI) server: CVSNT patched (SSPI)
client: CVSNT (MIT Kerberos) server: CVSNT patched (SSPI)
:sspi:
========================================================================
client: CVSNT patched server: CVSNT patched
Here is a partial list of things I had to change. I started to try to do
a merge so I could send you a patch but I'm too tired so I'll have to do
it tomorrow night after school.
There are a few things I have to polish up as well but I'd like to get
my changes merged in ASAP if possible so that the merge conflicts don't
get worse and worse (there are a lot of conflicts in sspi.c). For
example, there is some common code I'd like to factor out. I also need
to improve my error handling a little bit and expose the "use
third-party gserver" setting as an option for the user.
1. I had to change the signature of the get_protocol_interface function to:
struct protocol_interface *get_protocol_interface(
const char * method /* e.g. "gserver", "sspi",
const struct server_interface *server);
this caused a lot of little changes (one for each protocol).
I had to do that because get_protocol_interface will return different
values depending on what authentication protocol it is supposed to use.
2. I had to change all token-size handling code so that they are written
as 16-bit network-byte-order integers.
3. I had to change the AcceptSecurityContext loop since it was operating
in a NTLM-specific manner. I changed InitializeSecurityContext too but I
can't remember why, sorry.
4. I had to rewrite the wrapping/unwrapping code because it was not
GSSAPI compatible.
5. I had to change find_authentication_protocol so that it uses
sspi_protocol.dll instead of gserver_protocol.dll for ":gserver:" if the
windows version is >= 5.0 and a "use third-party gserver" flag is not
set. I think there is a more elegent way of doing this. For example, we
could create a registry entry for each supported protocol. The name of
the registry entry is the protocol name (.e.g. "sspi", "gserver") and
the value is the name of the DLL to use for that protocol. That way,
someone could disable protocols by deleting these registry entries.
Good {night|day},
Brian Smith
_______________________________________________
Cvsnt mailing list
Cvsnt at cvsnt.org
http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt https://www.march-hare.com/cvspro/en.asp#downcvs