24、ConfigMgr常见问题与安全配置全解析

ConfigMgr常见问题与安全配置全解析

1. 常见环境问题理解

在较大的多区域环境中，若要为所有区域启用并配置清理功能，可右键单击 DNS 服务器而非区域进行操作。但需注意，此操作会影响所有区域，若需要针对每个区域进行精细的清理设置，则不宜采用该方法。

在排查 DNS 问题时，在系统的 HOSTS 文件中创建手动条目会很有帮助，因为这样可以直接控制系统如何解析特定名称。不过，操作完成后要记得清理，因为本地 HOSTS 文件的优先级高于其他所有名称解析方法。

2. 管理权限

ConfigMgr 主站点服务器要正常工作，需要对自身以及层次结构中其下的每个其他服务器拥有完全管理员权限。通常，可通过将计算机对象帐户（例如 MOL\CM01$）手动添加到本地管理员组来实现，也可以使用组策略。推荐使用组策略，因为它可以进行集中控制和审计。

在授予帐户本地管理员访问权限时，要避免将该帐户添加到“Domain Admins”组。虽然“Domain Admins”组自动拥有对每个加入域的系统的本地管理员访问权限，但这种方法会赋予该帐户过多的特权访问权限，甚至可能被视为安全漏洞。

当使用组策略或其他机制配置本地管理员成员资格，而该机制未考虑 ConfigMgr 权限要求时，就可能出现问题。ConfigMgr 原本可能运行正常，但由于配置不当的策略，可能会导致站点角色被标记为不健康、内容分发失败，以及站点服务器对自身或其他站点服务器发起的任何操作都会出现问题。日志可能会显示明确的“Access denied”错误消息，这有助于缩小问题范围。

若无法控制环境中基于策略的权限，就很难防止此类问题发生。因此，要确保相关管理员在生产环境中进行重大更改之前，先与 ConfigMgr 管理员进行沟通。

3. 互联网访问

托管软件更新点和/或资产智能同步点角色的 ConfigMgr 站点服务器需要能够通过互联网与 Microsoft 通信，以获取最新的元数据和更新内容。在某些组织中，可直接让服务器具备对外通信的能力，这是最简单的方法。但在许多组织中，只有特定服务器具有直接互联网访问权限，其他服务器要么无访问权限，要么通过正向代理访问。

若要配置站点服务器通过代理进行通信，可按以下步骤操作：
1. 导航至“Administration > Site Configuration > Servers and Site System Roles”。
2. 选择相关的站点系统（例如 CM01.mol.sccmlab.net）。
3. 选择窗格底部的站点系统角色，右键单击并选择“Properties”。
4. 在“Proxy”选项卡中，输入相关代理服务器的详细信息和凭据。

若要配置 ConfigMgr 通过代理服务器进行通信，可能会遇到代理成为瓶颈的问题，例如代理阻止访问特定的 Microsoft URL，或者在将内容释放给 ConfigMgr 服务器之前进行本地缓存和处理。无论问题原因是什么，ConfigMgr 都无法知晓代理服务器上发生的情况，会将其视为一般的互联网访问失败。遇到此类情况，需要与网络团队密切合作，找出问题所在。所有企业网络代理都支持实时故障排除，因此网络团队应该能够确切了解发生了什么以及如何解决。

持续关注 wsyncmgr.log 文件，可快速发现是否存在互联网访问问题。

4. 实验室操作

磁盘空间不足对 ConfigMgr 来说可能是个大问题，但除了托管站点数据库和日志文件的磁盘外，ConfigMgr 不会主动监控可用空间。可通过以下操作解决此问题：
1. 修改硬件清单类以包含可用空间。
2. 将策略和 ConfigMgr 代理（如有必要）部署到 CM01，以便开始收集可用磁盘空间数据。
3. 根据这些数据创建新的设备集合（例如“All Site Servers with <10% Free Space”）。
4. 运行报告以确保数据收集正常。

如果有足够的实验室环境资源，可尝试启动 System Center Operations Manager (SCOM) 实例，在 CM01 上安装 SCOM 代理，并配置 SCOM 收集可用空间数据。若实验室中没有足够的可用资源安装 SCOM，也可以注册 Azure 试用版并启用 Operations Management Suite (OMS)，在 CM01 上安装 OMS 代理并收集可用磁盘空间数据。

5. 管理用户

管理用户是访问 ConfigMgr 的入口。ConfigMgr 管理用户的基本定义是“任何可以登录 ConfigMgr 执行操作的用户或组成员”。管理用户可以是从权限最低的帮助台人员到完整的 ConfigMgr 站点管理员等任何角色。访问级别取决于其他因素，但如果未被列为管理用户，则无法访问 ConfigMgr。

