J talbot 2007-08-31 23:54:25
I have read a lot of articles on how to configure delegation correctly to
enable me to use IWA to gain access to an IIS site which is based on a
shared folder located on another computer in the domain but it doesn’t let
me in and was wondering if someone knew why. This is a pure 2003 domain.
I have setup the following :
SERVER A (the domain controller) – has the shared folder
SERVER B has the virtual folder setup in IIS that is pointing to the share
located on another computer (i..e. \\SERVERA\share\ – For the directory
security I have anonymous access off and IWA turned on. I also have “Read”
and “Directory browsing” turned on. The folder itself has Everyone full
In Active Directory I have set Delegation for SERVER B to “Trust this
computer to delegation for any service”.
However, when I go to site on SERVER B (logged in as domain admin) I am
asked for manual login – attempting to login as Domain Admin I just get
asked repeatedly until I get a 401.3 – Access denied error.
Are there any other steps I need to take for this to work ?
Ken schaefer 2007-08-31 23:54:40
IIS and Kerberos Part 1 – What is Kerberos and how does it work?
IIS and Kerberos Part 2 – What are Service Principal Names?
IIS and Kerberos. Part 3 – A simple scenario
IIS and Kerberos Part 4 – A simple delegation scenario
You need to verify that IE is configured correctly
You need to ensure that an SPN for CIFS is correctly set
You need to ensure that the client is using Kerberos to authenticate to IIS
(because you choose the “trust this computer to delegate to any service” –
this procludes Protocol Transition)
J talbot 2007-08-31 23:54:40
Thanks Ken for your interesting articles which certainly make the process
much clearer. However, after reading through :
1) The IE client has “Enable IWA” turned on. SERVER B is in the Local
Intranet zone and I have “Automatic logon only in Intranet Zone” enabled.
2) from reading your articles I was under the impression that SPN for IIS
is correctly set if the application group is running as Network Service –
which it already is.
I have also turned Kerberos logging on for both servers but no errors are
showing in Event Viewer | System
Ken schaefer 2007-08-31 23:54:41
Can you look in the Security Event log of the webserver, and verify that the
client is actually authenticating using Kerberos (and not NTLM)?
screenshots of what you are looking for.
J talbot 2007-08-31 23:54:41
Hmm no it’s attempted login using NTLM – any idea on what would make it
fall back to NTLM ?
Davemo 2007-08-31 23:54:53
The only reason that the client should fall back to NTLM in this
scenario is if the KDC can not find a host account that would match
What is the URL that is used in IE?
What is the name of the IIS server?
J talbot 2007-08-31 23:54:54
The URL that is used is http://serverb:81 (the port IIS is running on)
The IIS server is called serverb
http://serverb is in the local intranet zone on the client and as mentioned
earlier Enable IWA is turned on.
Davemo 2007-09-05 02:37:08
SPNs can be applied to a unique port and since you aren’t using the
default port for HTTP this might be why the ticket request is failing.
Try setspn -A http/serverb:81 serverb (assuming IIS virtual folder is
configured to use an app pool using Network Service/Local System
This is just a guess – I don’t know whether using a different port
would cause the failure and I can’t easily repro your problem at this
A good diagnostic tool for this kind of problem is the latest version
of klist. If you can find the right version it allows you to request
tickets to arbitrary services from the command line and makes it a bit
more direct to figure out what the failure cases might be.
J talbot 2007-09-05 02:37:21
thanks for the pointer
Ken schaefer 2007-09-05 02:37:26
DaveMo is correct.
If you are accessing IIS on a non-standard port, then there is no SPN
currently registered for that FQDN. Reread the link I posted earlier on SPNs
for instructions on how to configure an additional SPN for your IIS server
on that non-standard port.
J talbot 2007-09-09 06:38:02
Thanks to both of you. This was the problem.