Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE

2026-02-05 19:32:24 -08:00 · 2025-02-10 00:25:06 +00:00
parent ad4b8a4f01
commit d7fdd67755
2 changed files with 51 additions and 50 deletions
--- a/src/pentesting-cloud/azure-security/az-basic-information/README.md
+++ b/src/pentesting-cloud/azure-security/az-basic-information/README.md
@@ -9,12 +9,12 @@
 ### 管理组

 - 它可以包含**其他管理组或订阅**。
- 这允许在管理组级别**应用治理控制**，如RBAC和Azure Policy，并让所有组内的订阅**继承**这些控制。
+- 这允许在管理组级别**应用治理控制**，如RBAC和Azure Policy，并使其**继承**到组内的所有订阅。
 - **单个目录**最多可以支持**10,000个管理组**。
 - 管理组树可以支持**最多六个层级的深度**。此限制不包括根级别或订阅级别。
 - 每个管理组和订阅只能支持**一个父级**。
 - 即使可以创建多个管理组，**只有1个根管理组**。
- 根管理组**包含**所有**其他管理组和订阅**，并且**不能被移动或删除**。
+- 根管理组**包含**所有**其他管理组和订阅**，并且**无法移动或删除**。
 - 单个管理组内的所有订阅必须信任**相同的Entra ID租户**。

 <figure><img src="../../../images/image (147).png" alt=""><figcaption><p><a href="https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png">https://td-mainsite-cdn.tutorialsdojo.com/wp-content/uploads/2023/02/managementgroups-768x474.png</a></p></figcaption></figure>
@@ -42,7 +42,7 @@ Azure 资源 ID 的格式如下：

 - `/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}`

-对于在订阅 ID `12345678-1234-1234-1234-123456789012` 下的资源组 `myResourceGroup` 中名为 myVM 的虚拟机，Azure 资源 ID 看起来像这样：
+对于在资源组`myResourceGroup`下，订阅 ID 为`12345678-1234-1234-1234-123456789012`的名为 myVM 的虚拟机，Azure 资源 ID 看起来像这样：

 - `/subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVM`

@@ -108,7 +108,7 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的
 - **访客用户对目录对象的属性和成员资格的访问有限（默认）**。这限制了访客访问仅限于他们自己的用户资料。对其他用户和组信息的访问不再允许。
 - **访客用户访问限制为仅限于他们自己目录对象的属性和成员资格**是最严格的。
 - **访客可以邀请**选项：
- **组织中的任何人都可以邀请访客用户，包括访客和非管理员（最包容） - 默认**
+- **组织中的任何人都可以邀请访客用户，包括访客和非管理员（最具包容性） - 默认**
 - **成员用户和分配给特定管理员角色的用户可以邀请访客用户，包括具有成员权限的访客**
 - **只有分配给特定管理员角色的用户可以邀请访客用户**
 - **组织中的任何人都不能邀请访客用户，包括管理员（最严格）**
@@ -133,7 +133,7 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的

 ### **服务主体**

-**服务主体**是为**应用程序**、托管服务和自动化工具创建的**身份**，用于访问 Azure 资源。此访问权限由分配给服务主体的角色**限制**，使您能够控制**可以访问哪些资源**以及访问的级别。出于安全原因，始终建议**使用服务主体与自动化工具**，而不是允许它们使用用户身份登录。
+**服务主体**是为**应用程序**、托管服务和自动化工具访问 Azure 资源而创建的**身份**。此访问权限由分配给服务主体的角色**限制**，使您能够控制**可以访问哪些资源**以及访问的级别。出于安全原因，始终建议**使用服务主体与自动化工具**，而不是允许它们使用用户身份登录。

 可以通过生成**密钥**（密码）、**证书**或授予对第三方平台（例如 GitHub Actions）的**联合**访问来**直接以服务主体身份登录**。

@@ -146,13 +146,13 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的

 #### 关键组件：