要查看当前的管理用户列表，可在 ConfigMgr 控制台中导航至“Administration > Security > Administrative Users”。默认情况下，可能只有一个用户（MOL\Administrator），且该用户帐户被分配到“Full Administrator”安全角色，这是在安装过程中设置的。首次安装和配置 ConfigMgr 时，至少需要一个“Full Administrator”，因此安装程序会自动将执行安装的用户帐户配置为默认管理员。

最佳实践是不手动为单个用户分配管理访问权限，因为这样很难进行有效审计。推荐使用安全组，创建新的管理组的步骤如下：
1. 在 DC01 上，启动“Active Directory Users and Computers”。
2. 展开“mol.sccmlab.net > MoL > Security Groups”。
3. 右键单击并选择“New > Group”，将组命名为“ConfigMgr Admins”。
4. 导航至“mol.sccmlab.net > MoL > Users”。
5. 右键单击用户帐户“Bob”并选择“Add to a group”。
6. 在对象名称字段中输入“ConfigMgr Admins”，然后单击“OK”，该帐户应成功添加到新组。
7. 在 ConfigMgr 控制台的“Administrative Users”下，右键单击并选择“Add User or Group”。
8. 单击“Browse”并输入“ConfigMgr Admins”，然后单击“OK”。
9. 对于“Assigned Security Roles”，单击“Add”，然后选择“Full Administrator”复选框。
10. 选择“All Instances of the objects that are related to the assigned security roles”，然后单击“OK”。

新组现在将被列为管理用户。要测试其功能，可按以下步骤操作：
1. 关闭 ConfigMgr 控制台。
2. 转到“Start”，右键单击“Configuration Manager Console”图标，选择“Run as different user”。
3. 提示输入凭据时，输入用户名“Bob”和密码“P@ssw0rd”。
4. 控制台将以与 MOL\Administrator 相同的访问级别启动，尽管 MOL\Bob 在 mol.sccmlab.net 活动目录层次结构中只是一个标准用户。

ConfigMgr 完全管理员还需要在层次结构中的每个服务器上具有明确的权限。在 ConfigMgr 中将用户/组分配为“Full Administrator”不会对底层操作系统进行任何更改，因此应使用组策略等机制分配适当的权限。

6. 安全角色

安全角色是实现权限细化的开始。角色是权限的集合，这些权限定义了在 ConfigMgr 数据库中的每个可安全保护的项目上可以执行和不可以执行的操作。收集在一起的权限被定义为一个角色。

在 ConfigMgr 控制台中，导航至“Administration > Security > Security Roles”，可以看到 15 个内置角色，涵盖了从“Full Administrator”到“Read-only Analyst”等广泛的常见 ConfigMgr 角色。右键单击“Application Administrator”角色并选择“Properties”，然后转到“Permissions”选项卡，可以看到该角色定义了对所有 ConfigMgr 可安全保护项目的权限。某些项目（如“Boundaries”和“Boundary Groups”）仅被分配了“Read”访问权限，因此“Application Administrators”组的成员可以查看有关边界的信息，但无法以其他方式主动管理它们。

所有内置安全角色的权限都是锁定的，无法编辑其值。这是一种保护功能，可防止有人意外减少关键角色（如“Full Administrator”）的访问权限，从而导致管理员无法访问 ConfigMgr，需要采取重大恢复措施。内置角色几乎涵盖了可能遇到的所有管理场景，但如果需要应用一些自定义权限，可以使用现有角色作为模板。创建自定义安全角色的步骤如下：
1. 右键单击“Application Administrator”并选择“Copy”。
2. 会弹出一个窗口，让你创建一个新的安全角色，该窗口已预先填充了内置“Application Administrator”角色的所有权限。
3. 将新角色命名为“MoL – Application Administrator”。
4. 在“Permissions”下，展开“Configuration Item”，将“Read and Modify”更改为“Yes”，然后单击“OK”。

在创建基于现有内置对象的新对象时，使用自定义前缀（例如“MoL”）是个好主意，这样可以让任何人都能立即清楚哪些是自定义对象。现在有了一个新的安全角色，可以进一步更改其权限（自定义角色的权限可以编辑），还可以将角色定义导出到 XML 文件。这在对现有角色进行更改之前创建备份（基本版本控制），或者在不同的 ConfigMgr 层次结构中重新创建该角色时非常有用，因为可以在不同的 ConfigMgr 服务器上导入 XML 文件，而无需手动复制和自定义内置角色。

