Windows Forum

Ask something
Discussion Locked

IIS4 NTFS Permissons

0 helpful
17 replies

by lordinfidel

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

Problem: In a user/password protected directory (website directory), the user, when authenticated) is allowed into the directory but is not allowed access to a .asp file in the same directory. (prompts for u/p)

Platform: IIS4 on NT4 srvr with sp6a. Is the PDC for web farm domain. Web farm has 3 other servers, all BDC's for the domain. Replication exec also running on all servers.
All servers contain identical software and sp's.

Has it ever worked: Yes, never had a problem until now.
Background details: We created a user and added him to the directory. In ISM we specied NT authen, no anon to that directory.

When we go to the directory it authenticates ok with the user. But when we try to access an asp file in the same directory we get an access denied after the 3rd attempt.

We verified that the user has read permsissions. We also tried change and full. ISM permissions for that file were standard read. Also tried write.

Any user we create and add to it gets the same result EXCEPT 1. The standard user that we have used for the past year can get in ok when assigned the same permissions as the user we created.

When we set up auditing on both users, I set it up so that it audits failure on the correct user and sucess on the standard user.

In Event editor/Security we receieve an event ID 576 which equals a success for that user at the time it tries to access the asp script. (the asp script is called thru post in an html doc and is supposed to create and send an e-mail, pretty standard nothing fancy)

We have tried recreating recreating the directory from scratch, recreating the user, copying the new user from the one that works.

We commented out the part of asp script that calls an external object to create the e-mail.

Continued below...

17 replies

by lordinfidel

Continued from above...

I tried CACLS to change the permissions on the directory.

We also looked in the IIS logs. The standard user was allowed to post but the correct user was not.

We limited our efforts to the 1st web server to eliminatethe possibilty of the requests going to the other servers.

We checked the User Rights in USRMGR and verified that there was nothing weird going on.

I have been able to password protect pages on these servers a million times using the exact same method.

I will be trying to reapply SP6a, that is without question... So any other suggestions, theories will be greatly appreciated and points awarded.

by dkpalmer

Just a thought - since it fails after the third attempt at login, it sounds like there is a resource being accessed for which the original user has rights but not the new users. What happens when the page is accessed - you mentioned an e-mail send. I'd start by following the entire sequence from initial access on and look at anything that accesses/runs/starts/uses a process/program and see if the new users have rights to all the resources needed to complete each access/program/process.
I'm guessing your page is calling a program or process to which the new users don't have rights.

by lordinfidel

That is what I originally thought.

But the object that the asp script is calling is located in an area that "everyone" has full rights to.
(to be on the safe side we commented out that part of the script)

Here is the steps from beginning to end.
User a = the correct new user
User b = old standard user that works

I go to the website www.blah.com/directory

I am prompted for a user name and password.

I enter in user "a". I then proceed to default.html with no problems.(www.blah.com/directory/default.html)

I then proceed thru the next 8 pages with no problems as user a. I then get to the last page
(www.blah.com/directory/lastpage.html)

lastpage.html is a form that posts to thankyou.asp.

Once I press submit on lastpage.html, I am then prompted for a user name and password again (?????????????).

I enter in user a's info again and I get kicked back. Twice more for good measure and I then receive the no access error. (does not look like a standard http 403 error either)

Now, lets though in the horse shoe.
I'm back at lastpage.html, press submit, get the login box again(???????) enter in user b, and VOILA' it works.

Now lets get crazy....

Start from the beginning but enter as user b. Press submit on lastpage.html and lo and behold "No password box" It behaves the way it was developed.

From all accounts it is not even getting to the asp script. NTFS permissions is preventing it from opening it. Which makes no sense since user a is there in the security properties with the same permissions as user b.

Microshaft has struck again.

Any other thoughts.......... Sorry for the unacceptable but that is the only way I can post a message.

by gregory w. smith

Since the standard user works, does a *COPY* of the standard user also work? Can you then rename the working copy to the current name for the 'correct' account?

Just a thought. I have ways to work around LOTS of problems....

by lordinfidel

Nope... Tried that avenue also.

<-----From orginal--->
We have tried recreating recreating the directory from scratch, recreating the user, copying the new user from the one that works.
<----end--->

I have tried every trick up my sleeve to get this to work. There is something in the OS that is messing up.

I just finished reaplying SP6a but still no correction.

Any other suggestions (besides reinstalling the OS, since this is a PDC)

I have been unable to find any tech docs on it but will be very interested in them if someone finds something in knowledgebase or the MSDN.

by gregory w. smith

Okay... I'll try once more, then off to the roads.

Have you stopped and restarted the IIS services after making these changes? Or even rebooted? (I'm assuming you have, but this is a classic sympton of the service not recognizing new permissions.)

It's worth a try, as it is the standard answer to such trouble. On the other hand, you've probably done it, because it's the standard answer...

by lordinfidel

Yeah.... You guessed it.... Tried both...

Stopped/Restarted the web site

Rebooted after the new apply of SP6a.

Still nothing.

Grrrrrrrr.... But don't give up on this one. Sleep on it.

by todd

Several suggestions:
1.) check the authentication level set to the ASP page from within IIS.
open IIS, find your asp page located in the website, then right click and properties, File security, and edit the anonymous access. Is it set to allow anonymous? If not maybe try that, since the directory itself is restricted. (might be a temporary work around.)

