Groups | Blog | Home
all groups > iis security > june 2007 >

iis security : Delegation / IIS6 / share located on another computer


J Talbot
6/6/2007 3:28:42 PM
Hi

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
permissions.

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 ?

Thanks

JT


Ken Schaefer
6/7/2007 12:00:00 AM
IIS and Kerberos Part 1 - What is Kerberos and how does it work?
http://www.adopenstatic.com/cs/blogs/ken/archive/2006/10/19/512.aspx

IIS and Kerberos Part 2 - What are Service Principal Names?
http://www.adopenstatic.com/cs/blogs/ken/archive/2006/11/19/606.aspx

IIS and Kerberos. Part 3 - A simple scenario
http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/16/1054.aspx

IIS and Kerberos Part 4 - A simple delegation scenario
http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/27/1282.aspx

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)

Cheers
Ken


[quoted text, click to view]
J Talbot
6/7/2007 10:25:37 AM
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

Thanks

JT


[quoted text, click to view]

J Talbot
6/7/2007 2:27:27 PM
Hmm no it's attempted login using NTLM - any idea on what would make it
fall back to NTLM ?

Thanks

John

[quoted text, click to view]

DaveMo
6/7/2007 6:51:37 PM
[quoted text, click to view]

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
the URL.

What is the URL that is used in IE?
What is the name of the IIS server?

Dave
Ken Schaefer
6/7/2007 9:17:46 PM
Hi,

Can you look in the Security Event log of the webserver, and verify that the
client is actually authenticating using Kerberos (and not NTLM)?

http://www.adopenstatic.com/cs/blogs/ken/archive/2006/08/02/194.aspx has
screenshots of what you are looking for.

Cheers
Ken

[quoted text, click to view]
J Talbot
6/8/2007 12:00:00 AM
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.

Thanks

John


[quoted text, click to view]

DaveMo
6/8/2007 5:37:41 AM
[quoted text, click to view]

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
identity).

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
time.

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.

HTH.

Dave
J Talbot
6/8/2007 3:17:27 PM
thanks for the pointer

[quoted text, click to view]

Ken Schaefer
6/9/2007 12:00:00 AM
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.

Cheers
Ken

[quoted text, click to view]
J Talbot
6/11/2007 12:00:00 AM
Thanks to both of you. This was the problem.

John

[quoted text, click to view]

AddThis Social Bookmark Button