Hi,

I have an AD domain which hosts an application which uses IWA. All the users
are from domains other than my domain and a trust exists between my domain
and all the user domains.

The IWA works fine for users on Windows 2000, Windows XP and clamped down
Windows NT 4.0 workstations. It doesn't however work for users on NT 4.0
workstations with little or no clampdown.

The IIS log file gives a long number when one of these users logs on and
that number means an NTLM authentication failure. It's not just the
LMCompatibility level on those workstations - we've tried every value 1-5 -
it's something else as well.

The webserver has LMCompatibilityLevel set to 5 and it also has
NTLMMinServerSec set to 0x20080030 which means that if Message Integrity,
Message Confidentiality, NTLM 2 session security and 128-bit encryption are
not negotiated it won't allow the connection. See Q239869 for further details.

So I think that these workstations aren't capable (for some reason) of doing
one or more of those 4 things. Now I don't want to lower my end of the
security - I want to identify what needs doing to those workstations to raise
their level of security. So my main question is "What is required at the
workstation end for each one of those 4 things to be successfully negotiated?"

I think I can answer the 128-bit encryption one myself. If IE on the
workstations reports 128-bit in the Help|About dialog box and schannel.dll
(amongst others) reports itself as Domestic (US & Canada) in it's version
info then we're OK for the 128-bit encryption.

Any ideas why the other three might be failing?

Regards,
Charles

The NT 4.0 workstations will not be able to negotiate NTLMv2 unless you
install the DSClient on them.

DSClient provides:
Site-awareness
NTLMv2
LDAP search ability
SMB-signing capability
AD object edit ability using the WAB
No dependency on PDC for password changes
ADSI support
DFS fault-tolerant client

Active Directory Client Extensions for Windows 95/98 and Windows NT 4.0:
http://www.microsoft.com/windows2000/server/evaluation/news/bulletins/adextension.asp

I have an AD domain which hosts an application which uses IWA. All the users
are from domains other than my domain and a trust exists between my domain
and all the user domains.

The IWA works fine for users on Windows 2000, Windows XP and clamped down
Windows NT 4.0 workstations. It doesn't however work for users on NT 4.0
workstations with little or no clampdown.

The IIS log file gives a long number when one of these users logs on and
that number means an NTLM authentication failure. It's not just the
LMCompatibility level on those workstations - we've tried every value 1-5 -
it's something else as well.

The webserver has LMCompatibilityLevel set to 5 and it also has
NTLMMinServerSec set to 0x20080030 which means that if Message Integrity,
Message Confidentiality, NTLM 2 session security and 128-bit encryption are
not negotiated it won't allow the connection. See Q239869 for further
details.

So I think that these workstations aren't capable (for some reason) of doing
one or more of those 4 things. Now I don't want to lower my end of the
security - I want to identify what needs doing to those workstations to
raise
their level of security. So my main question is "What is required at the
workstation end for each one of those 4 things to be successfully
negotiated?"

I think I can answer the 128-bit encryption one myself. If IE on the
workstations reports 128-bit in the Help|About dialog box and schannel.dll
(amongst others) reports itself as Domestic (US & Canada) in it's version
info then we're OK for the 128-bit encryption.

Any ideas why the other three might be failing?

Regards,
Charles

Todd,

Thanks for the response - however I've got evidence to say that DSClient is
not required.

I've got some NT 4.0 workstations which are clamped down and are in an NT
4.0 domain (also clamped down). The IWA (and hence then application) works
fine from those workstations. They definitely do not have DSClient installed.

Any more ideas?
Cheers,
Charles

Show quoteHide quote

Hello Charles,

Thank you for using newsgroup!

From your post, you have some concerns when using NTLM authentication on
Windows NT 4.0 workstations. At this point, firstly, I'd like to make a
simple explanation as below:

The NTLM protocol was the default for network authentication in Windows NT
4.0 and is based on a challenge response mechanism for client
authentication. It is retained in Windows 2000 for compatibility with
earlier client and server versions of Windows. NTLM is also used to
authenticate logons to stand-alone computers with Windows 2000.

Computers with Windows 95, Windows 98, or Windows NT 4.0 will use the NTLM
protocol for network authentication in Windows 2000 domains. Computers
running Windows 2000 will use NTLM when authenticating to servers with
Windows NT 4.0 and when accessing resources in Windows NT domain.

