在報告伺服器上設定 Windows 驗證

預設情況下,Reporting Services 接受指定 Negotiate 或 NTLM 認證的請求。 如果你的部署包含使用這些安全提供者的客戶端應用程式和瀏覽器,你可以使用預設值而不需其他設定。 假設你想使用不同的安全供應商來支援 Windows 整合安全,或者你修改預設值並想恢復原始設定。 你可以利用本文中的資訊,在報告伺服器上指定認證設定。

要使用 Windows 整合安全性,每位需要存取報告伺服器的使用者都必須擁有有效的 Windows 本地或網域使用者帳號。 或者,他們必須是 Windows 本地或網域群組帳號的成員。 只要其他網域受信任,你就可以納入來自這些網域的帳戶。 帳號必須能存取報告伺服器的電腦,並被指派角色,才能存取特定的報告伺服器操作。

以下要求也必須符合:

  • RSReportServer.config 檔案必須設定 AuthenticationType 為 RSWindowsNegotiate、 RSWindowsKerberos或 RSWindowsNTLM。 預設情況下,若報表伺服器服務帳號是 NetworkService 或 LocalSystem,RSReportServer.config 檔案會包含該 RSWindowsNegotiate 設定;否則, RSWindowsNTLM 該設定會被使用。 如果你的應用程式只使用 Kerberos 認證,也可以新增 RSWindowsKerberos 。

    Important

    當你使用 RSWindowsNegotiate時,如果你設定報表伺服器服務以網域使用者帳號執行,且沒有註冊該帳號的服務主體名稱(SPN),就會出現 Kerberos 認證錯誤。 欲了解更多資訊,請參閱本主題中 「解決連接報告伺服器時的 Kerberos 認證錯誤 」。

  • ASP.NET 必須設定為 Windows 認證。 預設情況下,報表伺服器網路服務的 Web.config 檔案會包含該 <authentication mode="Windows"> 設定。 如果你改成 <authentication mode="Forms">,Windows 的 Reporting Services 認證就會失敗。

  • 報表伺服器網路服務的 Web.config 檔案必須具備 <identity impersonate= "true" />。

  • 用戶端應用程式或瀏覽器必須支援 Windows 整合安全性。

  • 網頁入口不需要更多設定。

若要更改報告伺服器的認證設定,請編輯 RSReportServer.config 檔案中的 XML 元素與值。 你可以複製貼上本文中的範例,以實作特定的組合。

預設設定在所有客戶端和伺服器電腦都在同一域或受信任域時效果最佳。 而且,報告伺服器部署在企業防火牆後方,方便內部網路存取。 受信任網域和單一網域是傳遞 Windows 認證的必要條件。 如果你啟用 Kerberos 版本 5 協定,憑證可以被傳遞多次。 否則,資格認證只能通過一次,之後就會過期。 欲了解更多關於為多台電腦連線設定憑證的資訊,請參閱 「報告資料來源指定憑證與連線資訊」。

下列指示用於原生模式報表伺服器。 如果您在 SharePoint 整合模式下部署報表伺服器,您必須使用可指定 Windows 整合式安全性的預設驗證設定。 報告伺服器利用預設 Windows 認證擴充套件的內部功能,以支援 SharePoint 整合模式下的報告伺服器。

驗證的延伸保護

從 SQL Server 2008 R2 (10.50.x) 開始,即支援驗證擴充保護。 SQL Server 功能可支援使用通道繫結與服務繫結,以增強驗證的保護。 Reporting Services 的功能必須搭配支援擴展保護的作業系統使用。 你可以透過 RSReportServer.config 檔案中的特定設定來決定延長保護的Reporting Services配置。 你可以透過編輯檔案或使用 WMI API 來更新檔案。 欲了解更多資訊,請參閱與 Reporting Services 進行認證的擴展保護。

