Integrated Security fails using machine name, succeeds using FQN -- iis security

iis security : Integrated Security fails using machine name, succeeds using FQN

Seth Petry-Johnson
6/5/2008 1:02:04 PM

Active Directory: BAR.COM
Webserver: FOOWEB, IIS 6, single static IP address, running a single ASP.NET
website. Contains a virtual directory (called "/protected") with Integrated
Security as the only authentication option.

When logged in locally to FOOWEB, pointing IE to
http://fooweb/protected/default.aspx works. The user is authenticated
automatically.

From another machine [FOOBAT], same domain, same local network, same user
account, browsing to http://fooweb/protected/default.aspx causes the
username/password prompt to appear. THE USER CAN NOT AUTHENTICATE, even if he
manually enters his credentials!

On FOOBAT, the authentication DOES work if the user points IE at the fully
qualified name http://fooweb.bar.com/protected/default.aspx! [*.bar.com is
registered for local intranet zone]

Some observations:
1) The username prompt contains the FQN "fooweb.bar.com".
2) On FOOBAT, IE is in Intranet mode in both scenarios.
3) User is a domain admin and can access fileshares on FOOWEB, this is
certainly an IE/IIS issue.

David Wang
6/5/2008 8:31:56 PM

On Jun 5, 1:02=A0pm, Seth Petry-Johnson <Seth Petry-
[quoted text, click to view]

Make sure fooweb is actually getting to the correct server when access
from foobat. If it is, check the IIS log files on fooweb when the user
fails to authenticate from foobat. Provide the HTTP status, substatus,
and Win32 error code. That is what you need to troubleshoot.

The sequence of error codes from the IIS log file tells you what sort
of issue you have.

Based on your information, this is certainly not an IE/IIS issue and
almost certainly a user/misconfiguration issue. I am looking at the
IIS6 web server doing what you claim is not possible, so there must be
something misconfigured in your environment.

//David
http://w3-4u.blogspot.com
http://blogs.msdn.com/David.Wang

VC
6/19/2008 5:43:00 AM

I think you have an SPN problem. Is the application pool running under a
domain account? If so, make sure you have an spn registered for:

HTTP/foobar
HTTP/foobar.bar.com
HTTP/fooweb
HTTP/fooweb.bar.com

by running setspn -l domain\user. If anything is missing, correct this by
running:

setspn -A HTTP/foobar domain\user
setspn -A HTTP/foobar.bar.com domain\user
setspn -A HTTP/fooweb domain\user
setspn -A HTTP/fooweb.bar.com domain\user

If your app pool is running under a system account, make sure an spn is
registered for the DNS alias to the machine name by running setspn -l foobar.
The results should be:

HTTP/foobar
HTTP/foobar.bar.com
HTTP/fooweb
HTTP/fooweb.com

If anything is missing, the syntax is similiar as above:

setspn -A HTTP/fooweb foobar
setspn -A HTTP/fooweb.bar.com foobar
setspn -A HTTP/foobar foobar
setspn -A HTTP/foobar.bar.com foobar

Please let me know if this helps.

[quoted text, click to view]

Seth Petry-Johnson
6/19/2008 6:30:03 AM

Just yesterday I received an email back from my customer saying they had
figured out the configuration. They say the solution was to configure the
domain account as (1) trusted for delegation, (2) a member of IIS_WPG group
on FOOWEB, and (3) has "Act as a part of OS" / "Impersonate a client after
authentication" privileges.

Windows security is a little out of my purview, so I'm not 100% sure why
this works. I'm just glad it does :)

For posterity, here's the pattern I observed:

FROM FOOWEB, BROWSING TO FOOWEB:
--------------------------------------------
Using machine name only [http://fooweb/ProtectedVDir]: OK
Using FQDN: [http://fooweb.blah.com/ProtectedVDir]: FAIL
Using alias: [http://MyAlias.blah.com/ProtectedVDir]: OK

FROM CLIENT MACHINE, BROWSING TO FOOWEB:
--------------------------------------------
Using machine name only [http://fooweb/ProtectedVDir]: FAIL
Using FQDN: [http://fooweb.blah.com/ProtectedVDir]: OK
Using alias: [http://MyAlias.blah.com/ProtectedVDir]: FAIL

I can't explain why the FQDN does NOT work when local to the webserver...
could this be related to the SPNs?

VC
6/19/2008 6:46:02 AM

Glad that you solved the problem. Just as an answer to why you need those
settings: Trusted for delegation means that the account can forward
credentials to another server. Without this, the client's credentials are
lost between the web server and the database server. IIS_WPG group allows
the account the proper permissions to run the IIS components. You should
only need "Impersonate a client after authentication", as this allows
impersonation to occur under the context of the domain account. System
accounts already allow this by default, so this is only needed for the
domain. "Act as a part of OS" allows impersonation before the client is
authenticated, and shouldn't be necessary.

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about iis security

View Other Months
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008

home · blog · groups

Questions? Comments? Contact the dn