It's a really bad practice, kinda like enabling WEP to protect your WiFi because you have a Windows 98 computer that won't work with WPA2. It's 2009, Kerberos works if you really, really need SSO.
I also consider integrated authentication for websites to be a bad practice in general as it often leads to oddball issues when users have multiple accounts (we use separate user/admin accounts), requires you to muck around with IE trust zones, and requires you to use IE or fiddle with Firefox settings.
Given the trainwreck that IE has been and continues to be since 2002 or whenever IE6 came out, (ie. The out of band ActiveX patch) do you really want to commit to the platform?
i figured out the problem, it had to do with the clock settings on both machines:
Client: 3/20/2011 1:28:17 ᴘᴍServer: 3/20/2011 1:28:17 ᴘᴍ
To the untrained eye, it appears as though both clocks read the same. There's a limitation of the negiotation protocol which requires that all clocks be within 15 minutes of each other. These clocks differ by an hour. This is because the operating systems involved:
- Client: Windows 7
- Server: Windows 2000 Server
And because Windows 2000 Server is no longer supported, its daylight savings start date is no longer valid. So the times on both machines are really:
Client: 3/20/2011 1:28:17 ᴘᴍ EDTServer: 3/20/2011 1:28:17 ᴘᴍ EST
That's because the client has (correctly) switched to Daylight Savings Time, while the server is still on Standard Time. This means that the client machine clock is an hour ahead of the server clock - and so the two cannot authenticate.
Normally when the two clocks are more than 15 minutes out of sync, you would get a message warning you of that fact. In this case the clocks are synchronized, so there is no warning.
Summary: 3221225578, Windows 2000, Daylight Savings Time
In the meantime, just to make things work, i've restored to clock to the server to be an hour behind - and i'll let the "natural" DST switchover catch up - and transactions will start happening at the correct time again.
Best Answer
Typically the same value is configured on all Windows computers. The objective is to prevent any and all usages of NTLM1 due to the severity of the security risk. If a client transmits an NTLM1 hash over the network, it may be intercepted and easily cracked compared to NTLM2, depending on the length/complexity of the password. This is a common tactic used by attackers in man-in-the-middle attacks during the recon phase of an incursion. So you don't want NTLM1 anywhere in your environment.
The setting behaves differently depending if the computer is performing a client or server function. Any Windows computer (workstation, member server, or domain controller) can perform both.
Highly recommended to have a backout planned as a contingency. Assessing NTLM1 usage and impact is notoriously difficult, especially if you have a large, heterogeneous environment with a lot of crusty old legacy systems.
The Most Misunderstood Windows Security Setting of All Time
https://technet.microsoft.com/en-us/library/2006.08.securitywatch.aspx