端到端的NAC仍然很困难

InteropLabs NAC团队构建了三个演示区域，每个区域都致力于一个架构模型:可信计算集团的可信网络连接(TCG-TNC)、微软的网络访问保护(小憩）和思科网络准入控制（C-NAC）。我们的目标是把互操作的产品一起在每个NAC仓，并建立一个完整的，端到端的端到端部署。总体而言，我们确实发现每个发射井内互操作的产品，但没有NAC架构完全在这个时候的产品填充。

TNC，最简单的我们的示范区，在短短几个小时来了，但NAP和C-NAC采取了一些工程师和一个很长周末去一个稳定的状态。在这两个艰难的情况下，我们就不会如此成功，因为我们是从没有供应商的工程师谁已通过行使自己的互操作性实验室中得到实质性的现场咨询。

NAC的世界充满了所有功能于一身的厂商的解决方案的这一提议，以解决一些公司的NAC问题的大部分时间。InteropLabs的整点是互通的，我们找了多个产品供应商该插件为开放式架构。

不幸的是，企业买家，InteropLabs'焦点抛出就缺乏在NAC市场的互操作解决方案的致盲的聚光灯下。

例如，锁定网络排在其产品整合到NAP示范区。锁定提供了一个“完整的”终端到终端NAC系统，但它是完全只有当你使用它的产品及其策略一切从服务器到客户端和每一个执法技术之间。

我们试图将锁定系统锁定在NAP政策决策点(网络中NAC政策决策制定的地方)。但Lockdown很快就放弃了全面参与，但承诺会在午睡时再回来。

在其他情况下，我们的实现之所以停滞不前，仅仅是因为没有可供选择的供应商。例如，在NAP竖井中，没有一家供应商为Microsoft客户端提供客户姿态数据收集和验证插件。

这可能不会是这样一个巨大的惊喜，看到我们是九月份按从Vista / Longhorn的发布 - Windows版本将完全支持NAP-，但它是如何全新尝试这项技术的证据。在TNC测试网络，我们有三种可用的完整性测量验证 - 但仅仅是因为工程师Juniper网络公司写了三个。

可信计算集团的可信网络连接

TNC系统互操作性演示由用户的系统和Juniper的钢子午线半径（SBR）服务器作为策略决策点上Juniper的奥德赛客户端。该演示上来快，但有一点需要注意：瞻博网络已经计划从它带到InteropLabs产品继续前进。的Infranet，瞻博网络的原始NAC架构，正在经历一场激进的重组作为公司的收购Funk软件公司去年十二月的结果。

在InteropLabs测试中，我们听到的主要原因芬克太迷人了瞻博网络之一：基于对TNC架构的完全可操作的NAC产品。瞻博网络承诺将带来2.0版本的NAC产品集于互操作，这将恐怖客户端和服务器件结合了自己的Infranet控制器策略管理工具。这种组合应该可以帮助推动瞻博网络的防火墙和SSL VPN设备作为TNC领域内的执行点。

在我们InteropLabs筒仓，我们建立了一个网络，其中策略执行点可以是任何四802.1倍兼容的开关从思科,凯创,极端和惠普或两个来自思科(Cisco)和Enterasys的兼容802.1 x的无线接入点。

为了网络的策略决策点，我们狂奔在赛门铁克基于Juniper SBR服务器的完整性测量验证器。Juniper为TNC构建了四个完整性测量验证器IBM/蒂沃利迈克菲，PatchLink公司和赛门铁克。我们不安地发现，只有Juniper网络公司出货的生产TNC客户端。当然，这一些稀缺的是因为不完整的TNC规范。我们希望通过明年的这个时候，我们将在客户更多的选择。

因为所有的开关和接入点都支持RFC 3580 -虚拟局域网分配 - 我们发现，客户和不符合的活动会分流掉生产或隔离VLAN。这是一个相当有限的示范，但显示NAC的承诺的一个很小的方面。为了扩大我们的市场进入到由NAC在将来解决更有趣的地方，马克·汤森，热台在现场的凯创的工程师，带来了凯创交换机与细粒度访问控制的图片 - 简单的包过滤器 - 到位。

这是一个有趣的实验，因为它示出在NAC网络不同交换机混合的危险。我们发现，如果我们把访问控制列表的优势的Enterasys交换机的功能，其他的几个开关辞掉工作作为NAC策略执行点。我们也看到交换机之间的分歧有关的格式半径属性由SBR服务器发送。

幸运的是，我们有瞻博网络工程师克里斯蒂安·麦克唐纳和杰夫·赖利现场必要的魔法添加到SBR服务器通过为每个设备创建单独的RADIUS字典来解决这个问题。无论快乐的结局，它是如何变脆NAC部署可以和多少专业知识，需要把所有的拼在一起良好的工作秩序狠狠地教训。

除了Juniper实现之外，TNC团队还使用开源工具进行了一个并行的nacl部署工作。来自犹他大学的Chris Hessing是Xsupplicant(开源802.1X supplicant)的主要开发者之一Linux的系统。Hessing与开放系统顾问迈克·麦考利合作，TNC支持添加到Xsupplicant和散热器，商业RADIUS服务器。

在HotStage结束时，Hessing在访问请求程序上有了Xsupplicant，使用游标边墙网关作为策略实施点与策略决策点端的辐射器进行通信。这项工作不会有太多的商业影响(因为企业很少担心他们的Linux桌面的终端安全状态)，但是它确实代表了一个无价的参考平台，对于那些想要测试互操作性或者只是想看看“它是如何结合在一起的”的软件开发人员来说。

微软的网络访问保护

如果没有准确说明要安装的构建以及如何避免产品的粗糙点，但没有人有经验的微软工程师导游站在获取NAP运行在这个阶段在Vista中/ Longhorn的测试周期的机会。我们的团队，由克雷格·沃特金斯，互操作最资深的网络工程师之一的带领下，度过了从Microsoft网站上的热台下载代码，猜测要安装哪些组件和挣扎在Longhorn的服务器和Vista客户端的前四天，但无济于事。接着，幸运的是，微软发下来克里斯·塔克，NAP的测试工程师之一，事情开始陷入到位。

尽管NAP计划与许多访问方法集成，例如安全虚拟专用网，我们的演示集中在一个802.1X使用它，有线和无线LAN（WLAN)环境。我们组装了思科，Enterasys, Extreme, HP和北电，以及从Aruba无线网络、思科和惠普作为我们的政策执行点。在NAP的世界中，寻找完整性度量收集器(收集端点安全信息的客户机上的软件)和完整性度量验证器并不容易。

