DirectAccess 健康报告

　　为了开始处理 Woodgrove National Bank 的 NAP 和 DirectAccess 事件，我们下载并安装了 Microsoft 的 Log Parser 2.2。Log Parser 是这种项目中必不可少的工具，因为您必须浏览新的事件来源并制定相应的架构。简而言之，Log Parser 可以导入和导出多种数据格式，包括 Windows 事件日志 (.evtx)、CSV 和 SQL。

　　下一步是捕获所需的事件，包括：

　　DirectAccess 服务器安全日志中与 IPsec 安全关联相关的事件

　　HRA 服务器(如果使用 NAP 则是多台服务器)安全和系统日志中与健康注册机构相关的事件

　　收集这些事件的最好方法是实现自动化与集中化。Windows 事件转发功能就是这样一种选择。而在大型的生产部署中，Microsoft System Center 可能更加常用。在本示例中，我们不想为生产服务器加入新的关联功能，因此使用了简单的脚本来收集事件。

　　要使用这种方法，我们面对的挑战来自两个方面。首先，我们要关联多个数据源，因此大致在同一时间收集来自所有数据源的数据就很重要。其次，我们只需获取日志的快照，而高流量的事件日志滚动更新很快，因此一些关联事件的丢失就无法避免，尤其是在快照时间段的边缘时刻。这并不会导致实验失败，但会使微调查询变得更困难一些。

　　对于每个 IPsec 主模式安全关联(在一台 DirectAccess 服务器上)，我们预计会看到 NAP 健康流量(在一台 HRA 服务器上)。在 NAP 报告模式中，客户端计算机可能已经合规也可能并不合规。在 NAP 强制模式中，客户端计算机应该已经合规。否则，客户端如何获得有效的证书以通过 DirectAccess 服务器的身份验证并建立安全关联 (SA)?假设我们在下午 3 点同时截取所有 DirectAccess 和 HRA 服务器上的日志，有可能我们只看到主模式安全关联 (MM SA) 事件，而看不到健康事件。

　　更有可能的是，我们可以看到 IPsec 快速模式安全关联 (QM SA) 和 IPsec 扩展模式安全关联 (EM SA) 事件，而看不到 MM SA 或健康事件。前者的发生要比后者晚一个小时甚至更多。此外，因为各台服务器上的日志几乎肯定是按不同的频率滚动更新的，所以我们可能在 DirectAccess 服务器上获得自下午 2 点以来的事件，而在 HRA 上最早的事件也是从下午 2:30 开始的。正是由于上述这些原因，我们需要重申，在生产环境中使用集中的事件收集非常重要。