使用联合的基于证书的身份验证

您所在的位置：网站首页 › 山姆app删除其它设备 › 使用联合的基于证书的身份验证

使用联合的基于证书的身份验证

2023-06-09 23:00| 来源: 网络整理| 查看: 265

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

Azure Active Directory 中使用联合身份验证的基于证书的身份验证入门项目 06/08/2023

通过使用联合身份验证的基于证书的身份验证 (CBA)，在 Windows、Android 或 iOS 设备上将 Exchange Online 帐户连接到以下对象时，可由 Azure Active Directory 使用客户端证书进行身份验证：

Microsoft 移动应用程序，例如 Microsoft Outlook 和 Microsoft Word Exchange ActiveSync (EAS) 客户端

如果配置了此功能，就无需在移动设备上的某些邮件和 Microsoft Office 应用程序中输入用户名和密码组合。

注意

作为一种替代方法，组织可以部署 Azure AD CBA 而无需联合身份验证。有关详细信息，请参阅针对 Azure Active Directory 的 Azure AD 基于证书的身份验证概述。

本主题：

提供为 Office 365 企业版、商业版和教育版以及美国政府计划中租户的用户配置并使用 CBA 的步骤。假设已配置公钥基础结构 (PKI) 和 AD FS。要求

要配置使用联合身份验证的 CBA，以下语句必须为 true：

仅浏览器应用程序的联合环境、使用新式身份验证的本机客户端或 MSAL 库支持使用联合身份验证的 CBA。用于 Exchange Online (EXO) 的 Exchange Active Sync (EAS) 除外，它可用于联合帐户和托管帐户。要配置 Azure AD CBA 而无需联合身份验证，请参阅如何配置 Azure AD 基于证书的身份验证。必须在 Azure Active Directory 中配置根证书颁发机构和任何中间证书颁发机构。每个证书颁发机构必须有一个可通过面向 Internet 的 URL 引用的证书吊销列表 (CRL)。必须已在 Azure Active Directory 中至少配置一个证书颁发机构。可以在配置证书颁发机构部分查找相关步骤。对于 Exchange ActiveSync 客户端，客户端证书的“使用者可选名称”字段的主体名称或 RFC822 名称值必须为 Exchange Online 中用户的可路由电子邮件地址。 Azure Active Directory 会将 RFC822 值映射到目录中的“代理地址”属性。客户端设备必须能够访问至少一个颁发客户端证书的证书颁发机构。必须已向客户端颁发用于客户端身份验证的客户端证书。

重要

Azure Active Directory 成功下载和缓存的 CRL 的最大大小为 20MB，下载 CRL 所需的时间不得超过 10 秒。如果 Azure Active Directory 无法下载 CRL，则使用相应 CA 颁发的证书进行的基于证书的身份验证将失败。确保 CRL 文件符合大小限制的最佳做法是将证书生存期保持在合理的限制内，并清理过期的证书。

步骤 1：选择设备平台

第一步，用户需针对所关注的设备平台查看以下内容：

Office 移动应用程序支持特定的实现要求

存在以下设备平台的相关信息：

Android iOS 步骤 2：配置证书颁发机构

若要在 Azure Active Directory 中配置证书颁发机构，请为每个证书颁发机构上传以下内容：

证书的公共部分，格式为 .cer 证书吊销列表 (CRL) 所在的面向 Internet 的 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 }

对于此配置，可以使用 Azure Active Directory PowerShell 版本 2：

使用管理员特权启动 Windows PowerShell。

安装 Azure AD 模块 2.0.0.33 或更高版本。

Install-Module -Name AzureAD –RequiredVersion 2.0.0.33

作为第一个配置步骤，需建立与租户的连接。与租户建立连接后，即可查看、添加、删除和修改目录中定义的受信任的证书颁发机构。

连接

若要建立与租户的连接，请使用 Connect-AzureAD cmdlet：

Connect-AzureAD 检索

若要检索目录中定义的受信任的证书颁发机构，请使用 Get-AzureADTrustedCertificateAuthority cmdlet。

Get-AzureADTrustedCertificateAuthority 添加

若要创建受信任的证书颁发机构，请使用 New-AzureADTrustedCertificateAuthority cmdlet，并将 crlDistributionPoint 属性设为正确的值：

