Azure 云端环境里的活动目录介绍 | 申博官网
登录
  • 欢迎进入Sunbet!
  • 如果您觉得Sunbet对你有帮助,那么赶紧使用Ctrl+D 收藏Sunbet并分享出去吧
  • 您好,这里是Sunbet!

Azure 云端环境里的活动目录介绍

申博_安全防护 申博 20次浏览 已收录 0个评论

很多人都熟悉活动目录,即 Windows 服务器中可用的本地目录和身份验证系统,但Azure Active Directory到底是什么呢?

Azure 活动目录(Azure AD 或 AAD)是一个多租户云目录和身份验证服务。 

Azure AD 是 Office365(和 Azure)为账户、组和角色利用的目录服务。 它还是一个身份提供者(Identity Provider,IPD) ,并支持联邦(SAML,等等)。 

注意: 考虑到云变化的速度,这篇文章的元素可能在原始发布日期之后很快就过时了。 Azure AD 具有高可用性和全球部署性。

Azure AD 部署在全球超过30个数据中心,利用当前的 Azure 可用性区域。 随着更多 Azure 地区的部署,这个数字正在迅速增长。 

为了持久性,任何写入 Azure AD 的数据都会根据租户配置复制到至少4个和最多13个数据中心。 在每个数据中心内,数据再次复制至少9次,以提高持久性,并扩展容量以满足身份验证负载。 说明一下——这意味着在任何时间点,在我们最小的区域内,我们的服务中至少有36个你的目录数据副本可用。 为了持久性,直到一个地区外的数据中心成功提交之后,才能完成对 Azure AD 的写操作。 

这种方法既保证了数据的持久性,又提供了大量的冗余性——多个网络路径和数据中心可以服务于任意给定的授权请求,系统可以自动、智能地重试并绕过数据中心内部和数据中心之间的故障路由。 

为了验证这一点,我们定期进行故障注入,并验证系统对构建在 Azure AD 之上的系统组件的失败恢复能力。 这扩展到定期删除整个数据中心,以确认系统可以容忍数据中心的丢失,而对客户的影响为零。 

Azure AD 已经是一个庞大的系统,运行在超过300,000个 CPU 核心上,并且能够依靠 Azure 云巨大的可扩展性来快速动态地扩展以满足任何需求。 这可能包括流量的自然增长,比如某个地区上午9点的认证峰值,也可能包括我们 Azure AD B2C 服务的新流量的巨大激增,它驱动了一些世界上最大的活动,并经常看到数以百万计的新用户的冲击。 

为了支持门安全部署的健康检查,并让我们的工程团队洞察系统的健康状况,Azure AD 发布了大量内部遥测数据和信号,用于监测我们系统的健康状况。 在我们的范围内,每周有超过11pb 的信号提供给我们的自动健康监测系统。

https://azure.microsoft.com/en-us/blog/advancing-azure-active-directory-availability/

Azure 活动目录不是云 AD

Azure 活动目录不是云托管的活动目录。 没有标准的 AD 身份验证方法,如 NTLM 或 Kerberos; 没有 LDAP; 也没有组策略(GPO) ,因此 Azure AD 不适用于传统的本地应用程序。

在微软 Azure (Azure 活动目录域服务)、 Amazon AWS (Amazon 托管微软活动目录)和 Google Cloud (微软活动目录 (AD)的托管服务)中,有一些云托管的活动目录环境可用于管理云工作负载。 这些都是托管的微软活动目录环境,它们有2个域控制器(或更多) ,租户管理员不接收托管的 AD 环境的域管理权限; 只提供委托访问,这通常包括在特定 OU 和特定 GPO 中创建和管理资源的能力。 

注意: 我不会在这篇文章里对这些服务做详细的比较,但是如果有兴趣的话,我可能会在未来写篇这方面的文章(我在2017年对微软 Azure 和亚马逊 AWS 托管的活动目录服务做了一些研究比较)。

主要的管理工具介绍

AD 管理员熟悉的大多数工具是活动目录用户和计算机,又称为 ADUC (MMC 工具)。

Azure 活动目录管理员将主要使用 https://portal.azure.com 的网络控制台来管理环境。

