谈谈基于Kerberos的Windows Network Authentication[下篇]

六、User2User Sub-Protocol:有效地保障Server的安全

通过3个Sub-protocol的介绍,我们可以全面地掌握整个Kerberos的认证过程。实际上,在Windows 2000时代,基于Kerberos的Windows Authentication就是按照这样的工作流程来进行的。但是我在上面一节结束的时候也说了,基于3个Sub-protocol的Kerberos作为一种Network Authentication是具有它自己的局限和安全隐患的。我在整篇文章一直在强调这样的一个原则:以某个Entity的Long-term Key加密的数据不应该在网络中传递。原因很简单,所有的加密算法都不能保证100%的安全,对加密的数据进行解密只是一个时间的过程,最大限度地提供安全保障的做法就是:使用一个Short-term key(Session Key)代替Long-term Key对数据进行加密,使得恶意用户对其解密获得加密的Key时,该Key早已失效。但是对于3个Sub-Protocol的C/S Exchange,Client携带的Ticket却是被Server Master Key进行加密的,这显现不符合我们提出的原则,降低Server的安全系数。

所以我们必须寻求一种解决方案来解决上面的问题。这个解决方案很明显:就是采用一个Short-term的Session Key,而不是Server Master Key对Ticket进行加密。这就是我们今天要介绍的Kerberos的第4个Sub-protocol:User2User Protocol。我们知道,既然是Session Key,仅必然涉及到两方,而在Kerberos整个认证过程涉及到3方:Client、Server和KDC,所以用于加密Ticket的只可能是Server和KDC之间的Session Key(SKDC-Server)。

我们知道Client通过在AS Exchange阶段获得的TGT从KDC那么获得访问Server的Ticket。原来的Ticket是通过Server的Master Key进行加密的,而这个Master Key可以通过Account Database获得。但是现在KDC需要使用Server和KDC之间的SKDC-Server进行加密,而KDC是不会维护这个Session Key,所以这个Session Key只能靠申请Ticket的Client提供。所以在AS Exchange和TGS Exchange之间,Client还得对Server进行请求已获得Server和KDC之间的Session Key(SKDC-Server)。而对于Server来说,它可以像Client一样通过AS Exchange获得他和KDC之间的Session Key(SKDC-Server)和一个封装了这个Session Key并被KDC的Master Key进行加密的TGT,一旦获得这个TGT,Server会缓存它,以待Client对它的请求。我们现在来详细地讨论这一过程。


上图基本上翻译了基于User2User的认证过程,这个过程由4个步骤组成。我们发现较之我在上面一节介绍的基于传统3个Sub-protocol的认证过程,这次对了第2部。我们从头到尾简单地过一遍:

  1. AS Exchange:Client通过此过程获得了属于自己的TGT,有了此TGT,Client可凭此向KDC申请用于访问某个Server的Ticket。
  2. 这一步的主要任务是获得封装了Server和KDC的Session Key(SKDC-Server)的属于Server的TGT。如果该TGT存在于Server的缓存中,则Server会直接将其返回给Client。否则通过AS Exchange从KDC获取。
  3. TGS Exchange:Client通过向KDC提供自己的TGT,Server的TGT以及Authenticator向KDC申请用于访问Server的Ticket。KDC使用先用自己的Master Key解密Client的TGT获得SKDC-Client,通过SKDC-Client解密Authenticator验证发送者是否是TGT的真正拥有者,验证通过再用自己的Master Key解密Server的TGT获得KDC和Server 的Session Key(SKDC-Server),并用该Session Key加密Ticket返回给Client。
  4. C/S Exchange:Client携带者通过KDC和Server 的Session Key(SKDC-Server)进行加密的Ticket和通过Client和Server的Session Key(SServer-Client)的Authenticator访问Server,Server通过SKDC-Server解密Ticket获得SServer-Client,通过SServer-Client解密Authenticator实现对Client的验证。

这就是整个过程。

七、Kerberos的优点

分析整个Kerberos的认证过程之后,我们来总结一下Kerberos都有哪些优点:

1.较高的Performance

虽然我们一再地说Kerberos是一个涉及到3方的认证过程:Client、Server、KDC。但是一旦Client获得用过访问某个Server的Ticket,该Server就能根据这个Ticket实现对Client的验证,而无须KDC的再次参与。和传统的基于Windows NT 4.0的每个完全依赖Trusted Third Party的NTLM比较,具有较大的性能提升。

