One addition: IE will not attempt to
negotiate Kerberos Auth if is the site is in the Internet Security Zone (which
sites accessed by FQDN are by default). Add the site to the local Intranet
zone. Some other thoughts: If NTLM is not
desired (i.e. Kerberos only), then you can set the Auth Providers key to “Negotiate”
only, rather than “Negotiate,NTLM”. That will stop IE from using
NTLM KB299838 only applies to IE5 upgraded to
IE6 AFAIK, so if you have, say, Windows XP that comes OOB with IE6, then the
checkbox mentioned is already checked (by default). Lastly, if Kerberos isn’t an option
(e.g. users out on the Internet), then if you have a Windows 2003 Domain,
Protocol Transition may be a possibility (but I’ve never set that up on a
Sharepoint box, so I can’t say with 100% certainty that it’ll work):
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/constdel.mspx But in OP’s case, I think the first
thing to check is the Auth Providers key, since Sharepoint does set that to
NTLM by default (as mentioned below) Cheers Ken From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Carlos, If I understand the situation correctly
you are going client -> Sharepoint IIS server -> ISA server. It sounds
like you need to pass the client's kerberos credentials all the way to the ISA
box. If that is correct, here is what I would try... Client Browser: IE6SP1 will not negotiate
kerberos by default. You need to set the integrated authentication value as
detailed in KB299838. Sharepoint IIS Server: The default
Sharepoint install disables kerberos by default (see KB823265 - this is an
exchange article but it documents the default sharepoint install behavior). See
KB832769 for directions on how to enable kerberos for sharepoint. We did the
following to allow the default website to use kerberos: Cscript adsutil.vbs set
w3svc/1/ntauthenticationproviders “Negotiate,NTLM” Iisreset Next, setup the application pool service
account to permit delegation (ADU&C) "account is trusted for
delegation" After this, you need to add an SPN to the
service account that you setup to run the application pool: Setspn –A
HTTP/fqdnofyourserver yourdomain\youraccount At this point your client should negotiate
kerberos when it connects to the SPS server. You can verify this with kerbtray
from the resource kit. You should see a ticket for the application pool service
account. If you connect to the SPS site by any
other URLs other than the FQDN (i.e. the netbios name of the server or some
other internal namespace URL - sps.app.local, etc) you will need to add
additional SPNs to the application pool service account: Setspn –A
HTTP/netbiosservername yourdomain\youraccount Setspn –A
HTTP/sps.app.local yourdomain\youraccount Again, after you do this you shold be able
to access the site by any of the three URLs (server FQDN, server netbios, other
namespace URL) and see the ticket for the application pool service account in
kerbtray. In my case the sharepoint server was the
endpoint of the connection trail but once you get to the SPS server with
kerberos you should be able to hop again to the ISA box. Hope this helps - it may be a repeat of
what you have already done. This is an extract of the doc that I wrote for
myself when I had to figure this out. You amy also want to take a peek at the
ISA box to see if the ISA install also turned off Kerberos. I don't know about
this one because I have never had to look at that one... Frank From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Magalhaes Hey all, Ok late at night here and I’ve hit a mental block
(don’t laugh Dean). I have set this up like a gazillion times but this
time cant get it to work. Environment: Windows 2003 Native Forest Mode – All clients Windows
XP SP2 and above Single forest single domain setup Web Server – Windows Server 2003 Web Edition Share Point Team Services installed. That site has a web part that requires Kerb delegation for
access to a ISA firewall in order to stream RSS feeds. I can see on the ISA
server that when ever any user hits the site the HTTP request is sent as
ANONYMOUS. So what I have done:
a. Purged all
tickets as well.
Still get Anonymous access on the ISA box, and using some
normal .net code can see that its not delegating the creds correctly, can
anyone see what I am doing wrong or what I should be doing?
Carlos |
- RE: [ActiveDir] Kerberos Delegation joseph.e.kaplan
- RE: [ActiveDir] Kerberos Delegation Rick Kingslan
- RE: [ActiveDir] Kerberos Delegation Bernard, Aric
- RE: [ActiveDir] Kerberos Delegation Free, Bob
- RE: [ActiveDir] Kerberos Delegation Ken Schaefer
- RE: [ActiveDir] Kerberos Delegation joseph.e.kaplan
- RE: [ActiveDir] Kerberos Delegation joseph.e.kaplan
- [ActiveDir] Kerberos Delegation Carlos Magalhaes
- RE: [ActiveDir] Kerberos Delegation Tony Murray
- RE: [ActiveDir] Kerberos Delegation frank . carroll
- RE: [ActiveDir] Kerberos Delegation Ken Schaefer
- RE: [ActiveDir] Kerberos Delegation Carlos Magalhaes
- RE: [ActiveDir] Kerberos Delegation Tony Murray
- RE: [ActiveDir] Kerberos Delegation Carlos Magalhaes
- RE: [ActiveDir] Kerberos Delegation Roger Seielstad
- RE: [ActiveDir] Kerberos Delegation Ken Schaefer
- RE: [ActiveDir] Kerberos Delegation Carlos Magalhaes
- RE: [ActiveDir] Kerberos Delegation Roger Seielstad
- RE: [ActiveDir] Kerberos Delegation Ken Schaefer
- RE: [ActiveDir] Kerberos Delegation Roger Seielstad
- RE: [ActiveDir] Kerberos Delegation Brian Desmond