管理本地活动目录的管理员和现在的 Azure AD 和 Office 365的管理员将使用本地 MMC 工具和 web 管理门户(以及与它们相关的各种 URL)。 有一些 PowerShell cmdlet 可用于管理 Azure AD (类似于本地管理) ,不过云功能的发布速度通常比 PowerShell 工具的发布速度快,这意味着即使使用 PowerShell,仍然应该使用云管理门户。

与 Azure 活动目录的连接

由于 Azure AD 没有 LDAP,因此与 AAD 的连接涉及通过 Graph API (或 PowerShell 模块)进行连接。 我喜欢 PowerShell,所以我使用 PowerShell 模块(或 Portal 网站)进行管理和报告。 有两个主要的 PowerShell 模块可以与 Azure AD 进行连接: MSOnline  和 AzureAD。 这些功能可以通过 PowerShell 安装功能进行安装:

Install-Module -Name MSOnline -Force 
Install-Module -Name AzureAD -Force

AzureAD 模块可能最终取代 MSOnline PowerShell 模块,但是在 MSOnline 中有一些功能还没有移植到 Azure AD 模块中。

Azure AD PowerShell 模块和 cmdlet 比较(模块和 cmdlet 的数据截至2020年1月)

类别

MSOnline

AzureAD

管理单元

Get-MsolAdministrativeUnit

管理单元

Get-MsolAdministrativeUnitMember

应用程序

Get-AzureADApplication

应用程序

Get-AzureADApplicationExtensionProperty

应用程序

Get-AzureADApplicationKeyCredential

应用程序

Get-AzureADApplicationLogo

应用程序

Get-AzureADApplicationOwner

应用程序

Get-AzureADApplicationPasswordCredential

应用程序

Get-AzureADApplicationProxyApplication

应用程序

Get-AzureADApplicationProxyApplicationConnectorGroup

应用程序

Get-AzureADApplicationProxyConnector

应用程序

Get-AzureADApplicationProxyConnectorGroup

应用程序

Get-AzureADApplicationProxyConnectorGroupMember

应用程序

Get-AzureADApplicationProxyConnectorMemberOf

应用程序

Get-AzureADApplicationServiceEndpoint

应用程序

Get-AzureADMSApplication

应用程序

Get-AzureADMSApplicationExtensionProperty

应用程序

Get-AzureADMSApplicationOwner

应用程序

Get-AzureADDeletedApplication

应用程序

Get-AzureADServiceAppRoleAssignedTo

应用程序

Get-AzureADServiceAppRoleAssignment

应用程序

Get-AzureADGroupAppRoleAssignment

认证

Get-AzureADMSIdentityProvider

认证

Get-AzureADMSLifecyclePolicyGroup

认证

Get-AzureADOAuth2PermissionGrant

联络

Get-MsolContact

Get-AzureADContact

联络

Get-AzureADContactDirectReport

联络

Get-AzureADContactManager

联络

Get-AzureADContactMembership

联络

Get-AzureADContactThumbnailPhoto

合约

Get-AzureADContract

设备

Get-MsolDevice

Get-AzureADDevice

设备

Get-MsolDeviceRegistrationServicePolicy

设备

Get-AzureADDeviceConfiguration

设备

Get-AzureADDeviceRegisteredOwner

设备

Get-AzureADDeviceRegisteredUser

目录同步

Get-MsolDirSyncConfiguration

目录同步

Get-MsolDirSyncFeatures

目录同步

Get-MsolDirSyncProvisioningError

目录同步

Get-MsolHasObjectsWithDirSyncProvisioningErrors

Get-MsolDomain

Get-AzureADDomain

Get-MsolDomainVerificationDns

Get-AzureADDomainVerificationDnsRecord

Get-MsolDomainFederationSettings

Get-AzureADDomainNameReference

Get-AzureADDomainServiceConfigurationRecord

联邦

Get-MsolFederationProperty

Get-MsolGroup

Get-AzureADGroup

Get-MsolGroup

Get-AzureADMSGroup

Get-MsolGroupMember

Get-AzureADGroupMember

Get-AzureADGroupOwner

Get-AzureADMSGroupLifecyclePolicy

Get-AzureADMSDeletedGroup

许可证订阅

Get-MsolSubscription

Get-AzureADSubscribedSku

对象

Winnti恶意组织:利用ShadowPad和Winnti恶意软件针对香港高校发动攻击