-1. **应用程序 ID（客户端 ID）：** 您的应用在 Azure AD 中的唯一标识符。
+1. **应用程序 ID（客户端 ID）：** Azure AD 中应用程序的唯一标识符。
 2. **重定向 URI：** Azure AD 发送身份验证响应的 URL。
 3. **证书、密钥和联合凭据：** 可以生成密钥或证书以作为应用程序的服务主体登录，或授予对其的联合访问（例如 GitHub Actions）。
 1. 如果生成了**证书**或**密钥**，则可以通过知道**应用程序 ID**、**密钥**或**证书**以及**租户**（域或 ID）来**以服务主体身份登录**。
-4. **API 权限：** 指定应用可以访问的资源或 API。
-5. **身份验证设置：** 定义应用支持的身份验证流程（例如，OAuth2、OpenID Connect）。
-6. **服务主体**：创建应用时会创建服务主体（如果是从网络控制台创建）或在新租户中安装时。
+4. **API 权限：** 指定应用程序可以访问的资源或 API。
+5. **身份验证设置：** 定义应用程序支持的身份验证流程（例如，OAuth2、OpenID Connect）。
+6. **服务主体**：创建应用程序时会创建服务主体（如果是从 Web 控制台创建）或在新租户中安装时创建。
 1. **服务主体**将获得其配置的所有请求权限。

 ### 默认同意权限
@@ -161,11 +161,11 @@ Entra 域服务通过提供**与传统 Windows Active Directory 环境兼容的

 - **不允许用户同意**
 - 所有应用程序都需要管理员批准。
- **允许用户对来自经过验证的发布者的应用程序进行同意，仅限于选定的权限（推荐）**
+- **允许用户对来自经过验证的发布者的应用程序进行同意，针对选定的权限（推荐）**
 - 所有用户可以对被分类为“低影响”的权限进行同意，适用于来自经过验证的发布者或在此组织中注册的应用程序。
 - **默认**低影响权限（尽管您需要接受将其添加为低影响）：
 - User.Read - 登录并读取用户资料
- offline_access - 保持对用户已授予访问权限的数据的访问
+- offline_access - 维护对用户已授予访问权限的数据的访问
 - openid - 登录用户
 - profile - 查看用户的基本资料
 - email - 查看用户的电子邮件地址
@@ -187,7 +187,7 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程
 - **系统分配**。某些 Azure 服务允许您**直接在服务实例上启用托管身份**。当您启用系统分配的托管身份时，会在资源所在的订阅中创建一个**服务主体**。当**资源**被**删除**时，Azure 会自动为您**删除**该**身份**。
 - **用户分配**。用户也可以生成托管身份。这些身份是在订阅内的资源组中创建的，并且将在 EntraID 中创建一个服务主体。然后，您可以将托管身份分配给一个或**多个 Azure 服务实例**（多个资源）。对于用户分配的托管身份，**身份与使用它的资源是分开管理的**。

-托管身份**不会生成永久凭据**（如密码或证书）以访问与其附加的服务主体。
+托管身份**不会生成永久凭据**（如密码或证书）以访问与其关联的服务主体。

 ### 企业应用程序

@@ -212,40 +212,34 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程
 - 将“用户管理员”角色授予区域 IT 员工，范围限制在其区域的 AU。
 - 结果：区域 IT 管理员可以管理其区域内的用户帐户，而不影响其他区域。

-### Entra ID 角色
+### Entra ID 角色和权限

 - 为了管理 Entra ID，有一些**内置角色**可以分配给 Entra ID 主体以管理 Entra ID
 - 在 [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference) 中查看角色
+- EntraID 标记为**`PRIVILEGED`**的角色应谨慎分配，因为正如微软在文档中所解释的那样 [在文档中](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)：特权角色分配如果不以安全和预期的方式使用，可能会导致权限提升。
 - 权限最高的角色是**全局管理员**
