避免使用适用于 Microsoft 365 PowerShell 的 Windows 任务计划程序

存在运行 Microsoft 365 PowerShell 脚本的更好方法

当我阅读建议 Microsoft 365 租户管理员使用 Windows 任务计划程序运行 PowerShell 脚本的文章时，我感到很困惑。我理解人们使用任务计划程序的原因。它很简单，内置于 Windows 中，允许脚本在无人值守的情况下运行（在处理长时间运行的脚本时始终是一个优势），并完成工作。另一方面，任务计划程序是一个老式的实用程序，很难处理现代 PowerShell 实现。 IT 专业人员可以使用更好的方法。让我解释一下原因。

运行 Microsoft Graph PowerShell SDK 脚本

为了说明这一点，我创建了一个简单的 PowerShell 脚本，该脚本使用 Microsoft Graph PowerShell SDK 查找去年创建的用户帐户并将详细信息导出到 CSV 文件。代码如下：

Connect-MgGraph
[array]$Users = Get-MgUser -Filter "usertype eq 'Member' and CreatedDateTime ge $([datetime]::UtcNow.AddYears(-1).ToString("s"))Z" -All -Property Id, DisplayName, UserPrincipalName, CreatedDateTime
$Users = $Users | Select-Object Id, UserPrincipalName, DisplayName, CreatedDateTime
$Users | Export-CSv -NoTypeInformation c:\temp\UsersLastYear.CSV

确保脚本在交互式会话中成功运行后，我创建了一个任务。使用登录帐户运行任务时，一切都按预期运行。当用户未登录时尝试运行脚本时会出现问题，因为任务计划程序不会接受来自 Entra ID 帐户的凭据（图 1）。

你可以说这不是一个大问题。在大多数情况下，人们保持登录到他们的工作站，并且任务可以成功运行。

接下来是连接到 PowerShell 端点所需的凭据，脚本运行顺利，因为任务计划程序启动了 PowerShell 并调用了 Connect-MgGraph cmdlet。 Microsoft Graph PowerShell SDK 自动使用缓存的凭据并获取 SDK 应用程序的服务主体持有的一组同意的 Graph 权限。实际上，该任务的运行就像工作站所有者启动 PowerShell 并运行脚本一样。

这可能不是您想要的。一方面，可用于运行 SDK cmdlet 的有效权限集取决于登录帐户。如果登录帐户拥有某些 Entra ID 管理角色，则可用的权限比其他人登录时更广泛。这是因为 SDK 应用程序同意的权限是委派的，这意味着当 SDK cmdlet 运行时，他们可以访问该用户可用的数据仅此而已。

使用 Entra ID 注册应用程序

更好、更安全的方法是使用 Entra ID 注册的应用程序，并使用证书将 SDK 连接到应用程序。这允许更精确地控制脚本可用的权限集。这也意味着脚本使用应用程序权限而不是委派权限。最后，它消除了对特定登录帐户的依赖。由特定帐户引起的问题的典型症状是，有人报告说，当他们运行一个脚本时，没有可用的数据，而当其他人（具有管理角色的帐户）运行该代码时，该脚本可以正常工作。

要更改为基于证书的身份验证，请按照本文中的说明创建证书，将其上传到应用程序，然后使用如下命令进行连接：

Connect-MgGraph -TenantId "a562313f-14fc-43a2-9a7a-d2e27f4f3478" -AppId "45b178af-aaa3-4728-956f-35425fe5b6e6" -CertificateThumbprint "A6918A18EBBED10AF6B0D873A688F743020C742F"

在这种情况下，唯一需要的图形权限是Directory.Read.All。这是分配给应用程序的相当安全的权限，并且比使用 SDK 服务主体累积的完整权限集运行代码要好得多。

更好的是，转储任务计划程序

如果您转向使用 Entra ID 注册的应用程序来运行计划任务，自然的进展是完全转储 Windows 任务计划程序并将其替换为 Azure 自动化。缺点是需要 Azure 订阅来支付运行脚本 (runbook) 产生的（通常很小）账单。优点是：

• 能够使用安全的托管标识连接到 Microsoft 365 终结点，例如 SDK、Exchange Online 和 Teams。基于证书的身份验证可用于其他端点。
• 消除脚本在特定工作站上运行的依赖性。
• Azure 自动化支持应用程序的 RBAC 来限制对 Exchange Online 邮箱的访问。
• 用于运行手册的强大调度引擎。
• 与 Windows 任务计划程序相比，微软在 Azure 自动化上投入了更多的开发精力（自 Windows 2003 以来，Windows 任务计划程序似乎并没有受到太多的喜爱）。

这是一个完整的运行手册的好例子，用于检查统一审核日志中是否有高优先级事件，这些事件可能表明攻击者何时试图危害租户。

调整 Azure 自动化脚本

获取脚本并使其在 Azure 自动化上运行的正常方法是：

• 选择一个自动化帐户（或在 Azure 门户中创建一个帐户）。
• 为 PowerShell 脚本创建 Runbook。
• 确保 Azure 自动化帐户的服务主体同意使用所有必需的权限。
• 调整 Azure 自动化的代码。
• 测试代码以确保其正常运行。
• 将 Runbook 链接到 Azure 自动化计划。

通常，代码调整集中在两个方面：身份验证（使用托管身份是最佳方法）和输出。例如，示例脚本生成一个 CSV 文件并将其存储在本地驱动器上。由于 Azure 自动化在无头服务器上运行脚本，因此必须使用不同的方法，例如在 SharePoint Online 中创建输出文件或将其作为电子邮件附件发送。

将脚本移动到 Azure 自动化需要一些时间和坚持。调试更加困难，有时甚至令人困惑。但最终这是值得的，这才是重要的。转储任务计划程序并迁移到更现代的平台。

Microsoft 平台迁移规划和整合

简化迁移规划，克服迁移挑战，更快地完成项目，同时最大限度地降低成本、风险和对用户的干扰。