7. 安全范围

安全角色可以很好地限制人们在 ConfigMgr 中可以执行的操作，但当某人有权限执行某项操作时，他可以对该对象的每个实例执行该操作。例如，如果用户有权删除应用程序，那么他可以删除任何应用程序。在小型环境中这可能没问题，但在有专门团队的大型环境中，这不是个好主意。这时就需要安全范围发挥作用。

安全范围在 ConfigMgr 中就像一个限制过滤器。范围本身不提供或强制执行权限，权限由角色来实现。范围的作用是限制可以行使这些权限的对象。例如，组织中有两个 IT 团队：桌面团队和服务器团队。通过将特定于每个团队的对象（如应用程序、软件更新、配置基线和操作系统部署）分配到自定义安全范围，可以确保每个团队只能与与其相关的对象进行交互，防止影响到其他团队管理的对象。

创建安全范围的步骤如下：
1. 导航至“Administration > Security > Security Scopes”。
2. 右键单击并选择“Create Security Scope”。
3. 将新范围命名为“MoL – Desktops”，然后单击“OK”。
4. 重复上述过程，创建第二个新范围“MoL – Servers”。

创建范围很简单，但范围本身作用不大，需要将其分配给可安全保护的项目：
1. 导航至“Software Library > Application Management”。
2. 右键单击应用程序“Paint.NET”并选择“Set Security Scopes”。
3. 取消勾选“Default”范围，勾选“MoL – Desktops”范围。
4. 导航回“Security Scopes”，可以看到“MoL – Desktops”范围现在被标记为“In Use”。

所有可以属于安全范围的项目必须至少属于一个范围，这就是默认范围的作用，因此不能删除或修改默认范围。另一个内置范围是“all”范围，分配到“all”范围的管理用户对所有可安全保护的项目具有权限，实际上会忽略所有其他范围，使用时需谨慎。

8. 精细权限

ConfigMgr 中的有效精细权限是前面所有工作的结果。精细权限通常在组织需要保护系统免受用户误操作时使用，这并非因为用户无能或不可信，而是为了确保一个管理员不会意外破坏另一个管理员的工作。

例如，至少需要有一个“Full Administrator”了解 ConfigMgr 环境的所有信息并能进行任何必要的更改，但将相同级别的访问权限授予只需要使用远程控制工具的帮助台技术人员是不合理的。授予“Full Administrator”访问权限可能很简单，但会使组织面临潜在风险。此外，如果帮助台技术人员并非 ConfigMgr 专家，在没有管理边界的情况下将其置于庞大的系统中也是不公平的。

要实现精细权限，可按以下步骤操作：
1. 重复前面创建管理组的步骤，在活动目录中创建两个新组：
- ConfigMgr Application Admins – Desktops
- ConfigMgr Application Admins – Servers
2. 将用户“Frank”添加到“ConfigMgr Application Admins – Desktops”组。
3. 将用户“Johan”添加到“ConfigMgr Application Admins – Servers”组。
4. 在 ConfigMgr 控制台中，创建一个新的管理用户，设置如下：
- 用户或组名称：MOL\ ConfigMgr Application Admins – Desktops
- 分配的安全角色：MoL – Application Administrator
- 安全范围和集合：
- 移除所有默认实例
- 添加安全范围“MoL – Desktops”
- 添加集合“All Windows Workstation Clients”
- 添加集合“All Users and User Groups”
5. 创建另一个管理用户，设置如下：
- 用户或组名称：MOL\ ConfigMgr Application Admins – Servers
- 分配的安全角色：MoL – Application Administrator
- 安全范围和集合：
- 移除所有默认实例
- 添加安全范围“MoL – Servers”
- 添加集合“All Server Clients”

每个新的管理用户基于不同的 AD 组，每个组的成员不同。每个管理用户被分配到相同的安全角色，因此具有相同的权限，但被分配到不同的安全范围和不同的用户及设备集合。没有将“All Users and User Groups”集合分配给“ConfigMgr Application Admins – Servers”组，是因为在处理服务器客户端时，通常不需要针对用户帐户。从 ConfigMgr 的角度来看，在服务器上安装 ConfigMgr 客户端的目的是管理机器，而不是管理登录到机器的用户。