一、概述 在2019年11月,我们发现了Winnti恶意组织针对两所香港高校发起的新型恶意活动。在恶意活动中,我们发现了ShadowPad后门的新变种,这是该恶意组织主要使用的后门。新变种中部署了新的启动器,并且嵌入了许多模块。在ShadowPad出现的前几周,我们还在这些高校中发现了Winnti恶意软件。 Winnti恶意组织自2012年开始活跃,主要针对视频游戏和软件行业展开供应链攻击,最终导致受害者发布包含木马的软件(例如:CCleaner、ASUS LiveUpdate和多个视频游戏),并以此来攻击更多的受害者。并且,该恶意组织此前也针对医疗保健和教育领域的各种目标发动过攻击。 ESET研究人员最近在一篇文章中发布了一份白皮书,其中更新了我们对于Winnti恶意组织武器库的理解,该文章记录了针对亚洲视频游戏行

Get-AzureADMSDeletedDirectoryObject

对象

Get-AzureADObjectByObjectId

合伙人

Get-MsolPartnerContract

合伙人

Get-MsolPartnerInformation

密码

Get-MsolPasswordPolicy

角色组

Get-MsolRole

Get-AzureADDirectoryRole

角色组

Get-MsolRoleMember

Get-AzureADDirectoryRoleMember

角色组

Get-MsolScopedRoleMember

角色组

Get-AzureADDirectoryRoleTemplate

服务负责人

Get-MsolServicePrincipal

Get-AzureADServicePrincipal

服务负责人

Get-MsolServicePrincipalCredential

Get-AzureADServicePrincipalKeyCredential

服务负责人

Get-AzureADServicePrincipalCreatedObject

服务负责人

Get-AzureADServicePrincipalMembership

服务负责人

Get-AzureADServicePrincipalOAuth2PermissionGrant

服务负责人

Get-AzureADServicePrincipalOwnedObject

服务负责人

Get-AzureADServicePrincipalOwner

服务负责人

Get-AzureADServicePrincipalPasswordCredential

会话

Get-AzureADCurrentSessionInfo

租户

Get-MsolCompanyAllowedDataLocation

租户

Get-MsolCompanyInformation

租户

Get-AzureADTenantDetail

租户

Get-AzureADTrustedCertificateAuthority

租户

Get-CrossCloudVerificationCode

用户

Get-MsolUser

Get-AzureADUser

用户

Get-MsolUserByStrongAuthentication

Get-AzureADUserAppRoleAssignment

用户

Get-MsolUserRole

Get-AzureADUserCreatedObject

用户

Get-AzureADUserDirectReport

用户

Get-AzureADUserExtension

用户

Get-AzureADExtensionProperty

用户

Get-AzureADUserLicenseDetail

用户

Get-AzureADUserManager

用户

Get-AzureADUserMembership

用户

Get-AzureADUserOAuth2PermissionGrant

用户

Get-AzureADUserOwnedDevice

用户

Get-AzureADUserOwnedObject

用户

Get-AzureADUserRegisteredDevice

用户

Get-AzureADUserThumbnailPhoto

用户

Get-MsolAccountSku

在上面的表格中,我对两个 Azure AD PowerShell 模块中的 cmdlet 进行了分类,并尝试将提供相同或类似功能的 cmdlet 连接起来。 我计划将来在这些 cmdlet 上发布更多内容。

不幸的是,对这些模块进行单点登录(SSO)并不是一件简单的事情。 凭证可以在 PowerShell 中捕获,并在模块之间重用,但前提是不执行 MFA (这会降低帐户安全性)。 

微软云环境最初只支持用户名和密码身份验证。 这种“传统身份验证”不包括双重身份验证身份验证(“ MFA”) ,因此出于安全原因,传统身份验证应该禁用(通过安全默认值、条件访问等)。 Azure 活动目录身份验证库提供了“现代身份验证” ,它完全支持 MFA (无密码!) .

微软的 ADAL:

Azure 活动目录认证库 (ADAL) v1.0使应用程序开发人员能够对用户进行云或者本地活动目录(AD)的身份验证,并获得确保 API 调用安全的令牌。 ADAL 通过以下特性使开发人员更容易进行身份验证:

• 存储访问令牌和刷新令牌的可配置令牌缓存

• 当访问令牌过期且刷新令牌可用时,自动令牌刷新

• 支持异步方法调用

有一个 ADAL PowerShell 模块(Install-Module -Name adal.ps) ,它在模块之间提供某种程度的 SSO (可以支持)。 安装了 ADAL 模块后,运行以下命令在会话中加载 ADAL 令牌:

$clientId = "1b730954-1685-4b74-9bfd-dac224a7b894" , Azure AD PowerShell
     $redirectUri = [Uri]::new('urn:ietf:wg:oauth:2.0:oob')
     $authority = "https://login.windows.net/common/oauth2/authorize"
     $resourceUrl = "https://graph.windows.net"
 $ADALresponse = get-adaltoken -Resource $resourceUrl -ClientId $clientId -RedirectUri $redirectUri -Authority $authority -PromptBehavior:Always

一旦 $ADALResponse 变量被捕获,你就可以在 Azure AD 模块中利用这个令牌:

$ConnectAzureADInfo = connect-azuread -AadAccessToken $ADALresponse.AccessToken -AccountId $ADALresponse.UserInfo.DisplayableId
$ConnectMsolInfo = connect-msolservice -AdGraphAccessToken $ADALresponse.AccessToken
, Looks like the Microsoft Teams PowerShell module supports ADAL as well, though I added a new variable that includes the signed-in user UPN.
Connect-MicrosoftTeams -AadAccessToken $ADALresponse -AccountId $AssessmentAccountUPN

Azure 活动目录的访问权限

有了活动目录,几乎所有东西都可以作为普通用户查看。Azure AD 用户可以查看有关用户和组的信息,但有一些限制访问。

在 Azure AD 中,为了识别特殊的访问权限,特权组被称为“角色”(即组)。 在 Office365 中有几个这样的管理角色,它们为所有 Office365或其特定部分提供管理级别的权限。 (分配角色)

许多组织在全局管理员(又名租户管理员)角色中都有一个报告帐户,这个角色实际上是将企业管理、域管理和模式管理集成到一个组中。 全局管理员拥有对 Azure AD 和所有 Office 365服务的完全控制权。 这就是为什么许多组织有超过5个全局管理员(微软的最大推荐数量)。 只有云帐户应该添加到角色中,这样它们才能利用 Azure MFA (无密码)以及 PIM 控制的角色成员关系。 

还强烈建议创建一个“ break-glass”管理员帐户(或两个) ,以确保对租户的持续特权访问。 微软发布了一份关于如何保护特权访问的文档。 

强烈建议使用特权身份管理(Privileged Identity Management,PIM)来控制角色成员资格,并要求每个使用 PIM 的帐户都拥有 Azure AD Premium 2(P2)许可证。 PIM 提供对具有所需权限的管理员角色的实时访问。 当管理员需要管理权限时,他们可以通过 PIM 请求并获得访问权限(可以发送给批准或自动批准)。 微软建议角色中的所有帐户都由 PIM 管理(并且拥有 AAD P2许可证)。 

还有一个用于 PIM 的 Powershell 模块可以安装: 

Install-Module -Name Microsoft.Azure.ActiveDirectory.PIM.PSModule

在2019年秋天,微软增加了一个名为“全局读操作”的新角色,该角色对全局管理员可以看到的所有 Azure AD / Office 365服务拥有只读 / 只查看权限(有些例外,因为微软仍在对所有 Office 365服务推出全局读操作功能)。 Global Reader 的成员资格应提供给安全团队或审计人员,他们需要对微软云(Azure AD & Office 365)环境进行视图访问。

攻击 Azure 活动目录

Office 365 服务可以从互联网上访问(默认情况下,使用条件访问来限制访问) ,这使得它们对攻击者具有吸引力。 攻击者利用多种攻击方法对 Azure AD & Office 365进行攻击。

帐户枚举

使用旧式的活动目录,任何活动目录用户都可以枚举所有的用户帐户和管理组成员,并且可以通过网络访问域控制器目录。 Azure Active Directory 用户可以枚举访问 Office365 服务(默认)的所有用户帐户和管理组成员。 用户枚举通常可能没有使用 O365creeper 的帐户,该帐户试图使用电子邮件地址列表认证到 O365。 根据响应代码,该工具确定电子邮件地址是否为有效用户帐户。 

Azure AD 枚举工具 

O365 Creeper-Office 365身份验证页面(Python)[ 账户发现 ]

OWA (Golang)

ActiveSync  (Python)

MSOnline/AzureAD PowerShell Module (PowerShell)

密码喷射

