Re: Criteria for IE to Negotiate Kerberos and Not NTLMSSP
- From: "Steven L Umbach" <n9rou@xxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 29 Jun 2006 17:50:03 -0500
Though you are not using IIS reviewing the following KB article still may be
of help. Also by default in an AD domain only a five minute time skew is
allowed for kerberos though normally that is not a problem as Windows domain
computers should be synching with the PDC fsmo domain controller. ---
Steve
http://support.microsoft.com/default.aspx?scid=kb;en-us;326985
"Michael B Allen" <mba2000@xxxxxxxxxx> wrote in message
news:pan.2006.06.29.04.42.18.673583@xxxxxxxxxxxxx
Hi,
I have a web service product that runs on UNIX and does GSSAPI
and requires IE to negotiate Kerberos using Integrated Windows
Authentication. The log on the customer's site is showing that IE is
only asking for NTLMSSP. We're having trouble tracking down why.
I know of the usual reasons for not negotiating Kerberos (or Integrated
Windows Authentication in general) but I would like to create a
comprehensive list in anticipation of creating a wscript utility to
check a workstation for compatibility with my product. Can anyone add
to (or eliminate from) the list below? Are there any other configuration
options or perhaps registry settings somewhere?
Thanks,
Mike
The following is a list of criteria for Internet Explorer to negotiate
Kerberos with a web service (e.g. IIS):
1) The client workstation must be running Windows 2000, Windows XP,
or Windows 2003. Windows NT 4 and Windows 98 or previous do not support
Integrated Windows Authentication.
2) The client workstation must be joined to the target Windows
domain. Check Control Panel > System > Computer Name tab > Change ... and
make sure the client is a member of the correct domain and not just
a workgroup.
[Q: Is it important that the domain name of the client and Kerberos
realm share the same suffix?]
3) The user logged into the workstation using IE must be logged into
the domain. Check Ctrl+Alt+Del and look at the "You are logged on as"
dialog. The Windows domain shown must be the target domain and not the
local machine name. If the user is not logged into the domain, logoff,
select the domain in the drop down labeled "Log on to", and enter the
user's domain credentials (assuming they have domain credentials).
4) Integrated Windows Authentication must be enabled. Check Tools >
Internet Options > Advanced > scroll all the way to the bottom and
make sure "Enable Integrated Windows Authentication (requires restart)"
is checked.
5) Automatic logon must be enabled [1]. Check Tools > Internet Options >
Securty > Custom Level > scroll all the way to the bottom and make sure
"Automatic logon with current username and password" is selected.
6) The target website must be listed in the IntrAnet zone [1]. Check
Tools > Internet Options > Security > Local Intranet and make sure the
target domain is listed there. For example, if your domain is foo.net
add http://*.foo.net and https://*.foo.net. Or you may explicitly add
a specific site (e.g. http://www.foo.net).
[1] Actually this is may not be necessary if the site is in the Trusted
sites list (under Tools > Internet Options > Security).
.
- References:
- Criteria for IE to Negotiate Kerberos and Not NTLMSSP
- From: Michael B Allen
- Criteria for IE to Negotiate Kerberos and Not NTLMSSP
- Prev by Date: Re: Renaming a Certificate Root authority
- Next by Date: Re: Local System Account & Network Access
- Previous by thread: Criteria for IE to Negotiate Kerberos and Not NTLMSSP
- Next by thread: where to upload unknown files for analysis
- Index(es):
Relevant Pages
|
