I think the rule of thumb here is to always configure the security from within
Central Admin and NOT IIS. I did something very simliar to what you are
describing. We created a publishing site  (template-collaborate) and, then from
the browser uploaded a number of HTML static pages to the site via the "All Site
Content". I created a folder within the "Style Library" for my custom CSS,
images. My .HTML I put in the "Pages" folder. To link to the images  etc I used
[href="/Style%20Library%2fMyFolderName/MyCustomFile.css"].

After that I open SPD, check out the files, and edit away....be sure to save-all
and then check-in.

Since I have AA turned on at the site collection level, pages load with no
prompt. Not sure if this is best practice...but, it's work in progress.

Still trying to master the whole custom master page  stuff..... this solution was
a quick band-aid work around.

Yes I have it turned on in the SC went back and double checked this, I am
only running WSS 3.0, so I have to set  the master page  with SPDesigner, I
used the built-in rgt click set as home  page and that is when it started
prompting me for login, my page is completely made of html no dynamic code,
it renamed the orgininal default.aspx to default-old.aspx and it works as
long as you log in! Not understanding why? The IIS settings have anonymous
enable, I checked and So does the Site collection? I reset the page back to
default.aspx with SPDesigner but now if you hit the root domain it is asking
for a login but allows anonymous access  browsing to the default.aspx page?
i.e. if I go to www.mydomain.com" target="_blank" rel="nofollow">www.mydomain.com I get the login prompt, but if I go to
www.mydomain.com" target="_blank" rel="nofollow">www.mydomain.com/default.aspx i can see the sign in and do not get the login
prompt? Any idea on how to fix back to original (no login prompt  when
hitting www.mydomain.com" target="_blank" rel="nofollow">www.mydomain.com), what did SPDesigner do exactly when I set
default.htm as the home page?

When you use Designer to set  your home page  etc, it copies what is needed to the
content database of the site  collection and "customizes" the page in question.
You say you set the master page, so that's where your customization is coming in
to play. Instead of referencing the Masterpage located on your server, the site
now points to a customized Masterpage that sits in the content database for the
site. If you look at it again in Designer you should have the option to reset to
site definition.

I'm guessing that there is something with the permissions on the site that are
prompting for credentials. Could be one of the libraries that contain the
affected pages. Wish I could be more specific.

I did this and it did reset very
thing so as it derived from the 12Hive instead of the Database
(ghost/un-ghost & customized/un-customized) but the issue with the
permissions actually was still showing up at the root domain which is weird,
I did some Google-ing and found that the 403.1 error  was a file permission
error where a IIS doesn't have permissions to read, write, etc. on the FILE
location where the virtual directory is pointing to:

Error 401.3 you do not have permission  to view  this directory or
page using the credentials you supplied (access denied  due to access  control
lists). Ask administrator to give you access to

-------------------------------
c:\............\wss\virtualdirectories\81
-------------------------------

I remember reading something about it in some old documentation I saved
about four million SharePoint builds ago, so I looked at the IIS instances
on the dev server vs. production (dev being the one with the error) and
everything was ok then I decided to look at the
c:\............\wss\virtualdirectories\81 file permission themselves and on
the production server there was the problem. The IIS guest account had been
removed from the dev server. On the Production server the folder had this
account added  """Internet Guest Account(SERVERNAME\IUSR_SERVERNAME)""" with
permissions of read & exec, list folder contents, and Read. But the server
with the problem (Dev server) did not have this account added to it at
ALL!!!! Hmmm, I understand now where the error event was coming from!!!

Solution was to add the SERVERNAME\IUSR_SERVERNAME acct to
c:\............\wss\virtualdirectories\81 folder with the correct
permissions, better question is did SharePoint Designer really do that!!! I
was using it with the admin account of the server so it would have had
permissions to (I know not a good idea to do it with this account but I am
under the gun here!!!)

Anyways just wanted to share my solution in-case anyone runs into this
problem! And thanks again for the quick reply if this was not the issue I
would have definitely needed some more suggestions.

I'll have to file this one away for future reference.