IIS 訪問需要使用者名稱和密碼 （需要進行身份驗證）
接下來在其他計算機或更改本機訪問地址為自身IP後（例如58.129.1.80/1.htm）卻出現了一個要求輸入使用者名稱和密碼的對話方塊，這就是上文網友遇到的問題。（如圖2）
實 際上對於一個站點我們訪問他應該不需要輸入使用者名稱和密碼的，站點訪問都應該是匿名的。就算我們在對話方塊中輸入了相關的使用者名稱和密碼也無法通過驗證，頁面 會顯示——“您未被授權檢視該頁，您不具備檢視該目錄或頁面的許可權，因為訪問控制列表ACL對WEB伺服器上的該資源進行了配置”。（如圖3）
（2）故障分析：眾所周知在我們安裝IIS元件服務後系統中會自動新增兩個帳戶，一個是IUSER_計算機名（internet來賓帳戶），另外一個是IWAM_計算機名（啟動IIS程序帳戶）。（如圖4）
平 時訪問頁面的許可權和帳戶分配都是由IUSER_計算機名（internet來賓帳戶）來完成的。如果我們訪問時要求輸入使用者名稱和密碼的話很可能是該帳戶 資訊被改，例如密碼被一些軟體或病毒所修改，這時我們能做的就是重新解除安裝並再次安裝IIS元件，畢竟IUSER_計算機名（internet來賓帳戶）用 戶密碼是在安裝元件過程中由系統自動生成的，我們不可能通過手工設定的方法重置。（如圖5）
（3） 故障排查：如果重新安裝IIS依舊不能解決問題的話，故障根源就不在於IUSER_計算機名（internet來賓帳戶）了，我們應該從目錄許可權下 手解決問題。找到 我們要釋出的頁面所在資料夾（網站目錄），然後在其上點右鍵選擇“屬性”，在開啟的屬性視窗中找到“安全”標籤，如果這裡沒有IUSER_計算機名 （internet來賓帳戶）訪問許可權的存在，那麼問題就在於此。（如圖6）
我們通過“新增”按鈕選擇使用者列表中的IUSER_計算機名（internet來賓帳戶），將其新增到目錄許可權訪問設定視窗中。（如圖7）
接下來根據實際需要針對IUSER_計算機名（internet來賓帳戶）帳戶對該目錄的訪問許可權進行設定，一般就給予讀取許可權即可，切忌給予太高的許可權，否則訪問網站使用者很可能會刪除頁面檔案或者直接上傳木馬程式。（如圖8）
添 加相應許可權後就可以有效的解決訪問IIS釋出站點總是彈出使用者名稱和密碼驗證視窗的故 障。總的來說就是在我們要釋出的站點目錄上設定相應的訪問許可權，其 NTFS許可權中對應的IUSR_計算機名為讀取許可權。如果預設站點目錄在c:inetpubwwwroot下則不會涉及到此問題，這也是為什麼大部分 使用預設站點對外發布不會出現此問題的原因。 （4）幾點補充：
除了以上幾個容易設定錯誤造成訪問IIS釋出的WWW站點出現使用者名稱與密碼提示外，在IIS設定中如果配置不當也會出現上述問題。例如在IIS中“網站”上點右鍵選擇“屬性”，然後找到“目錄安全性”標籤，接下來點“身份驗證和訪問控制”。（如圖9）
在身份驗證方法視窗中啟用匿名訪問，這樣才能夠開啟在訪問WWW站點時使用IUSER_計算機名（internet來賓帳戶）帳戶來瀏覽頁面資訊。另外記得不要點下面的“整合Windows 身份驗證”。（如圖10）
還 有一點要注意的就是在網站屬性視窗中有一個“主目錄”標籤，在該標籤下我們可以檢視釋出目錄對應的許可權，記得一定要合理分配好，如果不小心給予了寫入和 目錄瀏覽許可權，那麼你釋出的站點很容易被攻擊，當然這裡如果沒有新增讀取許可權，那麼你的站點在別人訪問時同樣會出現不具備相關許可權的錯誤提示。（如圖 11）
筆者同事所用機器的IIS最近出了問題，訪問本地ASP檔案時用“http://localhost”或“http://計算機名”可以正常訪問，但如果用“http://127.0.0.1”訪問，就會彈出一個對話方塊要求輸入密碼。
因為只是用IP地址不能正常進行訪問，所以感覺不會是大問題，根據以往的經驗，首先檢視使用者組中的“IUSR_計算機名”、“IWAM_計算機名”兩個賬號是否被禁用了，結果發現狀態正常。
接下來懷疑是IIS預設網站屬性中“匿名訪問和身份驗證控制”（在“目錄安全性”選項卡中）一項被不小心禁用了，開啟相應對話方塊後發現並未禁用。難道是匿名訪問賬號（IUSR_計算機名）的密碼與使用者組中的密碼不同步了？手工進行同步設定後，發現問題依舊。
IIS出現類似問題的原因不外乎這幾種啊，還能是什麼原因呢？沒有辦法，乾脆重灌 IIS！幾分鐘後，IIS安裝完畢，但一試卻發現，剛才還只是用IP地址不能訪問，結果現在用計算機名也不能訪問了，總是提示DCOM+錯誤。檢視系統日 志，顯示為“DCOM遇到錯誤。登入失敗: 未知的使用者名稱或錯誤密碼”。
為了避免重新安裝系統，筆者決定查詢並修復這個DCOM錯誤。進入控制面板的“組 件服務”中，發現“DCOM配置”上有紅箭頭標誌，不能正常開啟，看來問題就出在這兒。但是怎麼處理呢？在經過多次無效的嘗試後，筆者終於找到了解決的辦 法：檢視系統的本地服務，發現DCOM正常；然後檢視其依存關係，發現依存於“Remote Procedure Call (RPC)”服務；進一步檢視RPC的狀態，發現狀態正常；再看RPC的依存關係，現在與其相關的“Distributed Transaction Coordinator”服務是禁止的，其描述為“協調跨多個數據庫、訊息佇列、檔案系統等資源管理器的事務”。將其開啟後，發現IIS馬上就可以用多種 方式進行訪問了。
事後得知，原來同事曾經在網上看到一篇關閉Windows不常用服務的文章，於是 就把系統中的一些服務關閉了，其中就包括“Distributed Transaction Coordinator”服務。今後大家如果想關閉不常用服務以優化系統時，可千萬要小心，拿不準的還是不要關為好。
小編提示：DCOM 是Microsoft的分散式COM技術，擴充套件了元件物件模型（COM）技術，使其能夠支援在區域網、廣域網甚至Internet上不同計算機物件之間的通訊。
RPC是“遠端協助”（Remote Procesdure Call）的英文簡稱，是微軟在Windows XP系統中新增的功能，允許遠端使用者對本地PC進行控制，幫助本地使用者解決問題。去年大名鼎鼎的衝擊波病毒就是利用Windows XP的RPC漏洞進行攻擊的。
另有一情況，當C盤為NTFS分割槽時，釋出目錄放在C盤也會出現這樣的情況