I was interested in disabling NTLMSSP for authentication and password
changing in particular, which are system services.
As it turns out, if there have not yet been any network logins to the NT
Server, you can disable the "NT Lan Manager Security Service Provider"
Service under the Services Control panel. Of course, if the service has
already started and you stop it, services.exe pulls a Dr. Watson.
Once I disabled the service, all previously encrypted connections were
sent unencrypted.
I spent hours digging through the registry looking for a hidden key, and
all I had to do was set a service startup to 'disabled'. How
annoying... :-)
Might be helpful to those who are dissecting protocols that are normally
encrypted. For example, I am working on the password change protocol.
Once I disabled the encryption, I found that the protocol is not
properly dissected.
-Devin
On Mon, 2002-07-08 at 10:02, Todd Sabin wrote:
> dheitmueller <dheitmueller@xxxxxxxxxxx> writes:
>
> > Does anyone know how to cause Windows NT or Windows 2000 to not
> > negotiation ntlmssp-1? The MSDN docs refer to an
> > LMCompatibilityLevel and NtlmMinClientSec registry keys, but these
> > seem to be tied to the minimum acceptable. In my case, I want it to
> > NOT negotiate the crypto.
> >
> > Has anyone played with this before? I suspect there is a registry
> > key to control this behavior, it just may be unpublished.
> >
> > Ideally, if I can drop the crypto, I can better dissect some of the
> > request types that are usually encrypted.
>
> In what context is the crypto you're referring to? If it's DCERPC,
> then it's generally up to the application to pick the auth level for
> the traffic.
>
>
> Todd
--
Devin Heitmueller
Senior Software Engineer
Netilla Networks Inc
