AD FS 中 Azure Active Directory 到 Office 365 的問題進行疑難排解

請注意--重要:本文是以 Microsoft 機器翻譯軟體翻譯而成,且可能由 Microsoft Community 利用 Community Translation Framework技術或人工進行事後編修。翻譯過程並無專業譯者參與。Microsoft 同時提供使用者人為翻譯、機器翻譯及社群編修後的機器翻譯三種版本的文章,讓使用者可以依其使用語言使用知識庫中的所有文章。但是,所有翻譯文章都可能不盡完美,內容都可能出現詞彙、語意或文法上的錯誤。就翻譯內容之不正確或錯誤,或客戶因使用翻譯內容所產生的任何損害,微軟不負擔任何責任。Microsoft將依合理的商業努力不斷地更新機器翻譯軟體和工具,以期能為使用者提供更好的服務。

按一下這裡查看此文章的英文版本:3079872
本文將告訴您疑難排解驗證問題,在 Azure Active Directory 或 Office 365 的聯盟使用者的工作流程。
徵狀
  • 聯盟的使用者無法登入 Office 365 或 Microsoft Azure 即使具有 domainxx.onmicrosoft.com 的 UPN 尾碼的 managed 定域機組專用使用者可以登入,而沒有問題。
  • 重新導向至 Active Directory 聯盟服務 (AD FS) 或 STS 聯盟的使用者不會發生。或者,就會觸發 「 無法顯示網頁 」 的錯誤。
  • 當您嘗試使用 AD FS 驗證時,您就會收到憑證相關的警告,瀏覽器上。這指出憑證驗證失敗,或憑證不受信任。
  • 「 未知的驗證方法 」 錯誤或錯誤,指出,AuthnContext 不支援。此外,在 AD FS 或 STS 層級時從 Office 365 的重新導向錯誤。
  • AD FS 會擲回 「 拒絕存取 」 錯誤。
  • AD FS 會擲回的錯誤訊息指出沒有問題,存取網站;這包括參考 ID 編號。
  • 在 AD FS 層級的認證,會重複提示使用者。
  • 聯盟的使用者無法從外部的網路進行驗證,或使用應用程式時,會使用外部的網路路由 (例如 Outlook)。
  • 在 AD FS 變更權杖簽署憑證之後,聯盟的使用者無法登入。
  • 聯盟的使用者登入 Microsoft Azure 中的 Office 365 時,就會觸發 「 抱歉,不過我們有問題時您登入 」 的錯誤。這個錯誤會包含錯誤代碼,例如 8004786 C、 80041034、 80041317、 80043431、 80048163、 80045C 06 8004789A 或不正確的要求。

