我们虚构的攻击者利用 ZeroLogon 可以完全破坏这一点。更糟糕的是，攻击者可以将 EPM 服务器踢出域，这使得跳转到 EPM 服务器并解决无人能登录的问题变得困难。
我曾与一些客户合作，他们使用 Microsoft 的替代方案进行最终用户身份验证，例如 Novell eDirectory 或其他 LDAP 解决方案。但总的来说，网络中的某个地方可能隐藏着 Microsoft Windows 域。
IT 部门，确认域控制器已应用 2020 年 8 月 Microsoft 补丁。我注意 科特迪瓦电报数据 到“外界”情况好坏参半；一些组织立即打上补丁，而其他组织则落后了……尤其是在财务季度末或年末变更冻结期间。
现在我们简单谈谈云。
Oracle 的 EPM SaaS 云产品（用于合并、规划、帐户记录等）都有一个共同点：EPMAutomate。
EPMAutomate 是云的命令行实用程序，用于执行各种任务：将数据上传到云、通过数据管理运行数据、触发计算规则、下载报告和审计日志等。EPMAutomate 驻留在客户控制的服务器上，无论是在本地还是在托管云中，例如 AWS、Azure、OCI 等。我见过的绝大多数 EPMAutomate 实现都位于 MS Windows 服务器上。（它可以托管在 Linux 上，有时我见过这种变化。）
如果 EPMAutomate 托管在 MS Windows 上，并且该计算机恰好加入了 MS Windows 域……那么， 如果入侵者破坏了您的网络帐户或将 EPMAutomate 主机服务器踢出域，您的 EPM Cloud 自动化可能会在某一天停止工作。（再次，我使用可能性这个词， 直到 我们 看到它最终发生的后果。）
到目前为止，2020 年是糟糕的一年，所以请尽自己的一份力量，不要让它变得更糟糕。坚持让您的网络域控制器针对“CVE-2020-1472”进行修补，该修补包含在2020 年 8 月 Microsoft 补丁星期二中。
这就是这篇文章的全部内容，但是如果您想了解有关 EPM 11.2 的更多内容，请务必查看我的白皮书“ Hyperion 11.1.2.4 的最后时刻 — 以下是要做的事情”。
从 EPM On-Prem Pro 交叉发布。请在此处阅读原始帖子。