you could then set the anonymous logon for the asp page to be User b (the one that works)

Does user b have logon locally rights?
I would try that also

Is there any other differences between these two users? are they both a member of Administrator? or domain user? or any other groups? similiarities or differences?

by lordinfidel

Thanx for trying..

I covered those areas already. This is something that is hiding well beneath the surface.

That directory (and all files in it) has NT auth only. The IUSR accounts have been removed from NTFS permissions to that directory and files leaving only administrators, user a and b.

I'm looking for a clue..something very basic in the OS that is messing up.

Auditing is set for that the user to audit read/write/change failures to the asp file but it comes up as a sucess.
(Event ID 576)??????????? Why I do not know. It should be a failure.

The error message it returns is not an IIS 403 message.

Error: Access is Denied

And that is it.

by zk

This is tough. But, the points seem too tempting to resist :-)

Despite the very detailed explanation on your part, I still have more questions than answers. So please bear with me.

1. When you are testing the web pages (both asp and html) using a browser, are you using a browser on a different computer (a member workstation in the web farm domain)? same computer (PDC)? or a computer in some other domains (any trust between these two domains?) or workgroup? What OS is your browser running on? If you're using 9x to test, what is the workgroup on that computer set at?

2. I assumed you've script access for the directory and the ASP in question, in ISM.

3. Is it correct you're only using NTLM (Challenge/Response). Anon, and Basic authentication is unchecked for that directory only in ISM? What does, the global and site and service directory security look like?

4. When you're prompted the first time when accessing the html, do you get a prompt with user, pwd, and domain fieldor without the domain field? If there is no domain field, have you tried logging in as domain\userA format at both prompts, that is for both asp and html?

5. What is the exact error message, that is, 40x.x? And the name?

6. In your ASP scripts, you have mentioned about creating email. Are you sending the text in the form, to the ASP page, which talks to a SMTP server? In other words, does your ASP page use, SMTP running on another serever? If so, what is the SMTP's directory security in ISM look like? What is the SMTP->Delivery->Outbound security set at?

7. Is there any thing at all in that ASP page that use something like a file, a cgi, a database located on other servers? Say a mapped drive, a virtual directory?

8. Is there anything in the ASP script that uses a UNC path to locate a local file on the PDC? That is, using \\PDC\share instead of C:\file?

by zk

Some suggestions here.

1. Seems to me you have a IIS delegation problem.

2. Please go to http://msdn.microsoft.com/workshop/server/feature/security.asp and download the article.
It seems to be right on your problem.

3. Go to http://www.somarsoft.com and download DumpSec. Install it. If you're worry about doing it on PDC, install it on another test computer that is part of the domain. Then run DumpSec->Reports->Select Computer->Your PDC. Then run the rights, groups, users dumps. Compare userA and userB in rights, groups, permissions. You can export them as CSV and sort them in Excel. Compare them side by side. Is there one right userB has that userA doesn't. Both should have "access this computer from network" rights for NTLM. Ifbasic authentication is also checked in ISM, you need "logon local" as well.

4. Since you're using NTLM only, IE will submit username, domain name, password hash (not the actual password) to the IIS. IIS will get the incorrect domain name and won't know what to do with it. Correct domain name is required to be passed on to IIS for NTLM. But, IE will do this without your knowledge. Since you might not be provided a prompt for domain, try accessing domain\userA for both of the prompts. Test this logging into a computer in web farm NT domain as well.

5. Please, please, read that Microsoft paper in #2. It is too much to post here.

6. The papers here are also useful in your situation http://www.microsoft.com/isn/whitepapers/security.asp.

Well, hope that helps.
If there is anything I can help further, email, zaw@trdesk.com.

Good luck.

by lordinfidel

Answers to Zaw's Questions.

1. no 98/95 machines. Tried it on w2k/NT4 wkstn and srvr with the same results. The web servers are in their own domain "wsd". NO trusts exist with any other domain in the enterprise. All web servers are bdc's in the domain. same result occurs on each machine. the pdc is the main deployment point for all of our sites and replication between them is controlled by replication exec.

I limited my tests to the pdc but the same results can be achieved by goingto any of the machines. These are for the extranet not intranet.

2. Yes the directory has script access.

3. For that directory only NT authen is currently checked. Originally I left the defaults, both anon and NT, just removed the IUSR accounts from the directory/files.

4. I get all 3 fields...U/P/D

5. Not a standard IIS answer, which is why this is puzzling.

6. I attached the asp so you can look at it. It's pretty standard stuff. It creates the email locally via a local object. No external smtp server, just local IIS smtp. Everyone has rights to the object, was second thing I checked.

7. Same as 6... No external mapped drives. One of my first theories also.

8. Same as 6...

This discussion is closed to new replies.