疑難排解的工作流程
  1. 存取 https://login.microsoftonline.com然後輸入 [聯盟的使用者的登入名稱 (某人@範例.com).您按下 Tab 將焦點從登入方塊之後,請檢查是否為 「 重新導向 」,然後網頁就會變更的狀態重新導向至使用中目錄聯盟針對您的服務 (AD FS) 登入。

    重新導向時,您會看到下列頁面:

    步驟 1 的螢幕擷取畫面
    1. 如果沒有重新導向,就會發生,當系統提示您輸入密碼,同一個頁面上,這表示,Azure 的 Active Directory (AD) 」 或 「 Office 365 無法辨識要同盟的使用者的網域。若要檢查 Azure AD 之間是否有同盟信任或執行 Office 365 和您的 AD FS 伺服器, 取得 msoldomain 從 Azure AD PowerShell cmdlet。如果聯盟網域,將 「 聯盟 」,以顯示其 [驗證] 屬性,如下列螢幕擷取畫面所示:

      逐步有關聯盟網域
    2. 如果重新導向,就會發生,但您無法重新導向至登入 AD FS 伺服器,請檢查是否 AD FS 的服務名稱會解析為正確的 IP 及是否它能夠連接到 TCP 連接埠 443 上的 IP。

      如果網域顯示為 「 聯盟 」,請執行下列命令以取得同盟信任的相關資訊:
      Get-MsolFederationProperty -DomainName <domain>
      Get-MsolDomainFederationSettings -DomainName <domain>
      請檢查 URI、 URL,以及由 Office 365 或 Azure 的 AD 設定的聯盟協力廠商的憑證。
  2. 您會被重新導向至 AD FS 之後,請瀏覽器可能會擲回憑證信任相關錯誤,,,有些用戶端及裝置它可能不會讓您建立 SSL 工作階段與 AD FS。若要解決這個問題,請依照下列步驟執行:
    1. 請確定呈現給用戶端的 AD FS 服務通訊的憑證是同一個 AD FS 上所設定。

      步驟 A 的螢幕擷取畫面

      在理想的情況下,AD FS 服務通訊的認證應嘗試建立 SSL 通道與 AD FS 服務時,會向用戶端的 SSL 憑證一樣。

      在 AD FS 2.0:

      • Iis 中將憑證繫結預設值的第一個網站->。
      • 用於 AD FS 嵌入式管理單元新增相同的憑證與所服務的通訊憑證。

      在 AD FS 2012 R2:

      • 使用 [AD FS 嵌入式管理單元或 新增 adfscertificate 若要新增服務的通訊憑證的命令。
      • 使用 設定 adfssslcertificate 若要設定相同的憑證進行 SSL 繫結的命令。

    2. 請確定該 AD FS 服務通訊的憑證信任的樹系的用戶端。
    3. 如果非 SNI – 功能的用戶端會嘗試建立 SSL 工作階段使用 AD FS 或 WAP 2-12 R2,可能會失敗的嘗試。在此情況下,請考慮在 AD FS 或 WAP 伺服器,以支援非 SNI 用戶端上新增一個後援的項目。如需詳細資訊,請參閱下列的部落格張貼:
  3. 您可能會遇到 「 未知的驗證方法 」 錯誤或錯誤,指出,AuthnContext 時,不支援在 AD FS 或 STS 等級從 Office 365 的重新導向。當 Office 365 和 Azure 的廣告會重新導向至 AD FS 或 STS 使用強制執行驗證方法的參數,這是最常見的。若要強制驗證方法,請使用下列方法之一:
    • WS-聯盟使用 WAUTH 的查詢字串強制慣用的驗證方法。
    • 為 SAML2.0使用下列:
      <saml:AuthnContext><saml:AuthnContextClassRef>urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport</saml:AuthnContextClassRef></saml:AuthnContext>
    當強制的驗證方法傳送不正確的值,或在 AD FS 或 STS 上不支援該驗證方法,您會收到錯誤訊息之前都會經過驗證。

    下表顯示的驗證類型可辨認的 AD FS 的 Uri WS-同盟 被動的驗證。
    想要的驗證方法URI wauth
    使用者名稱和密碼驗證urn: 綠洲: 名稱: tc: SAML:1.0:am:password
    SSL 用戶端驗證urn: ietf:rfc:2246
    Windows 整合式的驗證urn: 聯盟: 驗證: 視窗

    受支援的 SAML 驗證內容類別

    驗證方法 URI 的驗證內容類別
    使用者名稱和密碼urn: 綠洲: 名稱: tc: SAML:2.0:ac:classes:Password
    密碼保護的傳輸urn: 綠洲: 名稱: tc: SAML:2.0:ac:classes:PasswordProtectedTransport
    傳輸層安全性 (TLS) 用戶端urn: 綠洲: 名稱: tc: SAML:2.0:ac:classes:TLSClient
    X.509 憑證urn: 綠洲: 名稱: tc: SAML:2.0:ac:classes:X 509
    整合式的 Windows 驗證urn: 聯盟: 驗證: 視窗
    Kerberosurn: 綠洲: 名稱: tc: SAML:2.0:ac:classes:Kerberos

    若要確定在 AD FS 層級受支援的驗證方法,檢查下列項目。

    AD FS 2.0

    在下 /adfs/ls/web.config請確定存在的驗證類型的項目。

    <microsoft.identityServer.web></microsoft.identityServer.web>
    <localAuthenticationTypes></localAuthenticationTypes>
    新增名稱 ="Forms"page="FormsSignIn.aspx"/ >
    <add name="Integrated" page="auth/integrated/"></add>
    <add name="TlsClient" page="auth/sslclient/"></add>
    <add name="Basic" page="auth/basic/"></add>


    AD FS 2.0: 如何變更本機的驗證類型

    AD FS 2012 R2

    在下 AD FS 管理按一下 驗證原則 AD FS 嵌入式管理單元。

    主要驗證 區段中按一下 編輯 下一步] 通用設定.您也可以以滑鼠右鍵按一下 驗證原則 然後選取 編輯全域主要驗證.或者,在 動作 窗格中選取 編輯全域主要驗證.

    編輯全域驗證原則 視窗] 主要 索引標籤上,您可以設定設定為通用的驗證原則的一部分。例如,對於主要驗證 」,您可以選取在 [可用的驗證方法 外部網路內部網路.

    * * 請確定已選取 [需要的驗證方法] 核取方塊。
  4. 如果您前往 AD FS,並輸入您的認證,但您無法通過驗證,請檢查下列的問題。
    1. 作用中的目錄複寫問題

      AD 複寫已損毀,如果使用者或群組所做的變更可能會進行同步處理,所有網域控制站。網域控制站之間可能有密碼,UPN, GroupMembershipProxyaddress 會影響 AD FS 回應 (「 驗證 」 和 「 宣告 」) 的不相符。您應該開始了解 AD FS 與相同的網站上的網域控制站。執行 repadmin 進行 (含) DCdiag /v 命令應該顯示在 AD FS 是最有可能,連絡的網域控制站上是否有問題。

      您也可以收集 AD 複寫摘要],請確定 AD 變更會被正確地複寫到所有網域控制站。的 repadmin /showrepl * /csv > showrepl.csv 輸出是很有幫助檢查複寫狀態。如需詳細資訊,請參閱 Active Directory 複寫問題的疑難排解.
    2. 帳戶鎖定,或在 Active Directory 中停用

      當使用者已經過驗證,得以透過 AD FS 時,他或她將不會收到錯誤訊息,說明該帳戶已鎖定或停用。從 AD FS] 和 [登入稽核,您應該能夠判斷是否驗證失敗,因為不正確的密碼,無論帳戶是停用或鎖定,等等。

      若要啟用 AD FS 及稽核 AD FS 伺服器的登入,請依照下列步驟執行:
      1. 您可以使用 [本機或網域原則來啟用成功與失敗下列原則:
        • 稽核登入事件,位於 [電腦設定 \windows 設定 \ 安全性設定 \ setting\Local 原則原則]
        • 稽核物件存取,位於 [電腦設定 \windows 設定 \ 安全性設定 \ setting\Local 原則原則]
        有關原則的螢幕擷取畫面
      2. 停用下列原則:

        稽核: 強制稽核原則子類別設定 (Windows Vista 或更新版本) 強制覆蓋稽核原則類別設定

        這個原則位於電腦設定 \windows 設定 \ 安全性設定 \ setting\Local Policy\Security 選項。

        有關原則的畫面

        如果您想要這設定利用進階稽核,按一下 這裡.
      3. AD FS 的設定稽核:
        1. 開啟 AD FS 2.0 管理嵌入式管理單元。
        2. 在 [動作] 窗格中,按一下 [編輯聯盟服務內容]。
        3. 同盟服務內容 對話方塊中,按一下 [事件 ] 索引標籤。
        4. 選取 [成功稽核 失敗的稽核 核取方塊。

          關於 sceenshot 可讓您啟用 AD FS 稽核
        5. 執行 GPupdate /force 在伺服器上。
    3. 服務主要名稱 (SPN) 註冊不正確

      可能有重複的 Spn 或不 AD FS 的服務帳戶的帳戶已註冊的 SPN。為 AD FS 伺服器陣列設定] 中,請確定 SPN 主機/AD FSservicename 新增服務帳戶執行 AD FS 服務。AD FS 獨立安裝程式下, 執行服務的位置 網路服務SPN 必須裝載 (host) AD FS 伺服器電腦帳戶。

      螢幕擷取畫面的 AD FS 服務名稱

      確定沒有重複的 Spn,AD FS 服務,因為這可能與 AD FS 會造成暫時性驗證失敗。若要列出的 Spn,請執行 SETSPN – L<ServiceAccount></ServiceAccount>.

      關於清單 SPN 的螢幕擷取畫面

      執行 SETSPN – A 主機/AD FSservicename ServiceAccount 若要新增的 SPN。

      執行 SETSPN-X-F 若要檢查有重複的 Spn。
    4. 重複的 upn,請在 Active Directory 中

      使用者可能會當他們所使用,透過 AD FS 驗證 SAMAccountName 但無法驗證使用 UPN 時。在這個案例中,Active Directory 可能包含兩個具有相同的 UPN 的使用者。很可能最後會得到兩個具有相同的 UPN,使用者會加入和修改時間的使用者透過指令碼 (例如 ADSIedit)。

      UPN 是用來進行驗證,在這個案例中,使用者便通過驗證,對重複的使用者。因此,不會驗證所提供的認證。

      若要檢查是否有多個 AD 中的物件具有相同屬性的值,您可以使用類似下列的查詢:
      Dsquery * forestroot -filter UserPrincipalName=problemuser_UPN

      請確定,已重新命名重複的使用者上的 UPN,以便與 UPN 的驗證要求經過正確的物件。
    5. 在案例中,其中使用您的電子郵件地址作為在 Office 365 的登入識別碼,而當您重新導向至 AD FS,進行驗證時,輸入相同的電子郵件地址,驗證可能會失敗稽核記錄中的 「 NO_SUCH_USER 」 錯誤。若要啟用 AD FS 不的驗證的使用者,藉由使用 UPN 或 SAMaccountname 以外的屬性,您必須設定 AD FS 支援替代的登入 id。如需詳細資訊,請參閱 設定替代的登入識別碼.

      在 AD FS 2012 R2

      1. 安裝 更新 2919355.
      2. 任何陣列中的同盟伺服器上執行下列 PowerShell 指令程式來更新 AD FS 設定 (如果您有 WID 伺服陣列時,您必須執行這個命令在主要的 AD FS 伺服器陣列中):

        設定 AdfsClaimsProviderTrust-TargetIdentifier"AD 授權 」 AlternateLoginID <attribute>-LookupForests <forest domain=""></forest> </attribute>

        附註AlternateLoginID 是您想要使用的登入的 LDAP 名稱。和 LookupForests 是樹系使用者所屬的 DNS 項目清單。

        若要啟用 「 替代的登入識別碼 」 功能,您必須設定兩個 AlternateLoginIDLookupForests 具有非 null、 有效的值的參數。

    6. AD FS 的服務帳戶沒有簽章憑證的私密金鑰的 AD FS 語彙基元的讀取權限。若要新增此權限,請依照下列步驟執行:
      1. 當您新增新的權杖簽署憑證時,您會收到下列警告:"確定選擇的憑證的私密金鑰是存取陣列中的每一部伺服器上的 [為這個同盟服務的服務帳戶 」。
      2. 按一下 [開始],按一下 [執行] 型別 mmc.exe然後按 Enter 鍵。
      3. 按一下 [檔案],然後按一下 [新增/移除嵌入式管理單元
      4. 按兩下 [憑證]。
      5. 選取 [電腦帳戶有問題,,,然後按一下 [下一步]
      6. 選取本機電腦,然後按一下 [完成]
      7. 依序展開 [憑證 (本機電腦) 人物代表l,然後選取憑證
      8. 以滑鼠右鍵按一下新的權杖簽署憑證,選取 [所有工作],然後選取管理私密金鑰

        步驟 8 sceenshot
      9. 新增您的 AD FS 2.0 的服務帳戶的 「 讀取 」 權限然後再按[確定]
      10. 關閉憑證 MMC。
    7. Windows 驗證延伸保護選項會啟用 AD FS 或 LS 虛擬目錄。這可能會造成問題,與特定的瀏覽器。有時您可能會看到重複不要提示認證,AD FS,而這可能會與 延伸的保護 啟用 AD FS 或 LS 應用程式,在 IIS 中的 Windows 驗證的設定。

      步驟 8 sceenshot
      延伸的保護 驗證已啟用的驗證要求結合這兩個服務主要名稱 (Spn) 的用戶端嘗試連接,並在其上進行整合式 Windows 驗證外部的傳輸層安全性 (TLS) 通道的伺服器。延伸的保護,以增強現有的 Windows 驗證功能,降低驗證轉送或 「 中間人 」 攻擊。不過,某些瀏覽器無法使用 延伸的保護 設定;相反地,他們重複提示您輸入認證,然後拒絕存取。停用 延伸的保護 可幫助是這種情況。

      如需詳細資訊,請參閱 AD FS 2.0: 持續地提示您輸入認證時使用 Fiddler web 偵錯工具.

      為 AD FS 2012 R2

      執行下列的指令程式,若要停用 Extendedprotection:

      設定 ADFSProperties – ExtendedProtectionTokenCheck 無

    8. 在做為基礎的合作對象 (RP) 信任的發行授權規則可能會拒絕使用者存取。在 [AD FS 信賴憑證者信任中,您可以設定控制是否已驗證的使用者應該核發語彙基元的信賴憑證者的發行授權規則。系統管理員可以用來決定是否要拒絕存取權立即取出宣告為群組的成員使用者所發出的宣告。

      如果特定聯盟的使用者無法驗證得以透過 AD FS 中,您可能要檢查 Office 365 資源點數的發行授權規則,並查看是否 允許所有使用者的存取 設定規則。

      螢幕擷取畫面的相關規則
      如果不設定這項規則,請仔細檢查該規則的條件是否評估為受影響的使用者的 「 真正 」 的自訂的授權規則。如需詳細資訊,請參閱下列資源:
      如果您直接存取 AD FS 伺服器,但當您透過 AD FS proxy 存取 AD FS 無法進行驗證時,您可以從內部網路進行驗證,請檢查下列問題:
      • AD FS 伺服器和 AD FS proxy 上的時間同步問題

        請確定,AD FS 伺服器上的時間和 proxy 上的時間都是同步。當 AD FS 伺服器上的時間超過五分鐘內從網域控制站上的時間為關閉時,則會發生驗證失敗。當 AD FS proxy 上的時間不同步的 AD FS 時,proxy 信任將影響中,而中斷。因此,是透過 AD FS proxy 要求失敗。
      • 請檢查 AD FS proxy 信任與 AD FS 服務是否運作正常。如果您懷疑 proxy 信任失效時,請重新執行 proxy 設定。
  5. AD FS 會發出語彙基元,Azure 的廣告或 Office 365 擲回一個錯誤之後。在此情況下,請檢查下列問題:
    • 由在權杖中的 AD FS 所發出的宣告應符合 Azure 的 AD 中的使用者的個別屬性。Azure 的 AD 的語彙基元中或辦公室 365 下列宣告所需。

      WSFED:
      UPN: 此宣告的值應該符合使用者的 UPN Azure AD 中。
      ImmutableID: 此宣告的值應符合的 sourceAnchor 或 ImmutableID 的使用者 Azure AD 中。

      若要取得使用者的屬性值,Azure 的 AD 中,執行下列命令列: 取得 MsolUser-UserPrincipalName<UPN></UPN>

      SAML 2.0:
      IDPEmail: 此宣告的值應該符合使用者主要名稱的使用者 Azure AD 中。
      NAMEID: 此宣告的值應符合的 sourceAnchor 或 ImmutableID 的使用者 Azure AD 中。

      如需詳細資訊,請參閱 使用 SAML 2.0 身份識別提供者來實作單一登入。

      範例:
      同步處理使用者的 UPN 變更 AD 中,但不會更新的線上目錄時,可以發生這個問題。在這個案例中,您可以更正使用者的 UPN (以配對相關的使用者登入名稱) 的 AD 中或執行下列的指令程式,若要變更相關的使用者,線上目錄中的登入名稱:

      設定 MsolUserPrincipalName-UserPrincipalName [ExistingUPN]-NewUserPrincipalName [AD DomainUPN]

      也可能是使用 AADsync 同步 UPN 郵件為 SourceAnchor 的 EMPID但信賴憑證者宣告不傳送更新 AD FS 層級的規則 UPN 郵件為 ImmutableID 的 EMPID.
    • 沒有 AD FS 到 Office 365 之間權杖簽署憑證不相符。

      這是最常見的問題。AD FS 會使用權杖簽署憑證來簽署傳送給使用者或應用程式的語彙基元。AD FS 和 Office 365 之間的信任是此權杖簽署憑證為依據的同盟的信任 (例如,Office 365 驗證使用宣告提供者 [AD FS 的服務] 可信任的權杖簽署憑證簽署收到的語彙基元)。

      如果 AD FS 的權杖簽署憑證變更自動憑證變換,或由系統管理員介入 (之後,或者在憑證到期之前),新的憑證的詳細資料,都必須更新 Office 365 承租人,聯盟的網域上。

      Office 365 或 Azure 的廣告會嘗試 AD FS 服務中,向外聯繫提供其從公用網路的可執行到的。我們試著在提取 ADFS,主要權杖簽署憑證上的任何設定變更的固定間隔輪詢 ADFS 聯盟中繼資料。如果不使用此程序,全域系統管理員應該會看到通知 Office 365 入口網站上所要採取,將其更新警告有關權杖簽署憑證過期,以及與動作。

      您可以使用 取得 MsolFederationProperty 網域名稱<domain></domain> 若要傾印在 AD FS 到 Office 365 上的 [聯盟] 屬性。這裡您可以比較 TokenSigningCertificate 指紋,以檢查您聯盟的網域的 Office 365 承租人組態是否與 AD FS 的同步處理。如果您發現不相符的情形,權杖簽署憑證組態中,執行下列命令將其更新:
      Update-MsolFederatedDomain -DomainName <domain> -SupportMultipleDomain
      您也可以執行下列的工具,將工作排定為將監視的權杖簽署憑證和更新辦公室 365 承租人自動的自動憑證變換的 AD FS 伺服器上。

      Microsoft Office 365 聯盟中繼資料更新的自動化安裝工具

      驗證和管理單一登入與 AD FS
    • Office 的 365 RP 發行轉換宣告規則未正確設定。

      在此案例中有多個 Tld (最上層網域) 的位置,則您可能必須登入問題 Supportmultipledomain 不使用參數,當 RP 信任已建立和更新。如需詳細資訊,請按一下 這裡.
    • 請確定該權杖的加密 正在使用 AD FS 或 STS 語彙基元發出 Azure AD 或 Office 365 時。
  6. 在 [Windows 認證管理員] 中有過時快取的認證。

    有時候在登入工作站至入口網站 (或使用 Outlook 時) 期間,當會提示使用者輸入認證,認證可能儲存在 [Windows 認證管理員 (控制 Panel\User Accounts\Credential 管理員) 的目標 (Office 365 或 AD FS 服務)。這有助於防止認證提示段時間,但是使用者的密碼已變更,並不會更新認證管理員之後,它可能會造成問題。在此情況下,過時的認證送往 AD FS 服務,因此驗證失敗。移除或更新快取的認證,也就是在 [Windows 認證管理員] 中可以幫助。
  7. 請確定安全雜湊演算法設定上做為基礎廠商信任 Office 365 設 SHA1。

    STS/AD FS 和 Azure AD/辦公室 365 之間的信任使用 SAML 2.0 通訊協定,安全的雜湊演算法,而此一設定為 [數位簽章應該 SHA1。
  8. 如果沒有上述原因的一項適用您的情況,建立與 Microsoft 的支援案例,並要求他們檢查使用者帳戶一致地出現在 [Office 365 承租人] 下。如需詳細資訊,請參閱下列資源:

    從 AD FS 2.0 時聯盟的使用者登入 Office 365 的錯誤訊息: 「 時發生問題,網站存取"

    當他或她連線到 AD FS 2.0 的服務端點在 Office 365 登入期間,認證重複提示聯盟的使用者
  9. 根據 (與 Azure 的 AD 整合) 哪個定域機組服務而定,您正在存取,會傳送到 AD FS 驗證要求可能會有所不同。例如: 某些要求可能如包含額外的參數 WauthWfresh而且這些參數可能會導致不同的行為,在 AD FS 層級。

    我們建議您,AD FS 二進位碼檔案永遠保持更新包含已知問題的修正程式。如需有關最新的更新的詳細資訊,請參閱下表。

警告:本文為自動翻譯

內容

文章識別碼:3079872 - 最後檢閱時間:08/12/2015 04:20:00 - 修訂: 2.0

Windows Server 2008 Datacenter, Windows Server 2008 Enterprise, Windows Server 2008 Foundation, Windows Server 2008 Standard, Windows Server 2008 R2 Datacenter, Windows Server 2008 R2 Enterprise, Windows Server 2008 R2 Foundation, Windows Server 2008 R2 Standard, Windows Server 2012 Foundation, Windows Server 2012 Essentials, Windows Server 2012 Datacenter, Windows Server 2012 Standard, Windows Server 2012 R2 Datacenter, Windows Server 2012 R2 Essentials, Windows Server 2012 R2 Foundation, Windows Server 2012 R2 Standard

  • kbmt KB3079872 KbMtzh
意見反應