"Massimo" <barone@mclink.it> wrote in message
news:uTD$zXreDHA.3528@tk2msftngp13.phx.gbl...
> Here's a summary of the troubles I'm experiencing, of which I've been
talked
> in a previous thread. Now I'm posting again explaining all about my
> security-related configuration, so maybe someone can help me out of this.
> Here's the full story. I wanted to have my websites on another drive than
> the main one, so I first installed IIS and then Microsoft Exchange (I need
> OWA on my domain's main website), then I created a "web sites" dir on my
D:
> (data) drive, configured permission (hopefully in the right way, but see
> later) and then I created a "www.mydoman.com" subdir inside it, where I
> moved all of the contents of the original wwwroot. I then renamed the
> Default Web Site (the one under which Exchange created its virtual
subdirs)
> to "www.mydomain.com", told it to respond only to requests with host
headers
> "www.mydomain.com" and point its home directory to "D:\web
> sites\www.mydomain.com". Then I created new subdirs for every website I'm
> hosting on this server (D:\web sites\www.anotherdomain.com"). In the IIS
> configuration, I configured each website's home directory to be the proper
> one. Then, for some DB-access related reasons, for each website I
configured
> the account under which IIS's anonymous connections operate to be an AD
user
> I created only for this purpose (which I gave access to the DB I'm using).
> Now, everything works fine (eight websites), except I'm having some
> authentication troubles on this server when I use Windows integrated
> authentication for some webpages. When I enable it, on the main site, for
> example, the website works only if I access it with URL http://www, and
not
> if I access it with http://www.mydomain.com. The same is true for every
> other website or subdirectory I try to enable Windows authentication on
> (http://test but *not* http://test.mydomain.com). Standard authentication
> works fine everytime.
> Everyone of these websites is configured to accept requests both for its
> short name and its FQDN, of course.
> Can it be a NTFS permission-related problem ? I gave full control to
> administrators, web developers and SYSTEM, and I gave read permissions to
> the IIS service accounts I'm using for websites (except for some of them
> which actually *write* in their directory... I gave full control to their
> service accounts); but I saw the standard permissions for wwwroot include
> many more things... which of them are actually required for IIS to operate
?
> I tried the same with another webserver I'm running, where I didn't change
> anything about security from the default configuration, and everything
works
> fine there using Windows authentication, both with http://servername and
> http://servername.mydomain.com; so I think the problem should be related
to
> the changes I made...
>
> Please help me on this if you can, thanks.
>
> Massimo
>

"Massimo" <barone@mclink.it> wrote in message
news:u4mCJqteDHA.1700@TK2MSFTNGP10.phx.gbl...
> "Karl Levinson [x y] mvp" <levinson_k@despammed.com> ha scritto nel
> messaggio news:u8k2S0seDHA.1736@TK2MSFTNGP12.phx.gbl...
>
> > I believe that's a problem with your web browser configuration. Your
> > browser is probably set by default to allow windows integrated
> > authentication for local intranet zone. This particularly seems to
happen
> > with IE on XP but may also happen with others. The fix would be to
access
> > the site with the "www" server name or to go into each web browser's
setup
> > [e.g. Tools, Internet Options, Security if you're doing this manually,
or
> > try using active directory group policy, a .REG file or the MS IEAK to
> > automate settings changes] and add yourdomain.com to the local intranet
> > zone.
>
> Sorry, but I don't think this is the case: as I said, everything works
fine
> when I access my other webserver with its FQDN.
> Thanks anyway.
>
> Massimo
>

> When you say "it doesn't work", what exactly is the problem?

> I believe that's a problem with your web browser configuration. Your
> browser is probably set by default to allow windows integrated
> authentication for local intranet zone. This particularly seems to happen
> with IE on XP but may also happen with others. The fix would be to access
> the site with the "www" server name or to go into each web browser's setup
> [e.g. Tools, Internet Options, Security if you're doing this manually, or
> try using active directory group policy, a .REG file or the MS IEAK to
> automate settings changes] and add yourdomain.com to the local intranet
> zone.

"Massimo" <barone@mclink.it> wrote in message
news:u4mCJqteDHA.1700@TK2MSFTNGP10.phx.gbl...
> "Karl Levinson [x y] mvp" <levinson_k@despammed.com> ha scritto nel
> messaggio news:u8k2S0seDHA.1736@TK2MSFTNGP12.phx.gbl...
>
> > I believe that's a problem with your web browser configuration. Your
> > browser is probably set by default to allow windows integrated
> > authentication for local intranet zone. This particularly seems to
happen
> > with IE on XP but may also happen with others. The fix would be to
access
> > the site with the "www" server name or to go into each web browser's
setup
> > [e.g. Tools, Internet Options, Security if you're doing this manually,
or
> > try using active directory group policy, a .REG file or the MS IEAK to
> > automate settings changes] and add yourdomain.com to the local intranet
> > zone.
>
> Sorry, but I don't think this is the case: as I said, everything works
fine
> when I access my other webserver with its FQDN.
> Thanks anyway.
>
> Massimo
>

"Massimo" <barone@mclink.it> wrote in message
news:u4mCJqteDHA.1700@TK2MSFTNGP10.phx.gbl...
> "Karl Levinson [x y] mvp" <levinson_k@despammed.com> ha scritto nel
> messaggio news:u8k2S0seDHA.1736@TK2MSFTNGP12.phx.gbl...
>
> > I believe that's a problem with your web browser configuration. Your
> > browser is probably set by default to allow windows integrated
> > authentication for local intranet zone. This particularly seems to
happen
> > with IE on XP but may also happen with others. The fix would be to
access
> > the site with the "www" server name or to go into each web browser's
setup
> > [e.g. Tools, Internet Options, Security if you're doing this manually,
or
> > try using active directory group policy, a .REG file or the MS IEAK to
> > automate settings changes] and add yourdomain.com to the local intranet
> > zone.
>
> Sorry, but I don't think this is the case: as I said, everything works
fine
> when I access my other webserver with its FQDN.
> Thanks anyway.
>
> Massimo
>

"Massimo" <barone@mclink.it> wrote in message
news:uTD$zXreDHA.3528@tk2msftngp13.phx.gbl...

> PS I'm not sure I completely understand your setup, but if http://www
serves
> up the exact same files in the exact same web server instance that
> http://www.mydomain.com serves up, then that was my reason for thinking
> this was not an NTFS file permission issue.

> If you're running URLScan, you might also want to check the URLSCAN.LOG
file
> just in case to make sure URLScan isn't blocking your access to pages.

> There was at one time an issue with URLScan which caused it to block
> requests to URLs with no file name specified, e.g. mydomain.com does not
> work but mydomain.com/default.htm does. If this did happen to be your
> problem, the fix is in a MS knowledge base article mentioned at
> http://securityadmin.info/faq.htm#urlscan

> It sure sounds like an NTFS permissions issue to me.

> I just re-read your origianl post, haven't gone through all the replies
but
> is the AD user account a member of the guests group? Just out of
> curiousity, have you tried to log into the box with the user account that
> you are using for anonymous access? This user account also needs
> to have Log on locally rights..

"Massimo" <barone@mclink.it> wrote in message
news:uKp%23SAyeDHA.944@TK2MSFTNGP11.phx.gbl...

> : There's another thing I said and nobody replied to, so I'll repost it:
> : when I try my failing logins, I specify my username as "username"
> : or as "mydomain.com\username". But, when the dialog box returns
> : asking again for a valid login, it writes my username as
> : "mycomputer\username", where "mycomputer" is the name of the
> : computer I'm logging in *from*, i.e., the computer I'm sitting at.
> : Any thoughts about this ?
>
> Enter your username as either:
>
> myDomain\Username (pre Windows 2000 domain authentication)
>
> -or-
>
> username@myDomain.local (Windows2000 authentication)

"Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> wrote in message
news:u22jJ%233eDHA.2260@TK2MSFTNGP10.phx.gbl...
> I assume that after three goes, you get the "Access Denied" error message?
>
> If so, is there anything in the Windows Event Log? (IIRC Logon Failure
> auditing is enabled by default on a Windows 2003 machine).
>
> Lastly, the account you are trying to logon on - it has NTFS permissions
to
> the files/resources that need to be accessed? (you may wish to use
filemon
> from www.sysinternals.com to check this).
>
> It sure is an odd problem...
>
> Cheers
> Ken
>
> "Massimo" <barone@mclink.it> wrote in message
> news:OOqOh13eDHA.1088@TK2MSFTNGP10.phx.gbl...
> : "Ken Schaefer" <kenREMOVE@THISadOpenStatic.com> ha scritto nel messaggio
> : news:uU18noyeDHA.3788@tk2msftngp13.phx.gbl...
> :
> : > : There's another thing I said and nobody replied to, so I'll repost
it:
> : > : when I try my failing logins, I specify my username as "username"
> : > : or as "mydomain.com\username". But, when the dialog box returns
> : > : asking again for a valid login, it writes my username as
> : > : "mycomputer\username", where "mycomputer" is the name of the
> : > : computer I'm logging in *from*, i.e., the computer I'm sitting at.
> : > : Any thoughts about this ?
> : >
> : > Enter your username as either:
> : >
> : > myDomain\Username (pre Windows 2000 domain authentication)
> : >
> : > -or-
> : >
> : > username@myDomain.local (Windows2000 authentication)
> :
> : Tried both of them too, the problem remains.
> :
> : Massimo
> :
>
>

"Massimo" <barone@mclink.it> wrote in message
news:e9BqVy7eDHA.1760@TK2MSFTNGP09.phx.gbl...

> That seems a quite reasonable point, but then, why is this not happening
> when I access my other server ?
> Howewer, I tested this... in both cases, the browser recognizes
> http://servername as an Intranet address, and
http://servername.mydomain.com
> as an Internet one. But integrated authentication works with one server
and
> not with the other...

> > Checking the IIS logs and the windows auditing /
> > Security logs might also help you confirm or deny this.

> I assume that after three goes, you get the "Access Denied" error
> message?

> If so, is there anything in the Windows Event Log? (IIRC Logon Failure
> auditing is enabled by default on a Windows 2003 machine).

> Lastly, the account you are trying to logon on - it has NTFS permissions
> to the files/resources that need to be accessed? (you may wish to
> use filemon from www.sysinternals.com to check this).

> It sure is an odd problem...

> I still don't think you should be so quick to dismiss the possibility that
> the web browser configuration for the local intranet zone is causing the
> problem. It sure seems to me that the browser is sending windows
> authentication correctly for http://www and not for www.domain.com, and it
> seems to me that at least part of the cause for this is most often the
> browser not recognizing www.domain.com as being part of the domain
> containing the workstation and the user currently logged into Windows.
> Correct me if I'm wrong, but as far as I can tell from your description,
> both www and www.domain.com are identical as far as both the IIS MMC
> and the NTFS file permissions are concerned. If so, that leads me to
> the client, starting with the browser.

> Checking the IIS logs and the windows auditing /
> Security logs might also help you confirm or deny this.

"Massimo" <barone@mclink.it> wrote in message
news:OOqOh13eDHA.1088@TK2MSFTNGP10.phx.gbl...

> > That seems a quite reasonable point, but then, why is this not happening
> > when I access my other server ?
> > Howewer, I tested this... in both cases, the browser recognizes
> > http://servername as an Intranet address, and
> > http://servername.mydomain.com as an Internet one. But integrated
> > authentication works with one server and not with the other...
>
> I'm not sure if any of these apply to you, but is there any chance the two
> servers are in two different subnets, and the IP address of the old server
> is recognized by the computer / browser as being local while the new
server
> is on a different subnet that is not considered local by your browser?

> Or, could someone have already configured your browser to recognize
> the old server in the local intranet zone?

> Or, [and this seems less likely to me] is your DNS set up to resolve www
> and www.domain.com as different IP addresses, and the second IP address
> is routed through a different device like a proxy or NAT firewall that
somehow
> interferes with the authentication?

> > > Checking the IIS logs and the windows auditing /
> > > Security logs might also help you confirm or deny this.
>
> Well, RE: the www logs, try accessing the server both successfully and
> unsuccessfully, and then immediately open the logs using Notepad or Excel
> and compare the two accesses. [Using Excel should give you column headers
> notating what each column means.] It should be pretty plain the URL that
> was used, the user name that was attempted, and some kind of 40x error for
> failure or 200 message for success near the end of the entry. If you have
> no www logs or are unsure of the location, check the IIS MMC.

"Massimo" <barone@mclink.it> wrote in message
news:OZ9nAv7eDHA.560@tk2msftngp13.phx.gbl...

> Hmm - can you post the Event ID and Event descriptions from the
> Windows event logs?

> (I'm kinda grasping at straws here. We may need to put a trace on the
> traffic so see what's actually going back and forward, but I'd rather not
> look at hundreds of lines of traffic if we can find a clue to the problem
> someplace else!)

"Massimo" <barone@mclink.it> wrote in message
news:%23hnP4iEfDHA.3200@tk2msftngp13.phx.gbl...

> Hmm - can you post the Event ID and Event descriptions from the
> Windows event logs?

> (I'm kinda grasping at straws here. We may need to put a trace on the
> traffic so see what's actually going back and forward, but I'd rather not
> look at hundreds of lines of traffic if we can find a clue to the problem
> someplace else!)