当前位置:网站首页 > 更多 > 玩电脑 > 正文

[玩转系统] Microsoft 365 管理的十大 PowerShell 技巧:第二部分

作者:精品下载站 日期:2024-12-14 04:08:20 浏览:14 分类:玩电脑

Microsoft 365 管理的十大 PowerShell 技巧:第二部分


在本系列的第一部分中,我们将介绍一些通用的 PowerShell 技巧。在本文中,我们重点介绍如何使用 PowerShell 来管理 Microsoft 365。此外,我们还考虑如何使用云服务来管理 PowerShell 代码、测试、安全控制等。 本文的目的是帮助那些编写 PowerShell 脚本的人了解编码之外的全局,并管理其代码的未来使用。

密码、秘密和证书

Microsoft 正在稳步更改其身份验证机制,从不安全的基本身份验证 (Exchange Online) 切换到现代身份验证 (OAuth 2.0)。 管理员需要为脚本切换到更安全的 PowerShell 连接,例如使用证书或使用秘密 PowerShell 模块进行本地凭据存储,或使用存储在系统管理的 Azure Key Vault 中的 Azure 自动化凭据。确保使用基于证书的身份验证或 Azure 自动化凭据,因为它们比本地存储的密码或脚本文件中存储的明文密码更安全。

使用 Azure 自动化商店帐户需要安装 Az.Automation 模块,连接到 Azure 和四行代码:

install-module az.automation

Connect-AzAccount

$AutomationUserName = '[email protected]'

$Password = ConvertTo-SecureString (Read-host 'Enter password to encrypt') -asplaintext -Force

$Credentials = New-Object –TypeName System.Management.Automation.PSCredential –ArgumentList $AutomationUserName, $Password

New-AzureAutomationCredential -AutomationAccountName "AutomationAccount" -Name "AutomationCredentials" -Value $Credentials

对于基于证书的身份验证,大多数(但不是全部)(SharePoint Online)、Microsoft 365 PowerShell 模块都可以选择使用证书进行身份验证、Exchange Online Management v3、安全与合规中心、Microsoft Teams、SharePoint 的 PNP 模块和 Microsoft Graph PowerShell SDK。 基于证书的身份验证并不难设置,但它确实需要注册的 Azure 应用程序、适当的 API 权限以及脚本引用并附加到 Azure 应用程序的本地证书。 一旦证书到位,就可以连接到有效的工作负载。

提示:如果脚本在本地服务器上运行,请通过锁定谁具有文件权限来访问该文件来确保其安全性,并且无论身份验证方法如何,都应该这样做。

秘密模块资源链接。

适用于 Exchange、Microsoft Graph 和 SharePoint PNP 的基于证书的身份验证资源。

Azure 自动化凭据管理资源链接。

Azure自动化

从这里开始:停止使用本地跳线盒或管理工作站。 将您的工作负载转移到云端,因为 Microsoft 的 Azure 自动化提供了可扩展、经过验证的坚实基础,并且比工作站更安全。 Azure 自动化在拥有合适的资源的情况下,可以有非常小的学习曲线,并且有可能成为低成本的解决方案,具体取决于使用情况。通过访问许多默认的 PowerShell 模块、库模块或导入到 Azure 中的您自己的模块,我们可以自动执行许多管理任务。

Azure Runbook:Azure 中的一项服务,允许管理员使用 PowerShell 等语言创建自动化任务。

为了成功使用 Azure 自动化,请确保在将任务移至 Azure 自动化之前使用常规 PowerShell 测试自动化脚本,因为 Visual Studio Code 等 PowerShell 工具可提供更多调试和反馈。 脚本准备好进行自动化测试后,请确保通过单击 Runbook 的“开始”来运行脚本,并检查加载的面板中的错误、警告和日志(每个窗格可能包含故障排除信息)以查看脚本的执行情况。 然后,一旦脚本准备就绪并开始工作,创建并链接适合任务的计划并监视自动化 Runbook 中存在的日志。

通过自动化,我们可以管理 Graph、Exchange Online、SharePoint 和 Teams 中的数据,以执行报告、通知以及对每个工作负载中的数据进行更改等任务。 这就是测试派上用场的地方,因为对这些工作负载的访问虽然由 Azure RBAC 控制,但如果实施不正确,可能会造成严重破坏。

Azure 自动化还支持基于证书的身份验证。

跟进

  • Exchange Online 的 Azure 自动化
  • 使用 Azure 自动化监控统一审核日志
  • 还有更多……

GitHub - 您的脚本存储库

代码变更控制是维护生产级脚本的一个重要方面,利用 GitHub 等基于 Web 的工具可以使协作和变更测试变得更容易。 使用 GitHub,您可以创建可直接与内部 IT 项目、小组或在家工作项目相对应的项目。 我们可以创建登陆页面、帮助页面等来协助协作过程。

为什么使用 GitHub?

  • 变更控制:决定通过 Pull/Push 请求发布哪些功能和代码变更。
  • 分支:允许拆分代码以进行稳定性检查或新版本控制测试。
  • 访问控制:利用访问控制,根据项目的需要提供/阻止对项目和代码的访问。
  • 报告:为每个项目创建有关所做更改、贡献者等的报告。