下面看看新用户会看到什么：
6. 关闭 ConfigMgr 控制台，然后使用“Run as a different user”再次打开它。
7. 提示输入凭据时，使用用户名“Frank”和密码“P@ssw0rd”。
8. 导航至“Assets and Compliance > Device Collections”，会发现用户“Frank”只能看到“All Windows Workstation Clients”集合。
9. 导航至“Software Library”，会发现用户“Frank”只能看到“Application Management”下的项目，与“Software Updates”和“Operating System Deployment”有关的所有内容都不可见。
10. 展开“Application Management > Applications”，用户“Frank”可以看到应用程序“Paint .NET”，但看不到其他应用程序。
11. 关闭 ConfigMgr 控制台，然后以用户“Johan”和密码“P@ssw0rd”重新启动它。
12. 导航至“Assets and Compliance > Device Collections”，用户“Johan”看不到“All Windows Workstation Clients”集合，但可以看到“All Server Clients”集合。
13. 导航至“Software Library”，由于分配了相同的安全角色，用户“Johan”在“Application Management”下看到的选项与用户“Frank”相同。
14. 展开“Application Management > Applications”，用户“Johan”看不到任何应用程序，因为没有应用程序被分配到“MoL – Servers”范围。

ConfigMgr 正在应用基于角色的管理（RBA），即用户只能看到其有权访问的内容。这不仅是一种安全功能，还可以避免管理用户在控制台中看到可访问但实际无权限操作的内容而感到困扰。例如，“ConfigMgr Application Admins - Desktops”组只能处理“All Windows Workstation Clients”集合中的对象，这意味着他们无法与任何非工作站（服务器）客户端进行交互。如果管理员创建了一个受“All Windows Workstation Clients”集合限制的新集合（例如“All Windows 10 Clients”），桌面管理员也可以针对这些系统进行操作。但如果有人意外（或故意）创建了一个查询服务器操作系统并受“All Windows Workstation Clients”集合限制的集合，他们将无法访问，因为服务器操作系统不会出现在“All Windows Workstation Clients”集合中，因此也不会出现在其下的任何其他集合中。这是一种在不影响人们工作的情况下有效限制操作的方法。

以下是一个简单的 mermaid 流程图，展示了用户访问 ConfigMgr 资源的判断过程：

graph TD
    A[我需要部署一个应用程序] --> B{我是管理用户吗?}
    B -- 否 --> C(访问被拒绝)
    B -- 是 --> D{我被分配到正确的集合了吗?}
    D -- 否 --> C
    D -- 是 --> E{我处于正确的角色吗?}
    E -- 否 --> C
    E -- 是 --> F{我被分配到正确的范围了吗?}
    F -- 否 --> C
    F -- 是 --> G(访问被授予)

下面通过表格总结不同角色和范围下用户的访问权限：
| 用户组 | 可访问设备集合 | 可访问软件库项目 | 可访问应用程序 |
| ---- | ---- | ---- | ---- |
| ConfigMgr Application Admins – Desktops | All Windows Workstation Clients | Application Management 下项目 | Paint .NET |
| ConfigMgr Application Admins – Servers | All Server Clients | Application Management 下项目 | 无 |

ConfigMgr常见问题与安全配置全解析

9. 安全配置的重要性总结

ConfigMgr 的安全配置对于保障系统稳定运行和数据安全至关重要。从前面介绍的管理权限、安全角色、安全范围到精细权限的设置，每一个环节都相互关联，共同构建起一个多层次的安全防护体系。

管理权限的正确分配是基础，确保只有授权的用户和组能够访问 ConfigMgr 系统。使用安全组而非单个用户分配管理访问权限，便于审计和管理。安全角色则进一步细化了用户在系统内的操作权限，通过内置角色和自定义角色的结合，可以满足不同的业务需求。安全范围则像一个过滤器，限制了用户能够操作的对象范围，避免不同团队之间的操作干扰。精细权限的设置则是将用户、角色和范围三者结合起来，实现了对用户操作的精准控制。

以下是一个简单的表格，总结安全配置各部分的作用：
| 安全配置部分 | 作用 |
| ---- | ---- |
| 管理权限 | 确定谁可以访问 ConfigMgr 系统 |
| 安全角色 | 定义用户在系统内的操作权限 |
| 安全范围 | 限制用户可操作的对象范围 |
| 精细权限 | 结合用户、角色和范围，精准控制用户操作 |

10. 常见问题的预防与解决策略

在使用 ConfigMgr 过程中，可能会遇到各种问题，如前面提到的环境问题、权限问题和互联网访问问题等。以下是针对这些常见问题的预防和解决策略：

10.1 环境问题

