使用 PowerShell 管理条件访问 (CA) 策略

Microsoft 提供了多种方法来管理租户的数据和用户。 PowerShell 是一个强大的工具，用于管理资源，包括使用 AzureAD 模块中的一组 cmdlet 的条件访问策略。在本文中，我们回顾了八个 PowerShell cmdlet 以及如何使用它们。

**请注意，AzureAD 和 AzureADPreview PowerShell 模块都包含这些 cmdlet。

PowerShell 和 CA 策略

首先，使用 AzureAD 或 AzureADPreview 模块连接到 Azure Active Directory：
Connect-AzureAD

连接后，我们可以使用这两个单行代码获取可用的 PowerShell cmdlet 列表：
Get-Command *conditional*
Get-Command *named*

结合起来，我们总共得到处理条件访问策略和名称位置策略的八个 cmdlet：
Get-AzureADMSConditionalAccessPolicy
新建 AzureADMSConditionalAccessPolicy
删除-AzureADMSConditionalAccessPolicy
设置-AzureADMSConditionalAccessPolicy

获取-AzureADMSNamedLocationPolicy
新-AzureADMSNamedLocationPolicy< br>删除-AzureADMSNamedLocationPolicy
设置-AzureADMSNamedLocationPolicy

条件访问策略设置条件以确定用户接收应用程序访问权限的条件。这些条件可以包括位置、一个或多个用户、应用程序、平台等。

在以下示例中，我们将检查这些条件，看看可以使用 PowerShell 配置哪些内容。

创建新的条件访问策略

绿地或新租户没有条件访问策略。为了利用条件访问，我们需要构建它的条件。如果需要命名位置，我们需要首先创建命名位置。让我们使用示例场景来演示此过程。

指定地点

条件访问策略可以包含与组织环境中的物理位置相对应的命名位置。命名位置可以是具有相应 IP 子网/范围的物理位置，也可以是单个国家/地区/一组国家/地区。我们可以使用命名位置来提供一个条件，控制在何处提示（或不提示）用户进行 MFA 或其他可选操作。在 Azure AD 模块中，我们看到有四个 PowerShell cmdlet 用于管理命名位置并运行典型的 Get、New、Remove 和 Set PowerShell 动词。

在新的或新建的 Azure AD 中，没有可供条件访问使用的命名位置，我们需要在 Azure AD 中或使用 PowerShell 创建这些位置。要创建新的命名位置策略，我们需要使用 New-AzureADMSNamedLocationPolicy cmdlet。

创建新的命名位置时，我们需要记住以下几点：

显示名称为必填项
需要选择 IP 范围或国家/地区列表，因为这决定了我们要创建的指定位置的类型。

对于第一个指定位置，我们可以使用一些基本标准 - 芝加哥办公室，IP 范围为 10.25.0.0，子网掩码为 16 位，我们将将此位置标记为受信任位置。还可以为纽约办事处创建第二个位置，其 IP 范围为 10.26.0.0，并且具有相同的 16 位子网掩码。创建命名位置需要 PowerShell。请注意，在下面的示例中，办公室的 IP 子网有一个 MS Graph 对象。

示例：
IT 希望条件访问策略强制对所有云应用程序进行多重身份验证 (MFA)，除非用户从两个位置访问应用程序。这些位置都是芝加哥和纽约的物理办公室，子网分别为 10.25.0.0/16 和 10.26.0.0/16。我们将首先使用 New-AzureADMSNamedLocationPolicy 创建两个命名位置，然后使用 New-AzureADMSConditionalAccessPolicy 创建一个新的 CA 策略来引用这些位置：
$CHISubnet=New-Object -TypeName Microsoft.Open.MSGraph.Model.IpRange
$CHISubnet.cidrAddress='10.25.0.0/16'
New-AzureADMSNamedLocationPolicy -OdataType “#microsoft.graph.ipNamedLocation” -DisplayName '芝加哥办公室' -IsTrusted $True -IpRanges $CHISubnet
$NYSubnet=New-Object -TypeName Microsoft.Open.MSGraph.Model.IpRange
$NYSubnet.cidrAddress='10.26.0.0/16'
New-AzureADMSNamedLocationPolicy -OdataType “#microsoft.graph.ipNamedLocation” -DisplayName 'New York Office' -IsTrusted $True -IpRanges $NYSubnet