使用 GitHub 的优点

  • 大多数访问都是免费的
  • 存储库可以是私有的、公共的和共享的(协作)
  • 桌面应用程序和 Web 访问带来良好的用户体验
  • Visual Code Studio 编辑器存在集成

良好的公共脚本存储库示例:

https://github.com/12Knocksinna/Office365itpros - 可供参考和使用的一组很棒的 PowerShell 代码。

https://github.com/microsoft - Microsoft 的官方存储库和他们自己的 PowerShell 代码示例的来源。

https://github.com/O365scripts - 用于管理 Office 365 的 PowerShell 脚本的第三方资源。

注意事项/建议

GitHub 的一个关键方面是确定组织或个人需要什么计划。 如果只有一个人从事该项目并且不需要特殊协作,那么 GitHub 的免费版本是正确的解决方案。 但是,如果组织的团队必须在一个或多个项目上进行协作,则应选择团队版或企业版。 关键的区别在于 Enterprise 具有先进的功能,例如用于控制对 GitHub 组织的访问的跨域身份管理系统 (SCIM)、用于日志记录的 API、更多的存储空间、更多的执行计算时间,以及高级的合规性功能,例如 SOC1、 SOC2 和 FedRAMP (ATO)。

Microsoft 365 租户质量检查

对于管理 Microsoft 365 租户的管理员来说,并行获取开发租户是一种很好的做法,并且 Microsoft 提供了一个免费注册链接,如本文所述。 这意味着什么? 这意味着创建具有相同许可、功能等的重复租户,以模仿生产中使用的内容。创建测试租户时需要考虑的一些因素包括:

  • 预算和采购:管理多少预算以及谁的责任?
  • 确定要启用的功能:是否所有生产功能都需要在 QA 中进行测试?
  • 源数据:此环境中将填充什么? 它是一对一的生产副本、缩小版还是仅用于测试的匿名数据?
  • 变更管理:发生变更时如何维持秩序? 更改一旦完成如何恢复?
  • 域名:哪些个性化域名将用于测试?

那么,这种类型的租户及其配置与 PowerShell 有什么关系呢? 简而言之,这种类型的租户允许管理员尝试针对租户中的工作负载(Exchange、SharePoint、Teams、Graph 等)以及自动化脚本(需要 Azure 订阅)、凭据存储和沙箱中的其他功能进行 PowerShell 管理环境不影响其生产用户。 根据正在执行的工作,这可能至关重要。 例如,如果脚本自动执行许可、组分配或入职/离职流程权限等任务,则运行 PowerShell 会更加宽容,并减少麻烦。因此,即使从 PowerShell 方面来看,拥有 QA 租户也是一个好主意。 使用此租户,管理员可以磨练他们的 PowerShell 技能、调整脚本并提供不会导致组织生产中断的解决方案。

控制 PowerShell 对租户的访问

安全性和受控访问是在任何环境中使用脚本和自动化工具的重要方面,对于 Microsoft 365 也是如此。Microsoft 通过 Azure AD 角色提供内置保护和安全控制,这限制了用户可以根据角色和权限执行的操作他们被分配到的角色组。 简而言之,应允许具有适当访问权限的管理员使用 PowerShell,并阻止非管理员用户使用 PowerShell:

Exchange Online:默认情况下启用 PowerShell 访问,但仅限于其自己的上下文。 要禁用此访问,请以此为例:

Set-User -Identity [email protected] -RemotePowerShellEnabled $false

不需要对 SharePoint Online PowerShell 模块进行配置,因为默认情况下会阻止非管理员,如下图 1 所示。

[玩转系统] Microsoft 365 管理的十大 PowerShell 技巧:第二部分

团队:无法阻止 - 用户可以访问管理员或 Microsoft(默认)授予其权限的内容。

Microsoft Graph:在条件访问策略中,我们可以选择 Microsoft Graph PowerShell 应用并将访问控制设置为阻止非管理员用户(图 2)。 此策略将阻止用户访问 PowerShell,但不会阻止对 Graph API 的调用。 为此目的创建的任何条件策略还应排除破坏玻璃帐户,以防止锁定被阻止的资源。

[玩转系统] Microsoft 365 管理的十大 PowerShell 技巧:第二部分

AzureAD/MS Online:计划于 2023 年 6 月弃用。

安全与合规中心:通过 RBAC 限制。 普通用户可以访问隔离消息 PowerShell cmdlet,但没有其他权限。

值得注意的是,由于 Microsoft 的角色和访问权限安全模型,普通用户的 PowerShell 访问权限受到限制。

迁移到云端

当使用 PowerShell 管理基于云的资源(例如 Microsoft 365)时,管理员应该利用这些基于云的高级工具,因为它们提供本地系统所不具备的可扩展性、稳定性和安全性。 如果您无法使用本地资源来管理云基础设施,那么现在正是利用现有工具和功能来改变这种状况的好时机。使用 GitHub、基于证书的身份验证和自动化,您可以提高管理员 PowerShell 的安全性和可用性。

您需要 登录账户 后才能发表评论

取消回复欢迎 发表评论:

关灯