By default, Windows 2000 is installed in a mixed-mode network
configuration, meaning a network configuration that uses any combination of
Windows NT 4.0 and Windows 2000 computers. A Windows 2000 workstation or
client manages the NTLM credentials entered at system logon on the client
side to use when the client connects to Windows NT 4.0 servers using NTLM
authentication. Support for NTLM credentials in the Windows 2000 security
is the same as for Windows NT 4.0 for compatibility.

As examples, the following configurations would use NTLM as the
authentication mechanism:

1. A Windows 2000 Professional client authenticating to a Windows NT 4.0
domain controller.
2. A Microsoft Windows NT Workstation 4.0 client authenticating to a
Windows 2000 domain controller.
3. A Windows NT Workstation 4.0 client authenticating to a Windows NT 4.0
domain controller.
4. Users in a Windows NT 4.0 domain authenticating to a Windows 2000
domain.
In addition, NTLM is the authentication protocol for computers that are not
participating in a domain, such as stand-alone servers and workgroups.

The NTLM authentication package in Windows 2000 supports three methods of
challenge/response authentication:

LAN Manager (LM).
This is the least secure form of challenge/response authentication. It is
available so that computers running Windows 2000 Professional can connect
in share level security mode to file shares on computers running Windows
for Workgroups, Windows 95, or Windows 98.

NTLM version 1.
This is more secure than LM challenge/response authentication. It is
available so that clients running Windows 2000 Professional can connect to
servers in a Windows NT domain that has at least one domain controller that
is running Windows NT 4.0 Service Pack 3 or earlier.

NTLM version 2.
This is the most secure form of challenge/response authentication. It is
used when clients running Windows 2000 Professional connect to servers in a
Windows NT domain where all domain controllers have been upgraded to
Windows NT 4.0 Service Pack 4 or later. It is also used when clients
running Windows 2000 connect to servers running Windows NT in a Windows
2000 domain.

By default, all three challenge/response mechanisms are enabled. You can
disable authentication using weaker variants by setting the LAN Manager
authentication level security option in local security policy for the
computer.

Regarding your issue, I have performed lots of research and found the
following links that may be helpful:

299838: Unable to Negotiate Kerberos Authentication After Upgrading to
Internet Explorer 6
http://support.microsoft.com/default.aspx?scid=kb;en-us;299838

236414: Cannot Use Shares with LMCompatibilityLevel set to Only NTLM 2
Authentication
http://support.microsoft.com/default.aspx?scid=kb;en-us;236414

305379: Authentication Problems in Windows 2000 with NTLM 2 Levels Above 2
in a Windows NT 4.0 Domain
http://support.microsoft.com/default.aspx?scid=kb;en-us;305379

326985: HOW TO: Troubleshoot Kerberos-Related Issues in IIS
http://support.microsoft.com/default.aspx?scid=kb;en-us;326985

Hope that helps!

In addition, please understand that product support is no longer available
for this product. The newsgroups support policy is based on the product
lifecycle. More information here: 
http://support.microsoft.com/lifecycle/?p1=3194

Thanks & Regards,

Ken Zhao

Microsoft Online Partner Support
Get Secure! - www.microsoft.com/security

=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no rights.


Newsgroup Web Interface Upgrade
Please complete a one-time registration process on your first visit to the
Partner Portal beginning July 11, 2005 at 9 A.M. PST by entering the secure
code mspp2005 when prompted. This secure code will be valid for 6 months
after which you will need to update your registration by entering the new
secure code. We will post announcements in the newsgroups prior to
expiration. Once you have entered the secure code mspp2005 , you will be
able to update your profile and access the the partner newsgroups. Please
update your Favorites link to the newsgroups web page, your current link
will redirect until November 1, 2005.
Please post any comment, questions or concerns to the
microsoft.private.directaccess.partnerfeedback newsgroup. For more
information, please go to:
https://partner.microsoft.com/global/technicalsupport/registeredsupport/4001
4662


--------------------
<OCBhCJBrFHA.***@TK2MSFTNGP14.phx.gbl>
Show quoteHide quotehttp://www.microsoft.com/windows2000/server/evaluation/news/bulletins/adexte
nsion.asp
Show quoteHide quote

DNS & Windows 2003 Server
WinFirewall setup throughout network
local user profile after domains migration
Unable to save Trusted Sites after upgrade W2K3 to SP1
The directory is invalid
we have lost Windows 2000 Server CD's and must install
W2003 - IIS and http-download
folder redirect
Server Work Queues\Queue Length
Win2K3 Ghost