微软有一个完整性测量集电极 - 验证对计算结果的Windows安全设置，如状态其内置火墙和Windows更新。但是在Vista/Longhorn的生命周期中，还没有其他的收集器和验证器工具可以在这么早的时间里投入使用。最接近准备的是一个工具CA对于eTrust杀毒，因为微软使用其内部beta测试的工具。我们坚持用微软自己的收集和验证工具。

我们的结果喜忧参半，特别是在无线领域，但是这可能更多的是与Longhorn和Vista的新颖性比在NAP软件缺陷。例如，在我们的Longhorn服务器上的一个点上的网络策略服务器（NPS）（这是微软的策略决策点）开始录制错误日志文件而不是响应NAP身份验证请求，这表明一些Longhorn的TCP之间打破了/IP堆栈和核动力源应用。

快速重新启动解决了这个问题，但是找到突然出错的服务器需要时间。我们在客户方面的经验也是不确定的。我们有两台运行Vista的相同笔记本电脑，直到凌晨，一台运行得非常好，而另一台根本无法验证。第二天,mirabile dictu，一切都好。

在另一个新平台对NAC提出警告的例子中，我们可以指出Vista没有处理DHCP正确隔离和生产网络，这需要人工干预之间的无线网络和假摔上时。但从互操作性的角度，但是，NAP与我们测试的有线和无线设备运行良好。我们碰到了我们在跨国公司看到了同样的RADIUS格式的互操作性问题，但使用内置到微软的NPS工具机制解决了这个问题。

思科的网络准入控制

我们的C-NAC示范成败参半：我们试过的工作，但由于时间的限制，我们无法探索C-NAC架构的广度。从InfoExpress的蓝代斯克和的C-NAC队，由Brett托森，网络科学家专门从事IPv6安全导致广泛的现场支持，建立了C-NAC网络与多个完整性测量收集和验证对。什么思科的网络开放性的网络策略执行点层缺乏 - 你可以只使用思科交换机 - 它弥补了第三方的可用性，可互操作的工具，以帮助在作出政策决定。

思科提供了巨大的硬件支持，但不能放过任何工作人员，以帮助配置。这给我们留下了相当高，干燥，在相当短为了把事情一起工作正常。思科信任代理（CTA）的客户端软件使用依赖于网络的拓扑结构，以获取有关从完整性测量收集到验证端点安全评估信息战略。

我们使用了它的可扩展认证协议(学术用途英语）-over-用户数据报协议（UDP）的策略与Cisco路由器和交换机作为该问题的第一刺，以移动到EAP-过802.1X选项如果时间允许的计划。由于时间限制，我们不能试图思科的无客户端选项，思科清洁接入（从Perfigo收购）或自己的主机入侵侦测系统，思科安全访问（从Okena收购）。

在访问请求者侧，思科提供了思科信任代理，谈话对政策决定点侧思科访问控制服务器（ACS）版本4.0 Radius服务器。

我们使用一台Cisco 3550局域网交换机作为我们的策略执行点，并带来InfoExpress的的Cyber​​Gatekeeper和LANDesk的管理套件中的完整性测量收藏家和验证，用一块坐在客户端和策略决策点内运行InfoExpress的和蓝代斯克服务器，说话思科ACS RADIUS服务器。

我们观察到，蓝代斯克和InfoExpress的和Cisco的ACS之间的整合是不会工作在所有情况下。特别是，我们看到了客户端工具可以仅使用C-NAC路径，得到他们的诚信信息到他们的服务器。他们不得不在网络上的支配路径。如果一家公司希望其网络中混合EAP-过UDP和EAP-过802.1X通信流这会导致问题。蓝代斯克是只兼容旧版本的CTA（2.0版之前），而该公司的工程师现场无法与CTA客户端C-NAC工具的当前版本，他的工具集成。

虽然思科的解决方案需要较长的时间来建立比我们此前预期，我们发现的安全管理工具在客户端和服务器端的ACS的顶部坐在CTA的顶部之间良好的互操作性。在更改网络也很容易。

例如，虽然我们的第一个第三方供应商LANDesk花了一整天的时间让所有东西都运行起来，但在一切稳定之后将InfoExpress的设备添加到网络只需要几个小时的工作。

对我们的整体NAC互操作体验的底线是，这是一个市场，不仅存在强烈的香气也是林堡。我们有厂商的三层实木团体试图解决一个共同的问题，推动尽快商业化成为可能。

虽然市场上存在相当大的混乱，但可以有把握地说，互操作的解决方案将在年底或明年年初面世。不过，现在就得出哪种策略对哪种类型的网络最有效的结论还为时过早，尤其是考虑到强大的思科公司(Cisco)正与跨国公司(TNC)以标准为基础的方法针锋相对。

斯奈德，一个网络世界足球竞猜app软件测试联盟合作伙伴，在作品一号在亚利桑那州图森的高级合伙人，他可以达到Joel.Snyder@opus1.com。