我们可以使用 Get-AzureADMSNamedLocationPolicy cmdlet 验证位置的属性，在继续之前我们应该做的事情：

** 公平地说，创建命名位置时也会生成相同的输出，但上面说明了使用命名位置 cmdlet 的 Get-* 部分可以看到的内容。

创建命名位置后，我们现在可以将它们用于 CA 策略（请记住，CA 策略有很多设置）。首先，我们需要一个对象来保存 CA 策略的条件（应用程序、用户和位置）。 ConditionalAccessConditionSet 中可用条件的详细信息在此处定义。
$CAConditions=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet
$CAConditions.Applications=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessApplicationCondition
$CAConditions.Applications.IncludeApplications='全部'

在本节中，我们定义要应用条件访问策略的用户 (Users.ExcludeUsers) 以及我们希望排除的任何用户 (Users.ExcludeUsers)。在这种情况下，排除的用户是一个 Break Glass 帐户，它被排除在我们定义的任何策略之外，并在下面显示为 Azure AD 中用户的对象 GUID。位置的 GUID 位于 ID 字段中，如图 2 所示。
$CAConditions.Users=New-Object -TypeName Microsoft.Open.MSGraph .Model.ConditionalAccessUserCondition
$CAConditions.Users.IncludeUsers='全部'
$CAConditions.Users.ExcludeUsers='22561a78-a72e-4d39-898d-cd7c57c84ca6'
$CAConditions.Locations=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition
$CAConditions.Locations.IncludeLocations='0743ff81-cea0-40d2-b0f0-4028cdc1c61a','0f0c7a7f-4863-480e-9b71-d8f9eddb37e4'

** 请小心“所有”应用程序并且“所有”用户设置，因为这也会影响 Azure AD 门户，这意味着您可能会被锁定在门户之外，并且无法更改您的 CA 策略。确保创建并排除了 Break Glass 帐户，如下所示 [Users.ExcludeUsers]。有关 Break Glass 帐户的更多信息，请参阅此博客文章。

接下来，我们需要为 MFA 要求配置授予控制。与上面的条件一样，我们还需要一个 Graph 对象并提供一个运算符（“Or”/“And”）以及控件，在我们的示例中为 MFA:
$CAControls=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls
$CAControls._Operator=“或”
$CAControls.BuiltInControls=“Mfa”

**可以在此处找到可用的内置控件列表。

策略设置摘要：

适用于所有云应用
应用于 Azure AD 中的所有用户
不能申请一个账户
为这些用户和这些应用程序强制执行 MFA
包括两个不执行 MFA 的名称位置

现在，我们的 $CAConditions 对象和 $CAControls 对象已填充了所需的设置，并且可以使用它根据我们的初始要求创建 CA 策略：
新建-AzureADMSConditionalAccessPolicy -DisplayName“CloudApps-MFA-CorpWide” -状态“已启用” -Conditions $CAConditions -GrantControls $CAControls

