在我工作过的公司中,有一种趋势是管理员(或服务台人员)会礼貌地为用户提供旧密码的扩展名……而不是强迫用户更改密码。
这通常是通过直接通过 AD 用户和计算机重新输入过期密码来完成的……而不是通过 Ctrl-Alt-Delete 更改它。
鉴于“最后一次密码更改”字段不是检测这种情况的有效方法;如何检测过期密码重用?
一个例子是每隔一段时间比较一次密码哈希以确保合规性;但我正在寻找最合乎逻辑和最安全的方法。
在我工作过的公司中,有一种趋势是管理员(或服务台人员)会礼貌地为用户提供旧密码的扩展名……而不是强迫用户更改密码。
这通常是通过直接通过 AD 用户和计算机重新输入过期密码来完成的……而不是通过 Ctrl-Alt-Delete 更改它。
鉴于“最后一次密码更改”字段不是检测这种情况的有效方法;如何检测过期密码重用?
一个例子是每隔一段时间比较一次密码哈希以确保合规性;但我正在寻找最合乎逻辑和最安全的方法。
在组策略中配置审核的方法不止一种,但我认为主要的旧方法(在 Windows Server 2003 上)是打开 GPMC,编辑默认域策略(或在 OU 和对象中处于活动状态的任何域策略)重新使用),并从策略节点通过 Windows 设置向下钻取到安全设置,以打开本地策略审核策略分支。您可以定义一个“审计帐户管理”部分。
以上仅允许您审核帐户更改,但您必须通过将其与成功标准相关联来使其可操作,例如用户的密码最近过期。通过利用 OSSIM(或其他强关联引擎),您可以组合 ADSI 脚本来检查每个审计帐户管理消息,以查看是否是密码更改,以及密码是否最近过期。然后,可以匹配哈希,等等。甚至可以启动 OpenVAS 以尝试暴力破解密码——尽管使用更多数据执行此任务可能会更好。
这成为客户端、服务器和其他基础设施强化/监控的定制练习。您可能希望将整个基础架构的成熟度提升到更高的水平——因此我假设您已经完成了互联网安全中心 (CIS)和/或NIST规定的大部分工作。
如果您是新手并且过去没有实施过这样的定制解决方案,那么跳到ForgeRock的 OpenIDM等面向未来的解决方案肯定会更好。这将是一个耗资数百万美元、为期六年的项目。
如果您处于大型安装棕地运营中,例如财富 500 强 - 最好识别您现有的 IAM、IDM、目录、ESB 和其他后台组件,以便正确分析适合身份生命周期管理问题的位置例如用户密码重置。现有的解决方案提供商(例如 SAP、Oracle、TIBCO 或 Microsoft)可能有一个简单的答案。
如果您只是 Microsoft 商店 (100%),那么您可能想讨论他们的ILM 2007产品、FIM 2010和相关解决方案。微软有一种令人讨厌的方式来取消这些产品线,或者彻底改变它们——所以最好与“内部轨道”保持一致,直接与 ILM/FIM 和其他产品经理 (PM) 讨论,而不仅仅是客户经理(AM) 或其网站和交易信息。
还有其他更重要的解决方案,例如 Quest 软件的ChangeAuditor for AD,但我会警惕这只会解决短期问题,因为显然可能存在业务流程和大量业务/基础设施成熟度问题。
也许这里的答案不仅仅是技术,还有过程。这种礼貌,不应该做,应该审核管理员的行为,应该惩罚这样做的管理员。除非它符合安全政策(如果你有)
在技术层面上,这里的根本问题是帮助台可以重置密码并且不选中“用户必须更改密码”复选框。
我不知道有一种方法可以强制选中此复选框。可能有一个,但我不知道如何。
解决此问题的一种方法可能是不授予帮助台人员对 AD 用户和计算机的委托访问权限,而是创建一个使用 LDAP 重置密码并同时设置“用户必须在下次登录时更改密码”标志的脚本. 您可以使此脚本更加方便(对于帮助台):自动生成一个简短的密码作为临时密码,然后通过电子邮件将其(或交给)用户。
也就是说:归根结底,这不是技术问题。如今,即使是非技术用户也在处理大量密码,我完全感受到了他们的痛苦。一些安全人员一直认为,很少或从不更改的更长但易于记忆的密码实际上可能更好。
通常,即使没有“礼貌扩展”,用户也会通过始终使用带有计数器的相同简短简单密码并在易受攻击的系统和敏感系统之间共享相同的密码来破坏密码更改机制。或者通过向最高管理层投诉并将政策更改为“永不更改密码”。
所以你最好的策略是在最高管理层解决这个问题。如果高层管理人员不支持解决这个问题,你试图在技术层面处理它可能会适得其反。如果高层管理人员是支持解决这个问题,你可能并不需要的技术解决方案; 服务台人员将获得专门禁止此类礼貌行为的新政策。