这是一种常见的方法,攻击者以及许多渗透测试人员和红队员被称为“密码喷射”。 密码喷射很有趣,因为它会自动猜测密码。 这种针对所有用户的自动密码猜测通常可以避免帐户锁定,因为使用特定密码的登录尝试是针对每个用户执行的,而不是针对一个特定的用户,而这正是帐户锁定的目的。 攻击者首先会尝试一系列以最有可能作为密码开头的密码(“ Fall2017” ,“ Winter2018”等)。 

当密码喷射开始时,我们从列表中的第一个密码开始。 第一个密码用于尝试作为每个用户(或子集)进行身份验证。 这个密码是针对每个用户的,一旦所有用户都测试过这个密码,我们就会继续下一个密码。

密码喷射执行起来相对简单,而且非常有效。 我们曾与许多组织合作,因为他们的云环境就是由于账户受到密码喷射攻击而被入侵。 联邦的许多客户没有意识到他们的工作应该是发现这种攻击,而不是云的问题。 在云计算之外,密码喷射存在真正的风险。 如果云帐户和本地账户使用了相同的密码,而且没有配置 MFA,那么攻击者就有可能通过密码喷射攻击云端帐户,然后获得企业网络的访问权限。 这不是一个理论或假设的场景,并强调了MFA的重要性。

Office 365 密码喷射工具

Ruler (Exchange) [Golang]
SprayingToolkit (Lync/Skype for Business/OWA) [Python]
LyncSniper (Lync/Skype for Business) [PowerShell]
MailSniper (OWA/EWS) [PowerShell]

Office 365 密码喷射攻击缓解措施
通过启用“安全默认”或配置自定义条件访问策略禁用传统身份验证。强烈建议所有用户都使用MFA。

Office365 密码喷射攻击检测

假设密码喷射攻击的目标 Office365 服务和联邦没有配置(ADFS,Okta 等) ,那么可以通过引用 Azure AD 登录日志来执行检测。

通过将同一用户的多个事件与登录错误代码“50126”关联起来进行检测,客户端应用程序是“Other clients; Older Office clients”(这意味着执行了传统身份验证)。

帐户令牌窃取和重用

由于云认证通常会导致令牌存储在经过认证的应用程序或 web 浏览器中,这是认证的证据,可以进行重用。 Web 浏览器通常将这个验证标记存储为 cookie。 如果这些数据被窃取,攻击者可以利用这些数据进行欺骗访问,并配置持久性以便继续访问。

Azure AD 回顾

微软的 Azure AD GitHub 包括用于检查 Azure AD 配置的 PowerShell 代码 (https://github.com/AzureAD/AzureADAssessment)

Trimarc 还提供了一项名为微软云安全评估(MCSA)的新服务,该服务类似于本地活动目录安全评估,但专注于 Azure AD & Office 365。

其他 Office 365服务 PowerShell 模块 exchange 在线模块安装-Exchange 在线模块

Install-Module -Name ExchangeOnlineManagement

微软 SharePoint

Install-Module -Name Microsoft.Online.SharePoint.PowerShell

微软 Teams

Install-Module -Name MicrosoftTeams

微软企业在线 Skype 
微软 InTune 

Install-Module -Name Microsoft.Graph.Intune -Force

(需要管理员提供 Admin Consent: Connect-MSGraph -AdminConsent)

参考文献:

• 什么是 Azure 活动目录

• Azure 活动目录的新功能是什么?

• Azure 活动目录特性部署指南

• 条件访问

• 开始使用特权标识管理器(PIM)

• Azure 双重身份验证(MFA) 

• Azure AD 身份保护

• Azure AD 自助服务密码重置(SSPR)

• Azure AD 在 Azure AD 中保护混合云部署的特权访问

• Black Hat USA 2019 ——“攻击和保卫微软云(Office365 & Azure AD)” 
幻灯片(PDF) 
现场视频 (YouTube) 

• Azure AD 密码保护(针对本地活动目录)

本文翻译自:https://adsecurity.org/?p=4211


Sunbet|网络安全巴士站声明:该文看法仅代表作者自己,与本平台无关。版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
转载请注明Azure 云端环境里的活动目录介绍
喜欢 (0)
[]
分享 (0)
发表我的评论
取消评论
表情 贴图 加粗 删除线 居中 斜体 签到

Hi,您需要填写昵称和邮箱!

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址