- 在角色描述中可以看到其**细粒度权限**
+- 角色组**细化权限**，可以在其描述中找到。
+- 可以**创建自定义角色**，以获得所需的权限。尽管由于某种原因，并非所有细化权限都可供管理员创建自定义角色。
+- Entra ID 中的角色与 Azure 中的角色完全**独立**。唯一的关系是，具有 Entra ID 中**全局管理员**角色的主体可以提升为 Azure 中的**用户访问管理员**角色。
+- 在 Entra ID 角色中**不可能使用通配符**。

-## 角色与权限
+## Azure 角色和权限

-**角色**是**分配**给**主体**的**范围**：`principal -[HAS ROLE]->(scope)`
-
-**分配给组的角色**会被组内的所有**成员继承**。
-
-根据角色分配的范围，**角色**可能会**继承**到范围容器内的**其他资源**。例如，如果用户 A 在订阅上有一个**角色**，他将在订阅内的所有资源组和资源组内的**所有资源**上拥有该**角色**。
-
-### 经典角色
-
-| **所有者**                     | <ul><li>对所有资源具有完全访问权限</li><li>可以管理其他用户的访问权限</li></ul> | 所有资源类型 |
-| ----------------------------- | ---------------------------------------------------------------------------------------- | ------------------ |
-| **贡献者**               | <ul><li>对所有资源具有完全访问权限</li><li>不能管理访问权限</li></ul>              | 所有资源类型 |
-| **读取者**                    | • 查看所有资源                                                                     | 所有资源类型 |
-| **用户访问管理员** | <ul><li>查看所有资源</li><li>可以管理其他用户的访问权限</li></ul>           | 所有资源类型 |
+- **角色**是**分配**给**主体**的，具有**范围**：`principal -[HAS ROLE]->(scope)`
+- **分配给组的角色**会被组内的所有**成员**继承。
+- 根据角色分配的范围，**角色**可能会**继承**到范围容器内的**其他资源**。例如，如果用户 A 在订阅上具有**角色**，他将在订阅内的所有资源组和资源组内的**所有资源**上拥有该**角色**。

 ### 内置角色

-[来自文档： ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 基于角色的访问控制（Azure RBAC）](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) 有几个 Azure **内置角色**，您可以将其**分配**给**用户、组、服务主体和托管身份**。角色分配是您控制**对 Azure 资源的访问**的方式。如果内置角色不满足您组织的特定需求，您可以创建自己的 [**Azure 自定义角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)**。**
+[来自文档：](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure 基于角色的访问控制（Azure RBAC）](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) 有几个 Azure **内置角色**，您可以将其**分配**给**用户、组、服务主体和托管身份**。角色分配是您控制**对 Azure 资源的访问**的方式。如果内置角色不满足您组织的特定需求，您可以创建自己的 [**Azure 自定义角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)。

-**内置**角色仅适用于**它们所针对的资源**，例如检查这两个**内置角色**在计算资源上的示例：
+**内置**角色仅适用于**它们所针对的资源**，例如检查这两个关于**计算**资源的**内置角色**示例：