$cert=Get-Content -Encoding byte "[LOCATION OF THE CER FILE]" $new_ca=New-Object -TypeName Microsoft.Open.AzureAD.Model.CertificateAuthorityInformation $new_ca.AuthorityType=0 $new_ca.TrustedCertificate=$cert $new_ca.crlDistributionPoint="" New-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $new_ca 删除

若要删除受信任的证书颁发机构，请使用 Remove-AzureADTrustedCertificateAuthority cmdlet：

$c=Get-AzureADTrustedCertificateAuthority Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[2]

可通过更改为 Remove-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0] 来更改命令以删除第 0 个元素。

修改

若要修改受信任的证书颁发机构，请使用 Set-AzureADTrustedCertificateAuthority cmdlet：

$c=Get-AzureADTrustedCertificateAuthority $c[0].AuthorityType=1 Set-AzureADTrustedCertificateAuthority -CertificateAuthorityInformation $c[0] 步骤 3：配置吊销

若要吊销客户端证书，Azure Active Directory 会从作为证书颁发机构信息的一部分上传的 URL 中提取证书吊销列表 (CRL)，并将其缓存。 CRL 中的上次发布时间戳（“生效日期”属性）用于确保 CRL 仍然有效。将定期引用 CRL，以撤销对该列表中证书的访问权限。

如果需要更即时的吊销（例如，如果用户丢失了设备），可以使用户的授权令牌失效。若要使授权令牌失效，请使用 Windows PowerShell 为此特定用户设置 StsRefreshTokenValidFrom 字段。必须为要撤销其访问权限的每个用户更新 StsRefreshTokenValidFrom 字段。

若要确保撤销仍然有效，必须将 CRL 的生效日期设置为晚于 StsRefreshTokenValidFrom 所设置的值，并确保相关的证书在 CRL 中。

以下步骤概述了通过设置 StsRefreshTokenValidFrom 字段更新授权令牌并使其失效的过程。

使用管理员凭据连接到 MSOL 服务：

$msolcred = get-credential connect-msolservice -credential $msolcred

检索用户的当前 StsRefreshTokensValidFrom 值：

$user = Get-MsolUser -UserPrincipalName [email protected]` $user.StsRefreshTokensValidFrom

将用户的新 StsRefreshTokensValidFrom 值配置为等于当前时间戳：

Set-MsolUser -UserPrincipalName [email protected] -StsRefreshTokensValidFrom ("03/05/2021")

所设日期必须属于将来。如果日期不属于将来，则不会设置 StsRefreshTokensValidFrom 属性。如果日期属于将来，则将 StsRefreshTokensValidFrom 设置为当前时间（而不是由 Set-MsolUser 命令指示的日期）。

步骤 4：测试配置测试证书

作为第一个配置测试，应尝试使用设备上的浏览器登录 Outlook Web Access 或 SharePoint Online。

如果登录成功，则可确定：

已为测试设备预配用户证书已正确配置 AD FS 测试 Office 移动应用程序在测试设备上，安装 Office 移动应用程序（例如 OneDrive）。启动应用程序。输入用户名，并选择要使用的用户证书。

应可以成功登录。

测试 Exchange ActiveSync 客户端应用程序

若要通过基于证书的身份验证访问 Exchange ActiveSync (EAS)，必须为应用程序提供包含客户端证书的 EAS 配置文件。

EAS 配置文件必须包含以下信息：

用于身份验证的用户证书

EAS 终结点（例如 outlook.office365.com）

通过使用 Microsoft Intune 等移动设备管理 (MDM) 或者手动将 EAS 配置文件中的证书放置在设备上，可以配置 EAS 配置文件并将其放置在设备上。

在 Android 上测试 EAS 客户端应用程序在应用程序中配置满足上一部分中要求的 EAS 配置文件。打开应用程序，验证邮件是否正在同步。后续步骤

有关 Android 设备上基于证书的身份验证的其他信息。

有关 iOS 设备上基于证书的身份验证的其他信息。

【本文地址】

使用联合的基于证书的身份验证

使用联合的基于证书的身份验证

今日新闻

推荐新闻