設定報告伺服器以使用 Windows 整合安全性

  1. 用文字編輯器開啟 RSReportServer.config。

  2. 找出 <Authentication>。

  3. 複製以下最符合你需求的 XML 結構之一。 你可以指定 RSWindowsNegotiate、 、 RSWindowsNTLM, RSWindowsKerberos 順序任意。 如果你想驗證連線本身,而不是每個請求,應該啟用認證持久化。 在認證持久性下,所有需要驗證的請求在連線期間皆被允許。

    當報表伺服器服務帳號為 NetworkService 或 LocalSystem 時,第一個 XML 結構是預設配置:

    <Authentication>
        <AuthenticationTypes>
            <RSWindowsNegotiate />
        </AuthenticationTypes>
        <EnableAuthPersistence>true</EnableAuthPersistence>
    </Authentication>
    

    當報表伺服器服務帳號不是 NetworkService 或 LocalSystem 時,第二個 XML 結構是預設配置:

    <Authentication>
        <AuthenticationTypes>
                <RSWindowsNTLM />
        </AuthenticationTypes>
        <EnableAuthPersistence>true</EnableAuthPersistence>
    </Authentication>
    

    第三個 XML 結構指定了所有在 Windows 整合安全中所使用的安全套件:

    <AuthenticationTypes>
        <RSWindowsNegotiate />
        <RSWindowsKerberos />
        <RSWindowsNTLM />
    </AuthenticationTypes>
    

    第四個 XML 結構僅對不支援 Kerberos 的部署,或為了因應 Kerberos 驗證錯誤,而指定使用 NTLM:

    <AuthenticationTypes>
        <RSWindowsNTLM />
    </AuthenticationTypes>
    
  4. 將它貼到現有的 <Authentication>條目上。

    你不能用 Custom 在類型 RSWindows 上。

  5. 請適當調整設定以延長保護。 延伸保護預設是關閉的。 如果這些條目不存在,目前的電腦可能沒有執行支援延伸保護的 Reporting Services 版本。 欲了解更多資訊,請參閱與 Reporting Services 進行認證的擴展保護

    <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
    <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
    
  6. 儲存檔案。

  7. 如果你設定了擴展部署,請對部署中的其他報告伺服器重複這些步驟。

  8. 重新啟動報告伺服器以清除目前開啟的會話。

連接報告伺服器時解決 Kerberos 認證錯誤

在設定為 Negotiate 或 Kerberos 認證的報告伺服器上,若發生 Kerberos 認證錯誤,客戶端與回報伺服器的連線會失敗。 Kerberos 認證錯誤已知發生於以下情況:

  • 報表伺服器服務是以 Windows 網域使用者帳號執行,且你沒有為該帳號註冊服務主體名稱(SPN)。

  • 報告伺服器已經設定了這個 RSWindowsNegotiate 設定。

  • 瀏覽器在發送給報告伺服器的請求中,在認證標頭中選擇 Kerberos 而非 NTLM。

如果你啟用了 Kerberos 日誌,就能偵測到這個錯誤。 錯誤的另一個症狀是你會多次被要求輸入憑證,然後看到一個空白的瀏覽器視窗。

你可以透過從設定檔移除 <RSWindowsNegotiate> 並重新嘗試連線來確認遇到 Kerberos 認證錯誤。

確認問題後,你可以用以下方式處理:

  • 在網域使用者帳號下註冊一個報告伺服器服務的 SPN。 如需詳細資訊,請參閱為報表伺服器註冊服務主體名稱 (SPN)。

  • 將服務帳號改為以內建帳號(如 Network Service)執行。 內建帳號會將 HTTP SPN 對應至 Host SPN,而 Host SPN 是在您將電腦加入您的網路時所定義的。 如需詳細資訊,請參閱設定服務帳戶 (報表伺服器組態管理員)。

  • 使用NTLM。 NTLM 通常適用於 Kerberos 認證失敗的情況。 使用 NTLM 時,從 RSReportServer.config 檔案中移除 RSWindowsNegotiate 並確認只 RSWindowsNTLM 指定了 。 如果你選擇這種方式,即使你沒有為報表伺服器定義 SPN,也可以繼續使用網域使用者帳號。

總結來說,你應該執行類似以下範例的指令。 適當地替換數值。

setspn -S HTTP/<SSRS Server FDQN> <SSRS Service Account>
setspn -S HTTP/<host header for Report server web site> <SSRS Service Account>
setspn -S HTTP/<SharePoint Server FDQN> <SharePoint Application Pool Account>
setspn -S HTTP/<host header for SharePoint site>  <SharePoint Application Pool Account>
setspn -S HTTP/Dummy <Claims to Windows Taken Service Account>