2.实现了双向验证(Mutual Authentication)

传统的NTLM认证基于这样一个前提:Client访问的远程的Service是可信的、无需对于进行验证,所以NTLM不曾提供双向验证的功能。这显然有点理想主义,为此Kerberos弥补了这个不足:Client在访问Server的资源之前,可以要求对Server的身份执行认证。

3.对Delegation的支持

Impersonation和Delegation是一个分布式环境中两个重要的功能。Impersonation允许Server在本地使用Logon 的Account执行某些操作,Delegation需用Server将logon的Account带入到另过一个Context执行相应的操作。NTLM仅对Impersonation提供支持,而Kerberos通过一种双向的、可传递的(Mutual 、Transitive)信任模式实现了对Delegation的支持。

4.互操作性(Interoperability)

Kerberos最初由MIT首创,现在已经成为一行被广泛接受的标准。所以对于不同的平台可以进行广泛的互操作。

原文地址:http://www.cnblogs.com/artech/archive/2007/07/10/811970.html

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Windows 系统下部署 Kerberos 服务,通常可分为以下几个步骤: 1. 安装 Active Directory 域服务。Kerberos 服务是基于 Active Directory 的,因此需要安装和配置 Active Directory 域服务。 2. 创建 Kerberos Realm。使用 Active Directory 管理工具创建 Kerberos Realm,该 Realm 的名称通常与 Active Directory 域名称相同。 3. 创建 Kerberos Principal。在 Kerberos Realm 中创建 Kerberos Principal,该 Principal 通常对应着一个用户或服务。 4. 生成 Keytab 文件。Keytab 文件包含了 Kerberos Principal 的加密密钥,可以用于 Kerberos 身份验证。使用 ktpass 命令生成 Keytab 文件。 5. 配置 Kerberos 应用程序。在应用程序中配置 Kerberos 身份验证,包括指定 Kerberos 库的位置和 Keytab 文件的位置。 下面是一个简单的教程,介绍如何在 Windows Server 中部署 Kerberos 服务: 1. 安装 Active Directory 域服务。在 Windows Server 上,打开 Server Manager,选择 Add Roles and Features,然后选择 Active Directory Domain Services 进行安装。 2. 创建 Kerberos Realm。使用 Active Directory Users and Computers 管理工具,创建一个新的 Active Directory 域,该域的名称就是 Kerberos Realm 的名称。 3. 创建 Kerberos Principal。在 Active Directory Users and Computers 中创建一个新的用户或服务账户,该账户就是 Kerberos Principal。 4. 生成 Keytab 文件。打开命令行工具,使用 ktpass 命令生成 Keytab 文件。例如,以下命令将创建一个 Keytab 文件,用于 Kerberos Principal "user1@EXAMPLE.COM": ``` ktpass /out user1.keytab /princ user1@EXAMPLE.COM /mapuser user1 /pass password /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1 ``` 5. 配置 Kerberos 应用程序。在应用程序中设置 Kerberos 身份验证,包括指定 Kerberos 库的位置和 Keytab 文件的位置。例如,在 Java 应用程序中,可以通过设置系统属性来指定 Kerberos 库和 Keytab 文件的位置: ``` System.setProperty("java.security.auth.login.config", "krb5.conf"); System.setProperty("java.security.krb5.realm", "EXAMPLE.COM"); System.setProperty("java.security.krb5.kdc", "kdc.example.com"); System.setProperty("javax.security.auth.useSubjectCredsOnly", "false"); System.setProperty("sun.security.krb5.debug", "true"); System.setProperty("sun.security.spnego.debug", "true"); System.setProperty("sun.security.jgss.debug", "true"); System.setProperty("sun.security.spnego.initiate", "true"); System.setProperty("sun.security.spnego.targetName", "HTTP/server.example.com@EXAMPLE.COM"); System.setProperty("javax.net.ssl.trustStore", "truststore.jks"); System.setProperty("javax.net.ssl.trustStorePassword", "password"); System.setProperty("javax.net.ssl.keyStore", "keystore.jks"); System.setProperty("javax.net.ssl.keyStorePassword", "password"); ``` 以上是一个简单的 Kerberos 部署教程,实际情况可能更为复杂。如果您需要更详细的教程,建议参考 Microsoft 的官方文档。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值