当Windows 2000 Server发布的时候，当时我们最期待就是IPsec，因为操作系统中有了IPsec，就能够帮助我们保护网络中所有计算机间通信的安全，这样我们将不再需要担心会有人使用网络嗅探器窃取密码、用户名和应用程序信息。虽然IPsec能够让这一切实现，但是当时的IPsec太复杂、太有限，而且坦率地说，存在很多瓶颈问题。
而在Windows Server 2003中，事情就变得容易一些。Windows 2000 Server要求我们在每台想要启用IPsec政策的机器上运行IPsec向导，而Windows Server 2003则是使用组策略，以anIPsec组策略管理单元的形式来为网络中的windows server 2003和windows XP配置IPsec政策。有了Active Directory启用的组策略，我们可以对IPsec政策进行规划。然而，IPsec配置向导却同样复杂。
IPsec是windows TCP/IP协议栈的一部分，Ipsec驱动是非常低级别的驱动程序。Ipsec策略，顾名思义，是部署在网络层的，发生在任何应用层数据被系统接收前。当你配置Ipsec策略时，你可以配置Ipsec来确定以下规则：
IPsec应该保护哪些流量？
流量是否应该被允许或者阻止
如果流量被允许，是否应该要求身份验证或者加密
如果要求加密和/或身份验证，应该使用哪种类型的加密或者身份验证
同时还有其他设置，例如定义源地址和目的地址或者该策略使用的网络。
不过，当2005年微软发布有关服务器和域隔离(SDI)的信息后，似乎对IPsec造成不小冲击。关于SDI的构想就是，你可以从逻辑上将网络进行分段来保护域资源不受较低信任级的主机访问，可以从逻辑上将高价值资产与较低价值资产(或者高信任度资产和较低信任度资产)隔离，而不是物理上隔离这些安全区。这种使用IPsec逻辑分段的功能似乎非常有吸引力，并且能够节省成本。
SDI的理论听起来很不错。然而，实际操作过程却不尽人意。为了建立有效的SDI解决方案，你必须创建大量规则，随之需要非常复杂的部署过程。不仅设计很复杂，而且管理过程也很复杂。创建大量规则后，然后需要创建更多的规则以说明之前规则的例外情况，如此琐碎且耗时让管理人员失去了兴趣。
大家都知道，有时候微软需要在几次尝试之后才能找到正确的路，微软不想放弃利用IPsec来加强安全性这个思路，于是他们开始研究IPsec部署的问题并决定解决这些问题。这最终催生了AuthIP，它实现了IPsec的功能，改善了互联网密钥交换(IKE)协议，并解决了IPsec早前版本中存在的问题。AuthIP首次出现实在Vista系统和windows server 2008中，Windows 7和Windows Server 2008 R2同样有AuthIP功能。
AuthIP加强了IPsec功能
AuthIP实际上是对IKE协议的扩展，其中包括新的标志和谈判方法以提高IPsec的有效性。AuthIP可以在运行Vista、Windows 7、Windows Server 2008 和Windows Server 2008 R2的计算机中使用。如果这些计算机需要使用IPsec来与不支持AuthIP的旧版计算机通信的话，将无法再使用IKE。
AuthIP主要有以下特点，这些在IKE早前版本不存在：
以新方式对用户进行身份验证
使用多种协议或者方法进行身份验证
使用更加有效的协议谈判
使用多套凭证来进行身份验证
以新方式对用户进行身份验证
如果你还记得早前版本IPsec的身份验证方式，你就知道，之前的身份验证是基于计算机凭证的。对于计算机身份验证有两个选择：计算机证书验证或者使用Kerberos的计算机帐号验证。或者你也可以使用预共享的密钥，但是可扩展性和安全性不是那么好。如果你想要控制哪些用户能够访问服务器应用程序，则你需要在应用程序级别来处理用户身份验证，这意味着来自可信任机器的不可信任用户可能会在网络级别对承载应用程序的服务器发动攻击。
有了AuthIP，我们就可以通过计算机帐号、用户帐号或者两者来控制访问权限。这将在TCP/IP协议栈的较低级别执行身份验证，这样就不再需要依赖于应用程序来验证用户身份。有了AuthIP，我们可以在网络层验证用户，并且保护应用程序免受发生在应用层身份验证前的网络层攻击。
你可以使用AuthIP的以下用户身份验证方法：
计算机健康证书，这是网络访问保护(NAP)使用的
用户证书(用户证书库的客户端证书)
登陆用户帐号使用NTLMv2
登陆用户帐号使用Kerberos
使用多种协议或者方法进行身份验证
AuthIP提供了之前IPsec版本没有的部署方法。例如，你需要支持每个谈判方不同的验证方法。例如，可能IPsec谈判支持证书验证，而另一边支持计算机帐号认证，在以前版本可能无法实现，但是AuthIP提供。
例如，考虑这样的情况，你想要使用IPsec来保护隔离区服务器和数据中心服务器间同学的安全。隔离区的服务器所在的forest对数据中心服务器的forest有单向的信任，也就是说隔离区forest信任数据中心forest，但是数据中心forest不信任隔离区forest。这使数据中心forest的用户可以使用用户或者计算机凭证连接到隔离区服务器，但不允许隔离区的用户使用计算机或用户凭证登陆到数据中心资源。
然而，你必须在每个服务器部署证书，并且每个服务器信任其他服务器的证书。有了AuthIP，现在你可以支持验证各方使用不同验证方法的情况。在这种情况下，当数据中心服务器验证其IPsec连接到隔离区服务器时，将会使用用户或者计算机帐号Kerberos验证。当隔离区服务器验证到数据中心服务器时，将会使用计算机或用户证书验证。虽然IPsec各方使用不同的身份验证方法，他们仍然能够建立IPsec连接，因为目标是成功验证，而不是使用相同身份验证协议的成功验证。
更加有效的谈判
如上所述，早期版本的IPsec(IKE)可以使用计算机证书的计算机帐号或者通过Kerberos的计算机帐号来进行身份验证，然而，如果首选验证方法失败，那么整个IPsec谈判将失败。
假设你有两台计算机希望使用IPsec来保护它们之间的通信，这两台计算机属于不同的forest，并且之间没有信任。但是，你已经在这些主机上部署了计算机证书，并且每天机器信任另一台机器的证书。然而，在早期版本的IKE中，这种情况的IPsec谈判将会失败，因为Kerberos身份验证失败后，潜在的IPsec将不会尝试使用计算机证书验证。
而AuthIP通过启用谈判验证方法来解决这个问题，如果一个方法失效，你还可以配置IPsec使用其他方法，而其他IPsec则会继续谈判验证方法直到找到共同点，这使我们可以更好地部署IPsec，并确保整个解决方案更加容易管理和配置。
使用多套凭证进行身份验证
你可能已经从AuthIP支持各种新方式中推测，可以使用多种凭证来验证IPsec。你可以使用计算机凭证、用户凭证或者两者来验证IPsec。如果你知道DirectAccess(windows 7企业版/旗舰版和windows server 2008 R2提供的远程访问技术)，你可能就会知道基础设施通道使用计算机证书和计算机帐户NTLMv2验证，而内网通道使用计算机证书和用户帐号Kerberos验证。通过添加用户证书到验证组合，你可以保护服务器免受可能使用可信任机器的恶意用户的攻击。
多种凭证支持允许的另一种情况就是NAP，在NAP中，计算机健康证书是用来验证计算机是否是域成员并且是否符合网络健康政策规定。这些证书可以堆栈在计算机和用户帐号验证的顶部，AuthIP让这一切变成可能。
域控制器支持让服务器和域隔离成为可能
IPsec在过去没有被使用的主要原因是域控制器的问题。如果你想要在网络中使用早前版本的IPsec，你必须从IPsec政策中免除域控制器。这样做的原因是：为了验证计算机，你必须访问域控制器，如果你不能访问域控制器，则无法进行身份验证。
Windows Server 2008及以上版本和Vista 及以上版本是通过启用以下操作来解决这个问题：
不再需要从IPsec政策中免除域控制器，你可以配置IPsec来决定何时使用Ipsecin与域控制器进行通信。
运行Windows Server 2008及以上版本和Vista 及以上版本的计算机当连接到域控制器时可以对凭证进行提示，这解决了“加入域”的问题，以前当需要将计算机加入域则必须从IPsec保护中免除以一台计算机。通过启用凭证提示，非域计算机可以提示凭证来迅速建立IPsec会话
对于下级客户端，你可以轻松创建政策(无需创建免除规则)要求IPsec保护，但并不是需要它
在intradomainIPsec谈判中的这些改进使IPsecdeployment 变得可行。
总结
IPsec最早出现在Windows 2000 Server中，尽管当时能够实现很多安全保护，但复杂度和操作的局限性都没能让IPsec部署在企业网络中。随后Vista 和Windows Server 2008(以及Windows 7和Windows Server 2008 R2)中的AuthIP服务的推出，显著改善了IPsec的灵活度和可管理性，让我们拥有了强大的身份验证机制，并能使用基于组策略的管理工具来进行配置，从而创建强大的IPsec政策。结合新用户身份验证方法，使用多种凭证的功能，更加灵活的身份验证谈判以及各方使用不同验证方法的功能都让IPsec得到了充分的发挥，为计算机通信提供了更好的安全。