• DNS 问题 ：对于较大的多区域环境，若要启用并配置清理功能，需谨慎选择操作对象。若需要针对每个区域进行精细的清理设置，应避免右键单击 DNS 服务器来为所有区域配置，而是针对每个区域单独操作。在排查 DNS 问题时，可在系统的 HOSTS 文件中创建手动条目，但操作完成后要及时清理，防止影响其他名称解析方法。
• 磁盘空间问题 ：除了托管站点数据库和日志文件的磁盘外，ConfigMgr 不会主动监控可用空间。可通过修改硬件清单类来收集可用空间数据，并创建相关的设备集合和运行报告，以便及时发现磁盘空间不足的问题。

10.2 权限问题

• 管理权限分配 ：使用组策略等机制为 ConfigMgr 主站点服务器及其下属服务器分配完全管理员权限，避免手动添加计算机对象帐户到本地管理员组带来的管理困难。同时，在授予帐户本地管理员访问权限时，避免将其添加到“Domain Admins”组，防止过度授权。
• 权限策略配置 ：在使用组策略或其他机制配置本地管理员成员资格时，要充分考虑 ConfigMgr 权限要求，避免因配置不当导致站点角色异常、内容分发失败等问题。若遇到此类问题，可通过查看日志中的“Access denied”错误消息来缩小问题范围。

10.3 互联网访问问题

• 代理配置 ：若需要配置站点服务器通过代理进行通信，按照特定步骤操作，确保输入正确的代理服务器详细信息和凭据。若遇到代理成为瓶颈的问题，要与网络团队密切合作，利用企业网络代理的实时故障排除功能找出问题所在。
• 日志监控 ：持续关注 wsyncmgr.log 文件，及时发现互联网访问问题。

11. 最佳实践建议

为了更好地使用 ConfigMgr 并保障系统安全，以下是一些最佳实践建议：
1. 定期审计 ：定期审查管理用户、安全角色、安全范围和精细权限的设置，确保权限分配符合业务需求和安全策略。及时清理不再需要的用户和权限，防止权限滥用。
2. 培训与教育 ：对使用 ConfigMgr 的人员进行培训，使其了解系统的安全配置和操作规范。提高用户的安全意识，避免因误操作导致安全问题。
3. 备份与恢复 ：定期备份 ConfigMgr 数据库和相关配置文件，制定完善的恢复策略。在遇到系统故障或数据丢失时，能够快速恢复系统正常运行。
4. 更新与维护 ：及时更新 ConfigMgr 系统和相关组件，安装最新的安全补丁和更新，以修复已知的安全漏洞，提高系统的稳定性和安全性。

12. 未来趋势与展望

随着信息技术的不断发展，ConfigMgr 也将面临新的挑战和机遇。未来，ConfigMgr 可能会在以下几个方面得到进一步发展：
1. 智能化管理 ：引入人工智能和机器学习技术，实现对系统的智能监控和自动化管理。例如，通过分析系统日志和性能数据，自动发现潜在问题并进行预警和修复。
2. 云集成 ：与云服务提供商的深度集成，实现更灵活的资源部署和管理。例如，将部分 ConfigMgr 功能迁移到云端，利用云的弹性和扩展性来满足企业不断变化的需求。
3. 多平台支持 ：支持更多的操作系统和设备类型，满足企业多元化的设备管理需求。例如，对移动设备和物联网设备的管理。

以下是一个 mermaid 流程图，展示了未来 ConfigMgr 发展的趋势：

graph LR
    A[ConfigMgr现状] --> B[智能化管理]
    A --> C[云集成]
    A --> D[多平台支持]
    B --> E[智能监控与自动化管理]
    C --> F[灵活资源部署与管理]
    D --> G[多元化设备管理]

13. 总结

ConfigMgr 是一个强大的系统管理工具，但在使用过程中需要关注各种环境问题和安全配置。通过正确理解和应用管理权限、安全角色、安全范围和精细权限等安全配置要素，可以有效保障系统的稳定运行和数据安全。同时，针对常见问题制定预防和解决策略，遵循最佳实践建议，能够提高 ConfigMgr 的使用效率和安全性。展望未来，ConfigMgr 将不断发展，以适应信息技术的快速变化。希望本文能够帮助读者更好地掌握 ConfigMgr 的使用和安全配置，为企业的信息化建设提供有力支持。

以下是一个列表，总结本文的关键要点：
1. 理解常见环境问题，如 DNS 清理、磁盘空间监控等。
2. 正确分配管理权限，使用安全组进行管理。
3. 利用安全角色实现权限细化，可自定义角色。
4. 通过安全范围限制用户操作对象。
5. 结合用户、角色和范围设置精细权限。
6. 针对常见问题制定预防和解决策略。
7. 遵循最佳实践建议，保障系统安全稳定。
8. 关注 ConfigMgr 未来发展趋势。