記錄資訊

有多種日誌資訊來源可以幫助解決 Kerberos 相關問題。

使用者帳戶控制屬性

確認 Reporting Services 服務帳號在 Active Directory 中是否設定了足夠的屬性。 請檢視 Reporting Services 服務追蹤日誌檔,找出 UserAccountControl 屬性所記錄的值。 記錄的數值為十進位形式。 你需要把小數值轉換成十六進位,然後在 MSDN 描述 User-Account-Control Attribute 的文章中找到這個數值。

  • Reporting Services 服務追蹤日誌條目看起來類似以下範例:

    appdomainmanager!DefaultDomain!8f8!01/14/2010-14:42:28:: i INFO: The UserAccountControl value for the service account is 590336
    
  • 將十進位值轉換為十六進位格式的其中一種方式,是使用 Microsoft Windows 計算機。 Windows 計算機提供多種模式,可顯示 Dec 選項和 Hex 選項。 選取 Dec 選項,貼上或輸入你在記錄檔中找到的十進位值,然後選取「十六進位」選項。

  • 接著參考文章《 User-Account-Control Attribute 》來推導該服務帳號的屬性。

在 Active Directory 中為 Reporting Services 服務帳號設定的 SPN

若要將 SPN 登錄在 Reporting Services 服務追蹤日誌檔中,您可以暫時啟用 Reporting Services 的延伸保護功能。

  • 修改設定檔 rsreportserver.config ,請設定以下設定:

    <RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel>
    <RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>
    
  • 重新啟動 Reporting Services 服務。

如果你不想繼續使用 Extended Protection,請將設定值設回預設值,並重新啟動 Reporting Services 服務帳號。

<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>

欲了解更多資訊,請參閱與 Reporting Services 進行認證的擴展保護。

瀏覽器如何選擇協商 Kerberos 或協商 NTLM

當您使用 Internet Explorer 連線到報表伺服器時,它會在驗證標頭中指定「協商 Kerberos」或 NTLM。 當以下情況使用 NTLM 取代 Kerberos 時:

  • 請求會被送往本地的報告伺服器。

  • 請求會傳送到報告伺服器電腦的 IP 位址,而非主機標頭或伺服器名稱。

  • 防火牆軟體會封鎖用於 Kerberos 認證的埠口。

  • 特定伺服器的作業系統沒有啟用 Kerberos。

  • 該網域包含不支援新版本作業系統中內建的 Kerberos 認證功能的舊版 Windows 用戶端與伺服器作業系統。

此外,根據你如何設定 URL、LAN 和代理設定,Internet Explorer 可能會選擇協商 Kerberos 或 NTLM。

報表伺服器 URL

若網址包含完整限定的網域名稱,Internet Explorer 會選擇 NTLM。 若 URL 指定 localhost,Internet Explorer 會選擇 NTLM。 若 URL 指定電腦的網路名稱,Internet Explorer 會選擇協商,此選項是否成功或失敗取決於報告伺服器服務帳號是否存在 SPN。

用戶端的區域網路與代理設定

你在 Internet Explorer 中設定的 LAN 和代理設定可以決定是否選擇 NTLM 而非 Kerberos。 然而,由於不同組織的區域網路與代理設定不同,無法精確判斷哪些設定會導致 Kerberos 認證錯誤。 例如,您的組織可能會強制實施 Proxy 設定,將內部網路 URL 轉換為可透過網際網路連線解析的完整網域名稱 (FQDN) URL。 如果不同類型的 URL 使用不同的認證提供者,你可能會發現有些連線在你預期會失敗時反而成功。

你可能會遇到你認為是驗證失敗造成的連線錯誤。 如果是這樣,你可以嘗試不同的區域網路和代理設定組合來找出問題所在。 在 Internet Explorer 中,LAN 與代理設定位於區域網路(LAN)設定對話框中,透過網際網路選項的連接標籤選出 LAN 設定來開啟。

關於 Kerberos 及報告伺服器的額外資訊