如何設定 Microsoft Entra 憑證式驗證
Microsoft Entra 憑證式驗證 (CBA) 可讓組織設定其 Microsoft Entra 租用戶,允許或要求使用者以企業公開金鑰基礎結構 (PKI) 建立的 X.509 憑證驗證來登入應用程式和瀏覽器。 這項功能可讓組織使用 x.509 憑證採用防網路釣魚的新式密碼驗證。
登入期間,使用者也會看到使用憑證進行驗證,而不是輸入密碼的選項。 如果裝置上有多個相符的憑證,則使用者可以選擇要使用哪一個憑證。 憑證驗證通過使用者帳戶後,如果成功,使用者帳戶即可登入。
請遵循下列指示,為 Office 365 企業版和美國政府方案中的租用戶設定及使用 Microsoft Entra CBA。 您應該已設定公開金鑰基礎結構 (PKI)。
必要條件
確定滿足下列先決條件:
- 在 Microsoft Entra ID 中設定至少一個憑證授權單位 (CA) 和任何中繼 CA。
- 使用者必須能夠存取用於用戶端驗證的使用者憑證 (從租用戶上設定的受信任公開金鑰基礎結構簽發),以針對 Microsoft Entra ID 進行驗證。
- 每個 CA 都應該有憑證撤銷清單 (CRL),可從網際網路對應的 URL 參考。 如果受信任的 CA 未設定 CRL,Microsoft Entra ID 將不會執行任何 CRL 檢查、撤銷使用者憑證將無效,且不會封鎖驗證。
重要
請確定 PKI 是安全的,且不容易遭到入侵。 當遭到入侵時,攻擊者可以建立並簽署用戶端憑證,入侵租用戶中的任何使用者,包括從內部部署同步的使用者和僅限雲端使用者。 不過,強式金鑰保護原則以及其他實體和邏輯控制項 (例如 HSM 啟用卡或用於安全儲存成品的權杖) 可以提供深度防禦,以防止外部攻擊者或內部威脅危害 PKI 的完整性。 如需詳細資訊,請參閱保護 PKI。
重要
請瀏覽 Microsoft 建議,以取得Microsoft 密碼編譯的最佳做法,包括演算法選擇、金鑰長度和資料保護。 請務必使用其中一個建議的演算法、金鑰長度和 NIST 核准的曲線。
重要
作為持續安全性改善的一部分,Azure/M365 端點正在新增 TLS1.3 的支援,此流程預計需要幾個月的時間才能涵蓋 Azure/M365 中的數千個服務端點。 這包括 Microsoft Entra 憑證式驗證 (CBA) *.certauth.login.microsoftonline.com
和 *.certauth.login.microsoftonline.us
所使用的 Microsoft Entra 端點。 TLS 1.3 是最新版本的網際網路最多部署的安全性通訊協定,可加密資料,以提供兩個端點之間的安全通訊通道。 TLS 1.3 可消除過時的密碼編譯演算法、增強舊版的安全性,並旨在儘可能加密大部分的交握。 強烈建議開發人員開始在其應用程式和服務中測試 TLS 1.3。
注意
評估 PKI 時,請務必檢閱憑證發行原則和施行。 如前所述,將憑證授權單位 (CA) 新增至 Microsoft Entra 設定,即可讓這些 CA 簽發的憑證驗證 Microsoft Entra ID 中的所有使用者。 因此,請務必考慮 CA 簽發憑證的方式和時機,以及其如何實作可重複使用的識別碼。 系統管理員必須確保只有特定憑證能夠用來驗證使用者,只有系統管理員可以使用高親和性繫結,從更高的層級確保只有特定憑證能夠驗證使用者。 如需詳細資訊,請參閱高親和性繫結。
設定及測試 Microsoft Entra CBA 的步驟
啟用 Microsoft Entra CBA 之前要完成的一些設定步驟。 首先,系統管理員必須設定可發出使用者憑證的受信任 CA。 如以下圖表所示,我們會使用角色型存取控制,確保只需要擁有最低權限的系統管理員即可執行變更。
管理此功能需要全域系統管理員。
或者,您也可以設定驗證繫結,將憑證對應至單一要素或多重要素驗證,並設定使用者名稱繫結,將憑證欄位對應至使用者物件屬性。 驗證原則系統管理員可以設定使用者相關設定。 完成所有設定之後,請在租用戶上啟用 Microsoft Entra CBA。
步驟 1︰設定憑證授權單位
您可以使用 Microsoft Entra 系統管理中心或 Microsoft Graph REST API 和支援的 SDK (例如 Microsoft Graph PowerShell) 來設定憑證授權單位 (CA)。 PKI 基礎結構或 PKI 系統管理員應該能夠提供簽發 CA 的清單。 若要確定您已設定所有 CA,請開啟使用者憑證,然後按一下 [認證路徑] 索引標籤,並確定每個 CA,直到根上傳至 Microsoft Entra ID 信任存放區為止。 如果缺少 CA,CBA 驗證將會失敗。
使用 Microsoft Entra 系統管理中心設定憑證授權單位
若要在 Microsoft Entra 系統管理中心啟用憑證式驗證並設定使用者繫結,請完成下列步驟:
-
以全域管理員的身分登入 Microsoft Entra 系統管理中心。
瀏覽至 [資料保護]>[顯示更多]>[資訊安全中心] (或 [身分識別安全分數]) >[憑證授權單位]。
若要上傳 CA,請選取 [上傳]:
選取 CA 檔案。
如果 CA 是根憑證,請選取 [是],否則選取 [否]。
針對憑證撤銷清單 URL,請設定包含所有已撤銷憑證的 CA 基礎 CRL 網際網路對應 URL。 如不設定 URL,則使用已撤銷憑證的驗證將不會失敗。
針對 Delta 憑證撤銷清單 URL,請為包含自從上次發佈基礎 CRL 後所有撤銷憑證的 CRL 來設定網際網路對應 URL。
選取 [新增]。
若要刪除 CA 憑證,請選取 [憑證],然後選取 [刪除]。
選取 [欄標籤] 以新增或刪除欄標籤。
使用 PowerShell 設定憑證授權單位 (CA)
受信任的 CA 僅支援一個 CRL 發佈點 (CDP)。 CDP 只能是 HTTP URL。 不支援線上憑證狀態通訊協定 (OCSP) 或輕量目錄存取通訊協定 (LDAP) URL。
若要在 Microsoft Entra ID 中設定您的憑證授權單位,請為每個憑證授權單位下載下列項目:
- 憑證的公開部分 (「.cer」 格式)
- 憑證撤銷清單 (CRl) 所在的網際網路對應 URL
憑證授權單位的結構描述看起來像這樣︰
class TrustedCAsForPasswordlessAuth
{
CertificateAuthorityInformation[] certificateAuthorities;
}
class CertificateAuthorityInformation
{
CertAuthorityType authorityType;
X509Certificate trustedCertificate;
string crlDistributionPoint;
string deltaCrlDistributionPoint;
string trustedIssuer;
string trustedIssuerSKI;
}
enum CertAuthorityType
{
RootAuthority = 0,
IntermediateAuthority = 1
}
針對組態,您可以使用 Microsoft Graph PowerShell:
以系統管理員權限啟動 Windows PowerShell。
安裝 Microsoft Graph PowerShell:
Install-Module Microsoft.Graph
設定的第一個步驟,您需要與您的租用戶建立連線。 一旦您與租用戶的連線存在,您可以檢閱、新增、刪除、修改在您的目錄中定義的受信任的憑證授權單位。
連線
若要與您的租用戶建立連線,請使用 Connect-MgGraph:
Connect-MgGraph
Retrieve
若要擷取您目錄中所定義的受信任憑證授權單位,請使用 Get-MgOrganizationCertificateBasedAuthConfiguration。
Get-MgOrganizationCertificateBasedAuthConfiguration
加
注意
當任何現有的 CA 過期時,上傳新的 CA 將會失敗。 租用戶系統管理員應該刪除過期的 CA,然後上傳新的 CA。
請遵循上述步驟,在 Microsoft Entra 系統管理中心中新增 CA。
AuthorityType
- 使用 0 表示根憑證授權單位
- 使用 1 表示中繼憑證授權單位或憑證授權簽發單位
crlDistributionPoint
您可以下載 CRL 並比較 CA 憑證和 CRL 資訊,以驗證上述 PowerShell 範例中的 crlDistributionPoint 值,對您想要新增的 CA 是否有效。
下列表格和圖形示範如何將 CA 憑證中的資訊對應至所下載 CRL 的屬性。
CA 憑證資訊 | = | 下載的 CRL 資訊 |
---|---|---|
主體 | = | Issuer |
主體金鑰識別碼 | = | 授權金鑰識別碼 (KeyID) |
提示
上述範例中的 crlDistributionPoint 值是 CA 憑證撤銷清單 (CRL) 的 HTTP 位置。 您可以在幾個位置找到這個值:
- 在 CA 所簽發憑證的 CRL 發佈點 (CDP) 屬性中。
如果發行 CA 執行 Windows 伺服器:
如需詳細資料,請參閱了解憑證撤銷程序。
使用 Microsoft Graph API 設定憑證授權單位
MS Graph API 可用來設定憑證授權單位。 請遵循 certificatebasedauthconfiguration MSGraph 命令中的步驟來更新 Microsoft Entra 憑證授權單位信任存放區。
驗證憑證授權單位設定
請務必確保上述設定步驟結果是 Microsoft Entra 能夠同時驗證憑證授權單位信任鏈結,並確認已設定憑證授權單位 CRL 發佈點 (CDP) 的憑證撤銷清單 (CRL)。 若要協助這項工作,建議您安裝 MSIdentity Tools PowerShell 模組,並執行 Test-MsIdCBATrustStoreConfiguration。 此 PowerShell Cmdlet 會檢閱 Microsoft Entra 租用戶憑證授權單位設定,並針對常見的設定錯誤問題呈現錯誤/警告。
步驟 2:在租用戶上啟用 CBA
重要
當使用者在驗證方法原則中的憑證式驗證的範圍時,使用者會被視為能夠 MFA。 此原則需求表示使用者無法使用證明作為驗證的一部分來註冊其他可用的方法。 如果用戶沒有憑證的存取權,他們將被鎖定,而且無法註冊 MFA 的其他方法。 因此,系統管理員必須讓具有有效憑證的使用者進入 CBA 範圍。 請勿將所有使用者用於 CBA 目標,並使用具有可用有效憑證的使用者群組。 如需詳細資訊,請參閱 Microsoft Entra 多重要素驗證。
若要在 Microsoft Entra 系統管理中心啟用憑證式驗證,請完成下列步驟:
至少以驗證原則系統管理員身分登入 Microsoft Entra 系統管理中心。
瀏覽至 [群組]>[所有群組]> 選取 [新群組],然後為 CBA 使用者建立群組
瀏覽至 [資料保護]>[驗證方法]>[憑證式驗證]。
在 [啟用] 和 [目標] 下,選取 [啟用]。
選取 [所有使用者],或選取 [新增群組],以選取特定群組,例如上面建立的群組。 建議使用特定群組,而不是 [所有使用者]。
在租用戶上啟用憑證式驗證之後,租用戶中的所有使用者都會看到使用憑證登入的選項。 只有啟用憑證式驗證的使用者才能使用 X.509 憑證進行驗證。
注意
除了 login.microsoftonline.com
之外,網路系統管理員應該允許存取客戶的雲端環境 certauth 端點。 在 certauth 端點上停用 TLS 檢查,以確保用戶端憑證要求會在 TLS 交握過程中成功。
步驟 3:設定驗證繫結原則
驗證繫結原則可協助您以單一要素或多重要素來決定驗證的強度。 租用戶上憑證的預設保護層級是單一要素驗證。
驗證原則管理員可以將預設值從單一要素變更為多重要素,並設定自訂原則規則。 驗證繫結規則會將憑證屬性 (如憑證簽發者或原則 OID) 對應至某個值,然後選取該規則的預設保護層級。 您可以建立多個規則。
若要修改 Microsoft Entra 系統管理中心中的租用戶預設設定,請完成下列步驟:
至少以驗證原則系統管理員身分登入 Microsoft Entra 系統管理中心。
瀏覽至 [資料保護]>[驗證方法]>[原則]。
在 [管理] 底下,選取 [驗證方法]>[憑證式驗證]。
選取 [設定],以設定驗證繫結和使用者名稱繫結。
保護層級屬性的預設值為 [單一要素驗證]。 選取 [多重要素驗證],將預設值變更為 MFA。
注意
如果未新增任何自訂規則,則預設保護層級值會生效。 如果新增自訂規則,則會改為接受在規則層級定義的保護層級。
您也可以設定自訂驗證繫結規則,以協助判斷用戶端憑證的保護層級。 您可以使用憑證中的「簽發者主體」或「原則 OID」欄位來加以設定。
驗證繫結規則會將憑證屬性 (簽發者或原則 OID) 對應至某個值,然後選取該規則的預設保護層級。 您可以建立多個規則。
若要新增自訂規則,請選取 [新增規則]。
若要依憑證簽發者建立規則,請選取 [憑證簽發者]。
從清單方塊中選取 [憑證簽發者識別碼]。
選取 [多重要素驗證]、[低] 親和性繫結,然後按一下 [新增]。 出現提示時,按一下 [我確認] 以完成新增規則。
若要依原則 OID 建立規則,請選取 [原則 OID]。
輸入 [原則 OID] 的值。
選取 [多重要素驗證]、[低] 親和性繫結,然後按一下 [新增]。 出現提示時,按一下 [我確認] 以完成新增規則。 .
若要依憑證簽發者和原則 OID 建立規則:
選取 [憑證簽發者],以及 [原則 OID]。
選取 [憑證簽發者] 並輸入原則 OID。
針對 [驗證強度],選取 [單一要素驗證] 或 [多重要素驗證]。
針對 [親和性繫結],選取 [低]。
選取 [新增]。
使用原則 OID 為 3.4.5.6 且由 CN=CBATestRootProd 簽發的憑證進行驗證。 驗證應該通過並取得多重要素宣告。
重要
有一個已知問題:Microsoft Entra 租用戶系統管理員使用憑證簽發者和原則 OID 設定 CBA 驗證原則規則,會影響某些裝置註冊案例,包括:
- Windows Hello 企業版註冊
- Fido2 安全性金鑰註冊
- Windows 無密碼手機登入
使用 Workplace Join、Microsoft Entra ID 和混合式 Microsoft Entra 裝置加入案例進行裝置註冊不會受到影響。 使用憑證簽發者或原則 OID 的 CBA 驗證原則規則不會受到影響。 若要減輕問題,系統管理員應:
- 編輯目前同時使用憑證簽發者和原則 OID 選項的憑證型驗證原則規則,移除憑證簽發者或 OID 需求後儲存。 OR
- 移除目前同時使用憑證簽發者和原則 OID 的驗證原則規則,並且僅使用憑證簽發者或原則 OID 建立規則
我們正努力修正此問題。
若要依憑證簽發者和序號建立規則:
新增驗證繫結原則,此原則需要 CN=CBATestRootProd 與 policyOID 1.2.3.4.6 簽發的任何憑證,只需要高親和性繫結 (也就是使用憑證簽發者和序號)。
選取 [憑證] 欄位。 在這裡範例中,我們將選取 [憑證簽發者] 和 [序號]。
唯一支援的使用者屬性是 CertificateUserIds。 選取 [新增]。
選取 [儲存]。
登入記錄會顯示使用哪個繫結,以及憑證的詳細資料。
- 選取 [確定] 以儲存任何自訂規則。
重要
使用物件識別碼格式輸入 PolicyOID。 例如,如果憑證原則為 所有簽發原則,請在新增規則時輸入 OID 2.5.29.32.0。 所有簽發原則字串對規則編輯器不正確,而且不會生效。
步驟 4:設定使用者名稱繫結原則
使用者名稱繫結原則可協助驗證使用者的憑證。 根據預設,我們會將憑證中的主體名稱對應至使用者物件中的 UserPrincipalName,以判斷使用者。
驗證原則管理員可以覆寫預設值並建立自訂對應。 若要判斷如何設定使用者名稱繫結,請參閱使用者名稱繫結的運作方式。
如需使用 certificateUserIds 屬性之案例的詳細資訊,請參閱 憑證使用者識別碼。
重要
如果使用者名稱繫結原則使用同步處理的屬性,例如 certificateUserIds、onPremisesUserPrincipalName,以及使用者物件的 userPrincipalName 屬性,請注意 Active Directory 中具有系統管理權限的帳戶 (例如具有使用者物件委派權限的帳戶,或在 Microsoft Entra Connect 伺服器上具有系統管理權限的帳戶) 可以變更,以影響在 Microsoft Entra ID 中的這些屬性。
選取其中一個 [X.509 憑證] 欄位來繫結其中一個使用者屬性,以建立使用者名稱繫結。 使用者名稱繫結順序表示繫結的優先順序層級。 第一個具有最高的優先順序,依此類推。
如果在憑證上找到指定的 X.509 憑證欄位,但 Microsoft Entra ID 找不到使用該值的使用者物件,則驗證會失敗。 Microsoft Entra ID 會嘗試清單中的下一個繫結。
選取儲存以儲存變更。
最後的設定看起來會像此影像:
步驟 5:測試您的設定
本節說明如何測試您的憑證和自訂驗證繫結規則。
測試您的憑證
在第一個設定測試中,您應該嘗試使用您裝置上的瀏覽器來登入 MyApps 入口網站。
輸入您的使用者主體名稱 (UPN)。
選取 [下一步]。
如果您已啟用其他驗證方法 (例如,手機登入或 FIDO2),使用者可能會看到不同的登入畫面。
選取 [使用憑證登入]。
在用戶端憑證選擇器 UI 中選擇正確的使用者憑證,然後選取 [確定]。
使用者應登入 MyApps 入口網站。
如果登入成功,您便知道︰
- 使用者憑證已佈建到您的測試裝置中。
- Microsoft Entra ID 已使用受信任的 CA 正確設定。
- 已正確設定使用者名稱繫結,並已找到且驗證使用者。
測試自訂驗證繫結規則
讓我們逐步解說驗證增強式驗證的案例。 我們將建立兩個驗證原則規則,一個會使用簽發者主體滿足單一要素驗證,另一個使用原則 OID 來滿足多重要素驗證。
建立具有保護層級的簽發者主體規則作為單一要素驗證,並將值設定為您的 CA 主體值。 例如:
CN = WoodgroveCA
建立原則 OID 規則,並將保護層級設定為多重要素驗證,以及將值設定為您的憑證中的其中一個原則 OID。 例如,1.2.3.4。
建立條件式存取原則,讓使用者遵循條件式存取 (需要 MFA) 中的步驟,要求多重要素驗證。
導覽至 MyApps 入口網站。 輸入您的 UPN,然後選取 [下一步]。
選取 [使用憑證登入]。
如果您已啟用其他驗證方法 (例如,手機登入或安全性金鑰),使用者可能會看到不同的登入畫面。
選取用戶端憑證,然後選取 [憑證資訊]。
憑證隨即出現,您可以驗證憑證簽發者和原則 OID 值。
若要查看原則 OID 值,請選取 [詳細資料]。
選取用戶端憑證,然後選取 [確定]。
憑證中的原則 OID 符合所設定的 1.2.3.4 值,而且將滿足多重要素驗證。 同樣地,憑證中的簽發者會符合所設定的 CN=WoodgroveCA 值,並且會滿足單一要素驗證。
由於原則 OID 規則優先於憑證簽發者規則,因此憑證將滿足多重要素驗證。
使用者的條件式存取原則需要 MFA 且憑證滿足多重要素,因此可讓使用者登入應用程式。
測試使用者名稱繫結原則
使用者名稱繫結原則可協助驗證使用者的憑證。 使用者名稱繫結原則支援三個繫結:
- IssuerAndSerialNumber > CertificateUserIds
- IssuerAndSubject > CertificateUserIds
- 主體 > CertificateUserIds
根據預設,Microsoft Entra ID 會將憑證中的主體名稱對應至使用者物件中的 UserPrincipalName,以判斷使用者。 驗證原則系統管理員可以覆寫預設值並建立自訂對應,如先前步驟 4 中所述。
啟用新的繫結之前,驗證原則系統管理員必須確定已針對對應的使用者名稱繫結,在使用者物件屬性憑證 UserIds 中更新繫結的正確值。
- 針對僅限雲端的使用者,請使用 Microsoft Entra 系統管理中心或 Microsoft Graph API 來更新 CertificateUserIds 中的值。
- 針對內部部署同步處理的使用者,請使用 Microsoft Entra Connect 來同步處理內部部署的值,方法是遵循 Microsoft Entra Connect 規則或同步處理 AltSecId 值。
重要
憑證簽發者、主體和 SerialNumber 值的格式應該以憑證中格式的反向順序排列。 請勿在憑證簽發者或主體中新增任何空格。
手動對應憑證簽發者和序號
以下是手動對應憑證簽發者和序號的範例。 要新增的憑證簽發者值如下:
C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate
若要取得序號的正確值,請執行下列命令,並儲存 CertificateUserIds 中顯示的值。 命令語法為:
Certutil –dump –v [~certificate path~] >> [~dumpFile path~]
例如:
certutil -dump -v firstusercert.cer >> firstCertDump.txt
以下是 certutil 命令的範例:
certutil -dump -v C:\save\CBA\certs\CBATestRootProd\mfausercer.cer
X509 Certificate:
Version: 3
Serial Number: 48efa06ba8127299499b069f133441b2
b2 41 34 13 9f 06 9b 49 99 72 12 a8 6b a0 ef 48
CertificateUserId 中要加入的 SerialNumber 值是:
b24134139f069b49997212a86ba0ef48
CertificateUserId:
X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<SR> b24134139f069b49997212a86ba0ef48
手動對應票證和主體
以下是手動對應票證和主體的範例。 憑證簽發者值為:
主體值為:
CertificateUserId:
X509:<I>C=US,O=U.SGovernment,OU=DoD,OU=PKI,OU=CONTRACTOR,CN=CRL.BALA.SelfSignedCertificate<S> DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession
手動對應主體
以下是手動對應主體的範例。 主體值為:
CertificateUserId:
X509:<S>DC=com,DC=contoso,DC=corp,OU=UserAccounts,CN=FirstUserATCSession
測試親和性繫結
至少以驗證原則系統管理員身分登入 Microsoft Entra 系統管理中心。
瀏覽至 [資料保護]>[驗證方法]>[原則]。
在 [管理] 底下,選取 [驗證方法]>[憑證式驗證]。
選取設定。
在租用戶層級設定 [必要的親和性繫結]。
重要
請小心使用整個租用戶的親和性設定。 如果您變更租用戶的 [必要的親和性繫],而且使用者物件中沒有適當的值,則可以鎖定整個租用戶。 同樣地,如果您建立套用至所有使用者且需要高親和性繫結的自訂規則,租用戶中的使用者可能會遭到鎖定。
若要測試,請將 [必要的親和性繫結] 選取為 [低]。
新增像 SKI 這樣的高親和性繫結。 在 [使用者名稱繫結] 底下,選取 [新增規則]。
選取 [SKI],然後選取 [新增]。
完成時,規則看起來會像此螢幕擷取畫面:
更新所有使用者物件 CertificateUserIds 屬性,以從使用者憑證取得正確的 SKI 值。 如需詳細資訊,請參閱 CertificateUserIDs 支援的模式。
建立驗證繫結的自訂規則。
選取 [新增]。
完成時,規則看起來會像此螢幕擷取畫面:
使用來自具有原則 OID 9.8.7.5 憑證的正確的 SKI 值更新使用者 CertificateUserIds。
使用具有原則 OID 9.8.7.5 的憑證測試,且使用者應該以 SKI 繫結驗證,並且僅使用憑證取得 MFA。
使用 Microsoft Graph API 啟用 CBA
若要啟用 CBA 並使用 Graph API 設定使用者名稱繫結,請完成下列步驟。
選取 [登入 Graph 總管],然後登入您的租用戶。
取得所有驗證方法:
GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy
取得 x509 憑證驗證方法的設定:
GET https://graph.microsoft.com/v1.0/policies/authenticationmethodspolicy/authenticationMethodConfigurations/X509Certificate
預設會停用 x509 憑證驗證方法。 若要允許使用者使用憑證登入,您必須啟用驗證方法,並透過更新作業來設定驗證和使用者名稱繫結原則。 若要更新原則,請執行 PATCH 要求。
要求本文:
PATCH https: //graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate Content-Type: application/json { "@odata.type": "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration", "id": "X509Certificate", "state": "enabled", "certificateUserBindings": [ { "x509CertificateField": "PrincipalName", "userProperty": "onPremisesUserPrincipalName", "priority": 1 }, { "x509CertificateField": "RFC822Name", "userProperty": "userPrincipalName", "priority": 2 }, { "x509CertificateField": "PrincipalName", "userProperty": "certificateUserIds", "priority": 3 } ], "authenticationModeConfiguration": { "x509CertificateAuthenticationDefaultMode": "x509CertificateSingleFactor", "rules": [ { "x509CertificateRuleType": "issuerSubject", "identifier": "CN=WoodgroveCA ", "x509CertificateAuthenticationMode": "x509CertificateMultiFactor" }, { "x509CertificateRuleType": "policyOID", "identifier": "1.2.3.4", "x509CertificateAuthenticationMode": "x509CertificateMultiFactor" } ] }, "includeTargets": [ { "targetType": "group", "id": "all_users", "isRegistrationRequired": false } ] }
您會得到
204 No content
回應碼。 請重新執行 GET 要求,以確定原則已正確更新。使用滿足原則的憑證登入來測試設定。
使用 Microsoft Power Shell 啟用 CBA
- 開啟 Power Shell 命令視窗
- 連線至 Microsoft Graph
Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
- 建立變數來定義 CBA 使用者的群組
$group = Get-MgGroup -Filter "displayName eq 'CBATestGroup'"
- 定義要求本文
$body = @{ "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration" "id" = "X509Certificate" "state" = "enabled" "certificateUserBindings" = @( @{ "@odata.type" = "#microsoft.graph.x509CertificateUserBinding" "x509CertificateField" = "SubjectKeyIdentifier" "userProperty" = "certificateUserIds" "priority" = 1 }, @{ "@odata.type" = "#microsoft.graph.x509CertificateUserBinding" "x509CertificateField" = "PrincipalName" "userProperty" = "UserPrincipalName" "priority" = 2 }, @{ "@odata.type" = "#microsoft.graph.x509CertificateUserBinding" "x509CertificateField" = "RFC822Name" "userProperty" = "userPrincipalName" "priority" = 3 } ) "authenticationModeConfiguration" = @{ "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationModeConfiguration" "x509CertificateAuthenticationDefaultMode" = "x509CertificateMultiFactor" "rules" = @( @{ "@odata.type" = "#microsoft.graph.x509CertificateRule" "x509CertificateRuleType" = "policyOID" "identifier" = "1.3.6.1.4.1.311.21.1" "x509CertificateAuthenticationMode" = "x509CertificateMultiFactor" } ) } "includeTargets" = @( @{ "targetType" = "group" "id" = $group.Id "isRegistrationRequired" = $false } ) } | ConvertTo-Json -Depth 5
- 執行 PATCH 要求
Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate" -Body $body -ContentType "application/json"