>域环境中的管理员账户保护:管理帐户架构扩展-网络安全-黑吧安全网 | xxx>域环境中的管理员账户保护:管理帐户架构扩展-网络安全-黑吧安全网 – xxx
菜单

>域环境中的管理员账户保护:管理帐户架构扩展-网络安全-黑吧安全网

三月 12, 2020 - 黑吧安全网

域环境中的管理员账户保护:管理帐户架构扩展

来源:本站整理 作者:佚名 时间:2020-03-12 TAG: 我要投稿

活动目录的最佳管理模型规定了某种程度的帐户隔离——至少对于任何拥有敏感成员身份的用户组,如域管理员组——在某些情况下,甚至可能需要每个管理员拥有多个管理员帐户,如微软的分层管理模型。 但是,为了生命周期管理的目的,例如… … ,我们如何跟踪这些帐户的关系呢? 今天,让我们来看一下活动目录模式的扩展,它可能会有所帮助!
活动目录帐户分类入门
活动目录中的内置管理模型存在非常高的风险,它允许将域管理员和其他敏感帐户暴露给当今大多数企业网络中的凭据窃取行为——比如允许登录到工作站和其他客户端成员计算机,而这些计算机在默认情况下可能已经被入侵了。这就导致了外行人在拥有高度特权的账户和不受信任的资产之间使用各种不适当的接触点。
因此,为了保护你的AD环境,你可以(也应该)采取的最基本的步骤之一就是建立某种形式的帐户隔离。
>域环境中的管理员账户保护:管理帐户架构扩展-网络安全-黑吧安全网
可以简单地向管理员提供一个可以分配管理特权的额外帐户。 这个管理员帐户,反过来,不应该用于日常任务,如阅读电子邮件或浏览互联网。 这种模式在规模较小的操作中非常普遍(有时非常适合) ,在这些操作中,帮助台 / 系统管理员的责任由相同的员工共同承担。
锁定模式
另一方面,我们发现了微软的活动目录管理层模型。
>域环境中的管理员账户保护:管理帐户架构扩展-网络安全-黑吧安全网
在它最极端的形式中,这个三层模型是通过专用的、经过适当加固的管理林(俗称“ Red Forest”或 ESEA — Enhanced Security Administrative Environment)实施的,但它也可以直接在单个林中实现,以便不仅在服务器和工作站之间提供适当的隔离,而且将核心身份管理与应用程序基础设施隔离开来。
我强烈建议任何参与保护、设计或管理活动目录的人熟悉分层模型的概念和原则,尤其是0层等效的概念。
管理员账户遍布各地
假设你已经遵循了上面的所有建议——为所有支持人员提供了单独的管理帐户,目前为止一切正常。 现在,突然之间,你意识到所有这些增加的复杂性给你带来了另一个问题: 管理员帐户生命周期管理。
· 当你的管理员离开公司时,谁会记得检查(并禁用)相关的管理帐户呢?
另一个你可能会遇到的问题是,在对源自管理账户的可疑或异常活动进行分类时,所有这些账户都属于同一个人。
比如说,如果一个域管理员账户在凌晨3:45突然删除了目录中的一大堆对象,并开始更改用户的密码——你可能想要联系实际掌管此账户的员工并要求他们确认这是否是有意的——所以自动将管理员账户的身份转换为相关的常规用户账户的能力可能非常重要。 这就给我们留下了两个需要回答的问题:
· 给定一个管理帐户的标识,返回相关联的用户
· 给定一个用户的身份,返回任何相关的管理员帐户
我见过很多通过比较用户名来实现这一点的尝试,希望组织(通常不强制执行)的命名约定能够挽救局面(“ john-admin 可能属于 john”) ,我也见过几乎同样多的失败案例。 我们需要一个更强有力的方法来解决这个问题。
 
>域环境中的管理员账户保护:管理帐户架构扩展-网络安全-黑吧安全网
模式扩展
换句话说,我们需要某种方法来持久化活动目录中用户帐户对象之间的一对多关系。 听起来很熟悉吧?
事实上,活动目录已经有许多属性正是以这种方式工作的。 我们想到的第一个例子是 manager / directreports ——我们称之为 link-value 属性。 当帐户上的 manager 属性设置为 x 值时,x 标识的对象上的 directReports 属性将自动反映更新的帐户的值。 我们将第一个属性(manager)称为这对的前向链接属性,而第二个属性(directReports)是反向链接。
我们可以利用这个机制,通过3个简单的步骤来创建我们自己的映射:
· 在模式中创建一对链接属性
· 创建一个可能包含属性的辅助类
· 将辅助类与现有的 user 对象类关联
属性模式
简单地说,活动目录中的每个对象都由一个内部的、特定于副本的标识(DNT)和一些可能具有值或不具有值的属性组成。 每个属性的行为依次由 Schema 命名上下文中的 attributeSchema 对象绑定。 如果我们想要扩展活动目录的行为,我们需要添加一些attributeSchema!
考虑到这一点,我们首先来看一下 manager 属性的模式定义:
# Discover the schema container
$rootDSE = Get-ADRootDSE
$schemaNC = $rootDSE.schemaNamingContext
# Discover schema master
$schemaMaster = Get-ADObject $schemaNC -Properties fSMORoleOwner | Get-ADDomainController -Identity { $_.fSMORoleOwner }
# Retrieve the ‘manager’ attribute
Get-ADObject -Filter ‘Name -eq "manager"’ -SearchBase $schemaNC -Properties *
adminDisplayName                : Manager
attributeID                     : 0.9.2342.19200300.100.1.10
attributeSyntax                 : 2.5.5.1
DistinguishedName               : CN=Manager,CN=Schema,CN=Configuration,DC=corp,DC=iisreset,DC=me
isMemberOfPartialAttributeSet   : True
isSingleValued                  : True

[1] [2] [3] [4]  下一页

【声明】:黑吧安全网(http://www.myhack58.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱admin@myhack58.com,我们会在最短的时间内进行处理。

上一篇:攻击者仍在利用SharePoint的漏洞展开大规模攻击返回黑吧安全网首页】【进入黑吧技术论坛
下一篇:安全圈是这么玩车的——对Tesla Model S 固件更新过程的逆向研究


Notice: Undefined variable: canUpdate in /var/www/html/wordpress/wp-content/plugins/wp-autopost-pro/wp-autopost-function.php on line 51