設定報表伺服器上的 Windows 驗證
根據預設，Reporting Services 會接受可指定交涉式驗證或 NTLM 驗證的要求。 如果您的部署包括了使用這些安全性提供者的用戶端應用程式和瀏覽器，您可以使用預設值，而不需要進行額外的組態設定。 假設您想要針對 Windows 整合式安全性使用不同的安全性供應商，或是修改預設值並想要還原原始設定。 您可以使用這篇文章中的資訊來指定報表伺服器上的驗證設定。
若要使用 Windows 整合式安全性，每一個需要存取報表伺服器的使用者都必須擁有有效的 Windows 本機或網域使用者帳戶。 或者，使用者必須是 Windows 本機或網域群組帳戶的成員。 您可以將其他信任網域中的帳戶包括在內。 這些帳戶必須對報表伺服器電腦擁有存取權，且必須接著指派給角色，以取得特定報表伺服器作業的存取權。
下列需求也必須符合：
RSReportServer.config 檔案必須將
AuthenticationType設為RSWindowsNegotiate、RSWindowsKerberos或RSWindowsNTLM。 根據預設，如果報表伺服器服務帳戶是 NetworkService 或 LocalSystem，RSReportServer.config 檔案就會包含RSWindowsNegotiate設定。否則，就會使用RSWindowsNTLM設定。 如果您的應用程式僅使用 Kerberos 驗證，則可以新增RSWindowsKerberos。重要
如果您設定報表伺服器服務在網域使用者帳戶下執行，而且您並未針對該帳戶註冊服務主體名稱 (SPN)，當您使用
RSWindowsNegotiate將會產生 Kerberos 驗證錯誤。 如需詳細資訊，請參閱本主題中的在連線至報表伺服器時解決 Kerberos 驗證錯誤。ASP.NET 必須設定 Windows 驗證。 報表伺服器 Web 服務的 Web.config 檔案預設會包含
<authentication mode="Windows">設定。 如果您將它變更為<authentication mode="Forms">，Reporting Services 的 Windows 驗證會失敗。報表伺服器 Web 服務的 Web.config 檔案必須有
<identity impersonate= "true" />。用戶端應用程式或瀏覽器必須支援 Windows 整合式安全性。
Web 入口網站不需要其他設定。
若要變更報表伺服器驗證設定，請編輯 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 整合式安全性
在文字編輯器中開啟 RSReportServer.config。
尋找
<Authentication>。複製下列其中一個最符合您需要的 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 的部署指定 NTLM，或是暫時解決 Kerberos 驗證錯誤：
<AuthenticationTypes> <RSWindowsNTLM /> </AuthenticationTypes>將它貼到
<Authentication>的現有項目上。您無法以
RSWindows類型使用Custom。修改為擴充保護的適當設定。 預設會停用擴充保護。 如果這些項目不存在，目前的電腦可能未執行支援擴充保護的 Reporting Services 版本。 如需詳細資訊，請參閱使用 Reporting Services 來驗證擴充保護
<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel> <RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>儲存檔案。
如果您設定了向外延展部署，請針對部署中的其他報表伺服器重複這些步驟。
重新啟動報表伺服器，清除目前開啟的任何工作階段。
連線至報表伺服器時解決 Kerberos 驗證錯誤
在設定交涉式驗證或 Kerberos 驗證的報表伺服器上，如果發生 Kerberos 驗證錯誤，與報表伺服器的用戶端連線將會失敗。 目前已知以下情況下會發生 Kerberos 驗證錯誤：
報表伺服器服務以 Windows 網域使用者帳戶的身分執行，而且您並未針對此帳戶註冊服務主體名稱 (SPN)。
使用
RSWindowsNegotiate設定來設定報表伺服器。瀏覽器在它傳送給報表伺服器之要求的驗證標頭中優先選擇 Kerberos (勝於 NTLM)。
如果您啟用 Kerberos 記錄，就可以偵測此錯誤。 此錯誤的其他徵兆是系統會提示您輸入多次認證，然後您會看到空白瀏覽器視窗。
您可以從組態檔移除 <RSWindowsNegotiate> 並重新嘗試連線，藉此確認您所遇到的是 Kerberos 驗證錯誤。
在您確認問題之後，可以透過以下方式來解決：
使用網域使用者帳戶為報表伺服器服務註冊 SPN。 如需詳細資訊，請參閱為報表伺服器註冊服務主體名稱 (SPN)。
變更服務帳戶，以便在類似網路服務的內建帳戶下執行。 內建帳戶會將 HTTP SPN 對應到主機 SPN (當您將電腦加入網路時會加以定義)。 如需詳細資訊，請參閱設定服務帳戶 (報表伺服器組態管理員)。
使用 NTLM。 當 Kerberos 驗證失敗時，NTLM 通常會正常運作。 若要使用 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 相關問題。
User-Account-Control 屬性
判斷 Reporting Services 服務帳戶是否在 Active Directory 中設定足夠的屬性。 檢閱 Reporting Services 服務追蹤記錄檔，以尋找為 UserAccountControl 屬性記錄的值。 記錄的值是十進位格式。 您需要將此十進位值轉換成十六進位格式，然後在描述 User-Account-Control 屬性的 MSDN 文章中尋找該值。
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選項、貼上或輸入您在記錄檔中找到的十進位值，然後選取「Hex」選項。然後參考 User-Account-Control Attribute 屬性一文來衍生服務帳戶的屬性。
Active Directory 中針對 Reporting Services 服務帳戶所設定的 SPN。
若要在 Reporting Services 服務追蹤記錄檔中記錄 SPN，您可以暫時啟用 Reporting Services 擴充保護功能。
設定以下項目來修改組態檔 rsreportserver.config ：
<RSWindowsExtendedProtectionLevel>Allow</RSWindowsExtendedProtectionLevel> <RSWindowsExtendedProtectionScenario>Any</RSWindowsExtendedProtectionScenario>重新啟動 Reporting Services 服務。
如果不想要繼續使用擴充保護，請將組態值設回預設值，並重新啟動 Reporting Services 服務帳戶。
<RSWindowsExtendedProtectionLevel>Off</RSWindowsExtendedProtectionLevel>
<RSWindowsExtendedProtectionScenario>Proxy</RSWindowsExtendedProtectionScenario>
如需詳細資訊，請參閱使用 Reporting Services 來驗證擴充保護。
瀏覽器如何選擇交涉式 Kerberos 或交涉式 NTLM
當您使用 Internet Explorer 連接報表伺服器時，它會在驗證標頭上指定交涉式 Kerberos 或 NTLM。 在以下情況下會使用 NTLM 取代 Kerberos：
此要求會傳送給本機報表伺服器。
此要求會傳送到報表伺服器電腦的 IP 位址，而不是主機標頭或伺服器名稱。
防火牆軟體會封鎖用於 Kerberos 驗證的通訊埠。
特定伺服器的作業系統未啟用 Kerberos。
網域包括舊版 Windows 用戶端和伺服器作業系統，這些版本不支援內建在新版作業系統中的 Kerberos 驗證功能。
此外，Internet Explorer 可能會選擇交涉式 Kerberos 或 NTLM (根據您設定 URL、LAN 和 Proxy 設定的方式而定)。
報表伺服器 URL
如果此 URL 包含完整網域名稱，Internet Explorer 會選取 NTLM。 如果此 URL 指定 localhost，Internet Explorer 會選取 NTLM。 如果此 URL 指定電腦的網路名稱，Internet Explorer 會選取交涉，這樣會根據報表伺服器服務帳戶是否有 SPN 存在而成功或失敗。
用戶端上的 LAN 和 Proxy 設定
您在 Internet Explorer 中設定的 LAN 和 Proxy 設定可以決定是否優先選擇 NTLM (勝於 Kerberos)。 但是，由於組織之間的 LAN 和 Proxy 設定會有所差異，所以無法精確判斷造成 Kerberos 驗證錯誤的確切設定為何。 例如，您的組織可能會強制 Proxy 設定，這些設定會將 URL 從內部網路 URL 轉換成完整網域名稱 URL (透過網際網路連接來解析)。 如果將不同的驗證提供者用於不同類型的 URL，您可能會發現當您預期某些連接應該會失敗時，這些連接卻成功了。
您可能會碰到以為是驗證失敗而導致的連線錯誤。 若這種情況發生，您可以嘗試不同的 LAN 和 Proxy 設定組合來隔離問題。 在 Internet Explorer 中，LAN 和 Proxy 設定位於區域網路 (LAN) 設定對話框上，您可以在網際網路選項的連線索引標籤上選取區域網路設定來開啟此對話框。
Kerberos 和報表伺服器的其他資訊
- 如需 Kerberos 和報表伺服器的其他資訊，請參閱搭配 Kerberos 使用 SharePoint、Reporting Services 與 PerformancePoint 監控伺服器部署商業智慧方案。