Ken
Sat Jun 05 02:00:04 CDT 2004
Hi,
You can see the remote files in ISM because you are logged interactively
onto the server, and thus you can easily get a token for remote access.
HOWEVER, if you are remote to the IIS server (eg, using a browser), then you
need to have Kerberos setup correctly if you want to use pass through
authentication.
a) The server must send back the WWW-Authenticate: Negotiate header
b) IE must have "Use Integrated WIndows Authentication (Requires a Restart)"
checked in IE Options
c) IE must be running on WIndows 2000 or Windows XP
d) The client machine must be able to contact the domain controllers to get
a Kerberos TGT and service ticket
e) If the website's FQDN (or whatever name you are using) is different to
the NetBIOS name of the server, then you need to use the SetSPN.exe tool to
register the appropriate service principal name (SPN):
See:
http://support.microsoft.com/?id=294382
Authentication may fail with "401.3" Error if Web site's "Host Header"
differs from server's NetBIOS name
f) both user accounts and computer must be trusted for delegation in Active
Directory
So, you can see there, is a lot of things that can go wrong. You need to get
everything setup correctly first... :-)
As mentioned, to test to see whether pass-through works, try *disabling*
Integrated Windows Authentication, and enabling Basic Authentication. If
everything starts working, then you know it's a Kerberos delegation issue
(when using Basic Auth, IIS has the user's username *and* password, and can
directly impersonate the user to access the remote resource).
goto:
http://www.adopenstatic.com - there is a link there to download the
sample chapter from my book on IIS security. There is some information there
on how the various authentication mechanisms work, and what you need to do
to get delegation working. If you like the chapter, consider getting the
book.
Cheers
Ken
"Donovan" <anonymous@discussions.microsoft.com> wrote in message
news:6EC8D026-A907-45F7-8B76-28B66F1A1A39@microsoft.com...
: I have tried both steps A and B with essentially the same 401.3 errors.
:
: Ultimately I would like to use the passthrough authentication option as it
seems the cleanest and most secure way of using the share. Even with the
passthrough authentication the authentication bit succeeds whether Anonymous
or a real authenticated user, but it always comes back with a 401.3 error.
:
: I have setup several Anonymous accounts on the domain for use with
Anonymous access, I have even tried the AnonymousPasswordSync option, or
even defined a blank password on the domain side and in the ISM for the
Default Web Site. If anything other than Anonymous authentication is used a
dialog box appears, and account used fails with a 401.3 error after three
attempts, even though the log files show a successful auth. Anonymous
Account used has Read access to the share and files, authed account has Full
Control as defined in NTFS permissions.
:
: IIS6 servers are trusted for delegation in a 2000 AD Domain. So I'm not
certain what I am missing, as I can access the UNC share via ISM, and from
the server, just not through HTTP, even if authenticated as domain admin. I
believe the only time it did work is if I defined the UNC to be mounted as
the Domain Admin via the ISM, but that would essentially give an anonymous
account full control over the share, not to mention it would be a management
nightmare when admin account passwords are updated.