-| [磁盘备份读取者](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | 提供备份库执行磁盘备份的权限。      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
+| [磁盘备份读取器](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | 提供备份库执行磁盘备份的权限。      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
-| [虚拟机用户登录](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 在门户中查看虚拟机并以普通用户身份登录。 | fb879df8-f326-4884-b1cf-06f3ad86be52 |
+| [虚拟机用户登录](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | 在门户中查看虚拟机并以常规用户身份登录。 | fb879df8-f326-4884-b1cf-06f3ad86be52 |

-这些角色也可以**分配给逻辑容器**（如管理组、订阅和资源组），受影响的主体将在这些容器内的资源上拥有它们。
+这些角色也可以**分配给逻辑容器**（如管理组、订阅和资源组），受影响的主体将在**这些容器内的资源上**拥有它们。

 - 在这里找到 [**所有 Azure 内置角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) 的列表。
 - 在这里找到 [**所有 Entra ID 内置角色**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) 的列表。
@@ -254,14 +248,14 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程

 - 也可以创建 [**自定义角色**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles)
 - 它们是在一个范围内创建的，尽管一个角色可以在多个范围内（管理组、订阅和资源组）
- 可以配置自定义角色将具有的所有细粒度权限
+- 可以配置自定义角色将具有的所有细化权限
 - 可以排除权限
- 拥有被排除权限的主体即使在其他地方授予权限也无法使用该权限
+- 拥有排除权限的主体即使在其他地方授予权限也无法使用该权限
 - 可以使用通配符
 - 使用的格式是 JSON
 - `actions` 指的是对资源进行管理操作的权限，例如创建、更新或删除资源定义和设置。
 - `dataActions` 是对资源内数据操作的权限，允许您读取、写入或删除资源中包含的实际数据。
- `notActions` 和 `notDataActions` 用于从角色中排除特定权限。但是，**它们并不拒绝这些权限**，如果其他角色授予它们，主体将拥有这些权限。
+- `notActions` 和 `notDataActions` 用于从角色中排除特定权限。但是，**它们不会拒绝这些权限**，如果其他角色授予它们，主体将拥有这些权限。
 - `assignableScopes` 是可以分配角色的范围数组（如管理组、订阅或资源组）。

 自定义角色的权限 JSON 示例：
@@ -296,16 +290,16 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程
 ```
 ### 权限顺序

- 为了让一个 **主体对资源有某些访问权限**，他需要被授予一个明确的角色（以任何方式）**授予他该权限**。
+- 为了让一个 **主体对资源有某种访问权限**，他需要被授予一个明确的角色（以任何方式）**授予他该权限**。
 - 明确的 **拒绝分配优先于** 授予权限的角色。

 <figure><img src="../../../images/image (191).png" alt=""><figcaption><p><a href="https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10">https://link.springer.com/chapter/10.1007/978-1-4842-7325-8_10</a></p></figcaption></figure>

 ### 全局管理员

-全局管理员是 Entra ID 的一个角色，授予 **对 Entra ID 租户的完全控制**。然而，默认情况下，它并不授予对 Azure 资源的任何权限。
+全局管理员是 Entra ID 的一个角色，授予 **对 Entra ID 租户的完全控制**。然而，它默认不授予对 Azure 资源的任何权限。

-拥有全局管理员角色的用户可以在根管理组中 **“提升”到用户访问管理员 Azure 角色**。因此，全局管理员可以管理 **所有 Azure 订阅和管理组的访问**。\
+拥有全局管理员角色的用户可以在根管理组中 '**提升' 为用户访问管理员 Azure 角色**。因此，全局管理员可以管理 **所有 Azure 订阅和管理组的访问**。\
 此提升可以在页面底部完成：[https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/\~/Properties](https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties)

 <figure><img src="../../../images/image (349).png" alt=""><figcaption></figcaption></figure>
@@ -318,7 +312,7 @@ Azure Active Directory 中的托管身份提供了一种**自动管理应用程

 与角色分配一样，**拒绝分配** 用于 **控制对 Azure 资源的访问**。然而，**拒绝分配** 用于 **明确拒绝对资源的访问**，即使用户通过角色分配获得了访问权限。**拒绝分配** 优先于 **角色分配**，这意味着如果用户通过角色分配获得了访问权限，但也通过拒绝分配被明确拒绝访问，则拒绝分配将优先。

-与角色分配一样，**拒绝分配** 应用于某个范围，指示受影响的主体和被拒绝的权限。此外，在拒绝分配的情况下，可以 **防止拒绝被子资源继承**。
+与角色分配一样，**拒绝分配** 适用于某个范围，指示受影响的主体和被拒绝的权限。此外，在拒绝分配的情况下，可以 **防止拒绝被子资源继承**。

 ### Azure 策略

@@ -335,7 +329,7 @@ Azure 策略是 **主动的**：它们可以阻止不合规资源的创建或更

 **一些示例：**

-1. **确保符合特定 Azure 区域的合规性**：此策略确保所有资源在特定 Azure 区域中部署。例如，一家公司可能希望确保其所有数据都存储在欧洲以符合 GDPR。
+1. **确保符合特定 Azure 区域的合规性**：此策略确保所有资源在特定 Azure 区域部署。例如，一家公司可能希望确保其所有数据存储在欧洲以符合 GDPR。
 2. **强制命名标准**：策略可以强制 Azure 资源的命名约定。这有助于根据名称组织和轻松识别资源，这在大型环境中非常有用。
 3. **限制某些资源类型**：此策略可以限制某些类型资源的创建。例如，可以设置策略以防止创建某些 VM 大小等昂贵资源类型，以控制成本。
 4. **强制标签策略**：标签是与 Azure 资源关联的键值对，用于资源管理。策略可以强制要求所有资源必须存在某些标签，或具有特定值。这对于成本跟踪、所有权或资源分类非常有用。
@@ -375,10 +369,10 @@ Azure 策略 JSON 示例：
 **RBAC**（基于角色的访问控制）是我们在前面的部分中已经看到的内容：**将角色分配给主体以授予其对资源的访问权限**。\
 然而，在某些情况下，您可能希望提供 **更细粒度的访问管理** 或 **简化** **数百个** 角色 **分配** 的管理。

-Azure **ABAC**（基于属性的访问控制）在 Azure RBAC 的基础上，通过在特定操作的上下文中添加 **基于属性的角色分配条件** 来构建。_角色分配条件_ 是您可以选择性地添加到角色分配中的 **额外检查**，以提供更细粒度的访问控制。条件过滤掉作为角色定义和角色分配一部分授予的权限。例如，您可以 **添加一个条件，要求对象具有特定标签才能读取该对象**。\
-您 **不能** 明确 **拒绝** **使用条件** 对特定资源的 **访问**。
+Azure **ABAC**（基于属性的访问控制）在 Azure RBAC 的基础上，通过在特定操作的上下文中添加 **基于属性的角色分配条件** 来构建。_角色分配条件_ 是您可以选择性地添加到角色分配中的 **额外检查**，以提供更细粒度的访问控制。条件过滤作为角色定义和角色分配的一部分授予的权限。例如，您可以 **添加一个条件，要求对象具有特定标签才能读取该对象**。\
+您 **不能** 明确 **拒绝** **对特定资源的访问** **使用条件**。

-## 参考
+## 参考文献

 - [https://learn.microsoft.com/en-us/azure/governance/management-groups/overview](https://learn.microsoft.com/en-us/azure/governance/management-groups/overview)
 - [https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions](https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/ready/azure-best-practices/organize-subscriptions)
--- a/src/pentesting-cloud/azure-security/az-services/az-azuread.md
+++ b/src/pentesting-cloud/azure-security/az-services/az-azuread.md
@@ -4,7 +4,7 @@

 ## 基本信息

-Azure Active Directory (Azure AD) 是微软基于云的身份和访问管理服务。它在使员工能够登录并访问资源方面发挥着重要作用，这些资源包括组织内部和外部的 Microsoft 365、Azure 门户以及众多其他 SaaS 应用程序。Azure AD 的设计重点在于提供基本的身份服务，尤其包括 **身份验证、授权和用户管理**。
+Azure Active Directory (Azure AD) 是微软的基于云的身份和访问管理服务。它在使员工能够登录并访问资源方面发挥着重要作用，这些资源包括组织内部和外部的 Microsoft 365、Azure 门户以及众多其他 SaaS 应用程序。Azure AD 的设计重点在于提供基本的身份服务，尤其包括 **身份验证、授权和用户管理**。

 Azure AD 的关键特性包括 **多因素身份验证** 和 **条件访问**，以及与其他 Microsoft 安全服务的无缝集成。这些特性显著提升了用户身份的安全性，并使组织能够有效实施和执行其访问政策。作为微软云服务生态系统的基本组成部分，Azure AD 对于基于云的用户身份管理至关重要。

@@ -365,7 +365,7 @@ $password = "ThisIsTheNewPassword.!123" | ConvertTo- SecureString -AsPlainText
 ```
 ### MFA & Conditional Access Policies

-强烈建议为每个用户添加 MFA，然而，一些公司可能不会设置它，或者可能会通过条件访问进行设置：用户在特定位置、浏览器或 **某些条件** 下登录时将 **需要 MFA**。如果这些策略配置不正确，可能会容易受到 **绕过**。请检查：
+强烈建议为每个用户添加 MFA，然而，一些公司可能不会设置它，或者可能会通过条件访问进行设置：用户将被 **要求 MFA 如果** 从特定位置、浏览器或 **某些条件** 登录。如果这些策略配置不正确，可能会容易受到 **绕过**。检查：

 {{#ref}}
 ../az-privilege-escalation/az-entraid-privesc/az-conditional-access-policies-mfa-bypass.md
@@ -482,7 +482,7 @@ Get-AzureADGroup -ObjectId <id> | Get-AzureADGroupAppRoleAssignment | fl *

 #### 将用户添加到组

-组的拥有者可以将新用户添加到组中
+组的所有者可以将新用户添加到组中
 ```bash
 Add-AzureADGroupMember -ObjectId <group_id> -RefObjectId <user_id> -Verbose
 ```
@@ -735,6 +735,13 @@ az ad app owner list --id <id> --query "[].[displayName]" -o table
 az ad app list --show-mine
 # Get apps with generated secret or certificate
 az ad app list --query '[?length(keyCredentials) > `0` || length(passwordCredentials) > `0`].[displayName, appId, keyCredentials, passwordCredentials]' -o json
+# Get Global Administrators (full access over apps)
+az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1b2256f9-46c1-4fc2-a125-5b2f51bb43b7/members"
+# Get Application Administrators (full access over apps)
+az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/1e92c3b7-2363-4826-93a6-7f7a5b53e7f9/members"
+# Get Cloud Applications Administrators (full access over apps)
+az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d601d27-7b9c-476f-8134-8e7cd6744f02/members"
+
 ```
 {{#endtab }}

@@ -792,7 +799,7 @@ Get-AzureADApplication -ObjectId <id> | Get-AzureADApplicationOwner |fl *
 > 应用在请求令牌时用来证明其身份的秘密字符串是应用密码。\
 > 因此，如果找到这个 **密码**，你可以作为 **服务主体** **访问** **租户**。\
 > 请注意，这个密码仅在生成时可见（你可以更改它，但无法再次获取）。\
-> **应用** 的 **所有者** 可以 **添加密码**（以便他可以冒充它）。\
+> **应用程序** 的 **所有者** 可以 **添加密码**（以便他可以冒充它）。\
 > 作为这些服务主体的登录 **不会被标记为风险**，并且 **不会有 MFA**。

 可以在 [https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/governance/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications](https://learn.microsoft.com/en-us/troubleshoot/entra/entra-id/governance/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications) 找到属于 Microsoft 的常用应用 ID 列表。
@@ -980,7 +987,7 @@ Get-AzureADMSRoleDefinition | ?{$_.IsBuiltin -eq $False} | select DisplayName
 # 被分配角色的用户（全局管理员）
 Get-AzureADDirectoryRole -Filter "DisplayName eq 'Global Administrator'" | Get-AzureADDirectoryRoleMember
 Get-AzureADDirectoryRole -ObjectId <id> | fl
-# 行政单位的角色（谁对行政单位及其成员拥有权限）
+# 管理单位的角色（谁对管理单位及其成员拥有权限）
 Get-AzureADMSScopedRoleMembership -Id <id> | fl *
 ```

@@ -993,7 +1000,7 @@ Get-AzureADMSScopedRoleMembership -Id <id> | fl *
 {{#tab name="az cli" }}

 ```bash
-# 如果你知道如何做到这一点，请发送 PR！
+# 如果你知道如何做到这一点，请发送一个 PR！
 ```

 {{#endtab }}