Id              : cb14d13f-6ecb-4113-b684-cb6ace507edd
DisplayName     : CloudApps-MFA-CorpWide
State           : enabled
Conditions      : class ConditionalAccessConditionSet {
                    Applications: class ConditionalAccessApplicationCondition {
                    IncludeApplications: System.Collections.Generic.List`1[System.String]
                    ExcludeApplications: System.Collections.Generic.List`1[System.String]
                    IncludeUserActions: System.Collections.Generic.List`1[System.String]
                    IncludeProtectionLevels:
                  }

                    Users: class ConditionalAccessUserCondition {
                    IncludeUsers: System.Collections.Generic.List`1[System.String]
                    ExcludeUsers: System.Collections.Generic.List`1[System.String]
                    IncludeGroups: System.Collections.Generic.List`1[System.String]
                    ExcludeGroups: System.Collections.Generic.List`1[System.String]
                    IncludeRoles: System.Collections.Generic.List`1[System.String]
                    ExcludeRoles: System.Collections.Generic.List`1[System.String]
                  }

                    Platforms:
                    Locations: class ConditionalAccessLocationCondition {
                    IncludeLocations: System.Collections.Generic.List`1[System.String]
                    ExcludeLocations: System.Collections.Generic.List`1[System.String]
                  }

                    UserRiskLevels: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessRiskLevel]
                    SignInRiskLevels: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessRiskLevel]
                    ClientAppTypes: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessClientApp]
                    Devices:
                  }

GrantControls   : class ConditionalAccessGrantControls {
                    _Operator: OR
                    BuiltInControls: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControl]
                    CustomAuthenticationFactors: System.Collections.Generic.List`1[System.String]
                    TermsOfUse: System.Collections.Generic.List`1[System.String]
                  }

SessionControls :
Figure: Output from New-AzureADMSConditionalAccessPolicy cmdlet.

不幸的是，由于属性包含复杂的数据集，因此该 CA 策略的所有设置都被“System.Collections”混淆了。要验证 CA 策略的设置，我们必须分解每个条件以查看存在的内容。应用程序、用户和位置都是 CA 策略上 Conditions 属性的子属性；因此，我们可以像这样分解每个部分：
((Get-AzureADMSConditionalAccessPolicy).Conditions).Applications

IncludeApplications ExcludeApplications IncludeUserActions IncludeProtectionLevels
------------------- ------------------- ------------------ -----------------------
{All}               {}                  {}

((Get-AzureADMSConditionalAccessPolicy).Conditions).Users

IncludeUsers  : {All}
 ExcludeUsers  : {22561a78-a72e-4d39-898d-cd7c57c84ca6}
 IncludeGroups : {}
 ExcludeGroups : {}
 IncludeRoles  : {}
 ExcludeRoles  : {}

((Get-AzureADMSConditionalAccessPolicy).Conditions).Locations

IncludeLocations                                                             ExcludeLocations
----------------                                                             ----------------
{0743ff81-cea0-40d2-b0f0-4028cdc1c61a, 0f0c7a7f-4863-480e-9b71-d8f9eddb37e4} {}

在所有情况下，应用程序、用户和位置都在条件访问策略中作为 ObjectId 列出。如果生成报告用于管理，则需要额外的 PowerShell 查询来将这些值转换为名称。将 ObjectId 转换为名称也有助于验证或记录/审核 CA 策略。

更改现有条件访问策略

现在我们已经有了 CA 策略，我们可以使用 PowerShell 来更新应用程序、用户、位置和控件以及其他未配置的项目，例如平台和登录风险。

更改 CA 策略的执行
可以实施的一项更改是更改 CA 策略的状态。 CA 策略具有三种状态：EnabledForReportingButNotEnforced、Enabled 和Disabled。例如，如果部署了新的 CA 策略，并且在公司内部时提示用户进行 MFA，则该策略可能会被禁用或设置为仅在执行故障排除之前报告：
设置-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -状态已禁用
设置-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -State EnabledForReportingButNotEnforced

有效禁用策略后，IT 现在可以更改策略、验证策略，然后重新启用策略：
Set-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163 -State Enabled

更改 CA 策略控制
在前面的示例中，需要在以下情况下出现 MFA 提示：使用云应用程序并从两个指定位置外部进行连接。如果需要额外的安全要求或可能的替代方案（Azure AD 加入/合规性），也可以调整这些控制。 CA 策略的控制也可以与上一示例中的单一控制 (OR) 相结合 (AND)。

例如，如果我们想添加，当用户访问外部云应用程序时，他们需要从合规设备执行此操作，并且必须提示他们进行 MFA，我们可以通过创建一个新的 Control 对象，然后应用来实现这一点这适用于现有的 CA 政策。合规设备是指满足预定义条件（例如操作系统版本级别、未越狱等）的指定标准列表的设备。首先是控件：
$CAControls=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessGrantControls
$CAControls._Operator=“AND”
$CAControls.BuiltInControls=“Mfa”,”CompliantDevice”

请注意，我们有一个 AND 运算符，它声明两个 Control 都必须为 true。另外，值得注意的是，配置的控件是 MFA 和兼容设备。然后，这些控件将应用于现有 CA 策略，覆盖任何现有设置：
Set-AzureADMSConditionalAccessPolicy -PolicyId 21bdd8c1-bb5c-40d1-a4de-926888c69163s - GrantControls $CAControls

前：

_Operator BuiltInControls CustomAuthenticationFactors TermsOfUse
 
 OR        {Mfa}           {}                          {}

后：

_Operator BuiltInControls CustomAuthenticationFactors TermsOfUse 

AND        {Mfa, CompliantDevice} {}                   {}

现在，我们可以将其放在一行中，如下所示：
Remove-AzureADMSConditionalAccessPolicy -PolicyId 7ac2fcee-d5bd-4003-ad10-5dfa838417da

不会给出任何提示，因此删除 CA 策略时要小心。

指定地点

如前所述，条件访问策略使用命名位置的概念来对应组织环境中的物理位置。我们可以使用 Get-AzureADMSNamedLocationPolicy 来比较 PowerShell 中显示的内容和 Azure AD 门户中显示的命名位置的内容。这对于验证配置以及了解两个显示器之间的差异非常有用：

修改现有命名位置

组织随着时间的推移而变化，这可能意味着命名位置需要进行更改。例如，您可能需要重命名位置、添加子网、删除子网、将其标记为受信任或删除信任。所有这些更改都可以使用 Set-AzureADMSNamedLocationPolicy cmdlet 执行。让我们看看如何才能做出这些改变：

更改命名位置“名称”
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -DisplayName 'Chicago Loop Office'
更改 IP 范围
$ipRanges=New-Object -TypeName Microsoft.Open .MSGraph.Model.IpRange
$ipRanges.cidrAddress='10.25.0.0/16'
设置-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IpRanges $ipRanges -OdataType“#microsoft.graph.ipNamedLocation”
<可信
Set-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IsTrusted $False
设置-AzureADMSNamedLocationPolicy -PolicyId 0743ff81-cea0-40d2-b0f0-4028cdc1c61a -IsTrusted $True

删除指定位置

当办公室关闭或不再需要条件访问策略时，如果愿意，可以删除指定位置。保留命名位置不会产生安全风险。我们首先需要确定是否存在包含该位置的现有条件访问策略。我们可以从 CA 策略的 Conditions 属性中挑选这些内容，并查看 Locations 子属性，该属性将位置存储为 System.Collections.Generic.List：

Locations: class ConditionalAccessLocationCondition {
IncludeLocations: System.Collections.Generic.List`1[System.String] 
ExcludeLocations: System.Collections.Generic.List`1[System.String]

我们可以显示 GUID：
((Get-AzureADMSConditionalAccessPolicy).Conditions).Locations

IncludeLocations ExcludeLocations
---------------- ----------------
{088f361c-4103-43e1-a11d-0394018ab62b} {}

假设我们需要删除我们的芝加哥办事处，这是一个指定位置：

OdataType : #microsoft.graph.ipNamedLocation
Id : 088f361c-4103-43e1-a11d-0394018ab62b
DisplayName : Chicago Office
IpRanges : {class IpRange {
CidrAddress: 10.25.0.0/16
}
}
IsTrusted : True
CountriesAndRegions :
IncludeUnknownCountriesAndRegions :

我们可以使用“Id”值来匹配 CA 中的 Locations.IncludeLocations 值。要查找具有此命名位置的任何 CA 策略，我们需要像这样匹配值：
$OldNamedLocationId=(Get-AzureADMSNamedLocationPolicy |Where {$_ .DisplayName -eq '芝加哥办公室'}).Id
$CAPolicies=Get-AzureADMSConditionalAccessPolicy
Foreach（$CAPolicy中的$CAPolicy）{
If（$OldNamedLocationId -eq((($CAPolicy).Conditions).Locations).IncludeLocations) {
写入主机“CA 策略 $ ($CAPolicy.Id) 包含命名位置。”
}
}

我们可能只有一个位置，也可能有多个位置，但都会显示所有匹配的条目：
CA 策略 4e7dac6d-d471-483f-9677-46407acaa3f5 包含指定位置。
我们可以决定删除该策略或仅删除指定位置。如果指定位置是唯一的，那么我们需要替换它以保留 CA 策略。对于本示例，我们将用另一个命名位置替换该位置。首先，查找任何非芝加哥办公室命名位置：
Get-AzureADMSNamedLocationPolicy |其中 {$_.DisplayName -ne ‘芝加哥办公室’} | ft 显示名称，Id

DisplayName Id
----------- --
New York Office 0fae649d-a695-4761-9a83-cd20a96d0739

然后，我们使用此位置中的 ID 来替换需要删除的 ID：
$OldNamedLocationId=(Get-AzureADMSNamedLocationPolicy |Where {$_.DisplayName -eq '芝加哥办公室'}).Id
$NewNamedLocationId=(Get-AzureADMSNamedLocationPolicy | 其中 {$_.DisplayName -eq '洛杉矶办公室 Office'}).Id
$conditions=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessConditionSet
$conditions.Locations=New-Object -TypeName Microsoft.Open.MSGraph.Model.ConditionalAccessLocationCondition
$conditions.Locations.IncludeLocations =“$NewNamedLocationId”
Foreach ($$CAPolicies 中的 CAPolicy) {
If ($OldNamedLocationId-eq ((($CAPolicy).Conditions).Locations).IncludeLocations) {
Set-AzureADMSConditionalAccessPolicy -PolicyId $ ($CAPolicy.ID) -Conditions $Conditions
< span class =“crayon-inline lang：默认解码：true”>}
}

现在，我们重新运行相同的代码块，以查找具有指定位置的 CA 策略：
$NamedLocationId=(Get-AzureADMSNamedLocationPolicy |Where { $_.DisplayName -eq '芝加哥办公室'}).Id
$CAPolicies=Get-AzureADMSConditionalAccessPolicy
Foreach（$CAPolicies 中的 $CAPolicy）{
If ( $NamedLocationId -eq((($CAPolicy).Conditions).Locations).IncludeLocations) {
写入主机“CA 策略 & #36 ($CAPolicy.ID) 包含命名位置。”
}
}

Remove-AzureADMSNamedLocationPolicy -PolicyId $OldNamedLocationId

**提示：确保从条件访问策略中删除命名位置
如果我们尝试删除条件访问策略中定义的命名位置，则会生成错误。这是因为命名位置附加到条件访问策略，需要首先删除。

最后的想法

从文章中我们可以看到，微软提供了一组PowerShell cmdlet，为条件访问策略提供了便捷的访问点。可以像使用这些 cmdlet 一样创建、修改甚至删除这些 CA 策略。我们还有用于创建命名位置的 cmdlet，条件访问策略又可以使用命名位置。这些 cmdlet 的潜在用途包括 CA 策略的创建和管理，以及需要验证组织安全状况的安全人员/顾问的策略记录和审核。请务必阅读本文中提供的文档链接以及 cmdlet 的获取帮助，以获取有关用于策略的各个移动部分（位置、平台、授予控制、会话控制等）的值的指导。

使用 PowerShell 管理条件访问 (CA) 策略

PowerShell 和 CA 策略

创建新的条件访问策略

指定地点

更改现有条件访问策略

指定地点

修改现有命名位置

删除指定位置

最后的想法

相关文章