Windows R2 NTLM issues

Discussion:

(too old to reply)

BlueIT

2010-06-15 17:54:09 UTC

I have been poking away at this issue from some time now without
prevail. The following is a highlight of my environment:

DC01 - 2003 R2 (all FSMO roles)
DC02 - 2008 R2
DC03 - 2008 R2

The machine in question is running 2008 R2 with SQL 2008 (SQL01). Our
original problem stemmed from authentication issues in which we soon
realized that 2008 R2 has a minimum of 128-bit encytion for NTLM.
Once I ruled that out by setting to no restriction on the domain
controllers I still have an issue which has me exhausted. Basically,
if the machine (SQL01) logon server is DC01(2003 R2) proprietry app
(built with SSPI) timeouts. After speaking with the development team,
the proprietry app has a 15 second timeout interval.

Windows 2003 R2, by default is No minimum. All the 2008 R2 domain
controller have NTML set to no restrictions:
Computer Configuration\Windows Settings\Security Settings\Local
Policies\Security Options:
Network security: Minimum session security for NTLM SSP based
(including secure RPC) clients = No minimum
Network security: Minimum session security for NTLM SSP based
(including secure RPC) servers = No minimum
Network security: LAN Manager authentication level = Send LM & NTLM -
use NTLM2 session security if negotiated.

Observation:
If the logon server for SQL01 is either of the two 2008 R2 domain
controllers, proprietry app has no issues that we can replicate. Any
dependent apps work at par. If the logon server is the 2003 R2 domain
controller, proprietry apps timeouts and any dependent apps fail or
are horribly slow. I use echo %logonserver% command to determine the
logon server.

My next steps were to set no restrictions on SQL01 since it is a 2008
R2 machine and have the preference logon server to DC01 (2003 R2) but
to my surprise I still have the same issue. I have tried numerous
thing with the help of GOOGLE, but still no luck. Yes, one can say
problem solved once I upgrade DC01 to 2008 R2, but that defeats the
purpose of appreciated the true solution.

Thanks in advance and let me know if more information is required.

BlueIT

moncho

2010-06-17 10:43:34 UTC

Permalink

Post by BlueIT
I have been poking away at this issue from some time now without
DC01 - 2003 R2 (all FSMO roles)
DC02 - 2008 R2
DC03 - 2008 R2
The machine in question is running 2008 R2 with SQL 2008 (SQL01). Our
original problem stemmed from authentication issues in which we soon
realized that 2008 R2 has a minimum of 128-bit encytion for NTLM.
Once I ruled that out by setting to no restriction on the domain
controllers I still have an issue which has me exhausted. Basically,
if the machine (SQL01) logon server is DC01(2003 R2) proprietry app
(built with SSPI) timeouts. After speaking with the development team,
the proprietry app has a 15 second timeout interval.
Windows 2003 R2, by default is No minimum. All the 2008 R2 domain
Computer Configuration\Windows Settings\Security Settings\Local
Network security: Minimum session security for NTLM SSP based
(including secure RPC) clients = No minimum
Network security: Minimum session security for NTLM SSP based
(including secure RPC) servers = No minimum
Network security: LAN Manager authentication level = Send LM& NTLM -
use NTLM2 session security if negotiated.
If the logon server for SQL01 is either of the two 2008 R2 domain
controllers, proprietry app has no issues that we can replicate. Any
dependent apps work at par. If the logon server is the 2003 R2 domain
controller, proprietry apps timeouts and any dependent apps fail or
are horribly slow. I use echo %logonserver% command to determine the
logon server.
My next steps were to set no restrictions on SQL01 since it is a 2008
R2 machine and have the preference logon server to DC01 (2003 R2) but
to my surprise I still have the same issue. I have tried numerous
thing with the help of GOOGLE, but still no luck. Yes, one can say
problem solved once I upgrade DC01 to 2008 R2, but that defeats the
purpose of appreciated the true solution.
Thanks in advance and let me know if more information is required.
BlueIT

While I do not have a solution to your problem, and I completely
understand that finding a solution would be the correct way to
do things in a perfect world, we don't live in one.

IMHO, if the current setup is more of an annoyance vs lost productivity
then I say keep searching and/or waiting to find the answer. The
feeling of solving a nagging issue does give a person self-satisfaction,
especially with the field we are in.

If it is causing downtime, loss of company dollars in lost productivity
with your the user base and you want to fight the easiest solution so
you can get your kudos, you are doing a disservice to everyone,
especially yourself.

Move the FSMO roles to the DC02, decommission DC01, and raising the
functional level to 2008 R2 may be better for all involved (based on
the information you stated above). Your problem goes away, at least
temporarily until another crops up, and you get to move on with the
rest of your career.

To sum up, if the problem causes no money loss, I say go for solving,
if not, fix the problem with the fix you have and stop wasting
company dollars because that is why they hire us. I've had to kick
myself in the butt a few times on similar issues. :-)

moncho

BlueIT

2010-06-17 13:59:52 UTC

Permalink

Post by moncho

While I do not have a solution to your problem, and I completely
understand that finding a solution would be the correct way to
do things in a perfect world, we don't live in one.
IMHO, if the current setup is more of an annoyance vs lost productivity
then I say keep searching and/or waiting to find the answer. The
feeling of solving a nagging issue does give a person self-satisfaction,
especially with the field we are in.
If it is causing downtime, loss of company dollars in lost productivity
with your the user base and you want to fight the easiest solution so
you can get your kudos, you are doing a disservice to everyone,
especially yourself.
Move the FSMO roles to the DC02, decommission DC01, and raising the
functional level to 2008 R2 may be better for all involved (based on
the information you stated above). Your problem goes away, at least
temporarily until another crops up, and you get to move on with the
rest of your career.
To sum up, if the problem causes no money loss, I say go for solving,
if not, fix the problem with the fix you have and stop wasting
company dollars because that is why they hire us. I've had to kick
myself in the butt a few times on similar issues. :-)
moncho- Hide quoted text -
- Show quoted text -

Hilarious. I have a solution in place and seems to be working. I am
just worried that I opened up another can of worms.