移动安全 安全管理 应用案例 网络威胁系统安全 应用安全 数据安全 云安全
当前位置: 主页 > 信息安全 > 系统安全 >

Windows安然认证是若何进行的?

时间:2013-05-04 10:19来源:TuZhiJiaMi企业信息安全专家 点击:
比来一段时候都在折腾安然(Security)方面的东西,好比Windows认证、非对称加密、数字证书、数字签名、TLS/SSL、WS-Security等。假定时候承诺,我很甘愿答应写一系列的文章与广大年夜网友分享、交
Tags系统安全(735)Windows(112)客户端(11)安全认证(2)  

  比来一段时候都在折腾安然(Security)方面的东西,好比Windows认证、非对称加密、数字证书、数字签名、TLS/SSL、WS-Security等。假定时候承诺,我很甘愿答应写一系列的文章与广大年夜网友分享、交换。对良多读者来讲,今天会商的多是一个既熟谙、又目生的话题——Windows认证。

  1、Kerberos认证简介

  Windows认证和谈有两种NTLM(NT LAN Manager)和Kerberos,前者首要利用于用于Windows NT 和 Windows 2000 Server(or Later) 工作组环境,而后者则首要利用于Windows 2000 Server(or Later) 域(Domain)环境。Kerberos较之NTLM更高效、更安然,同时认证过程也相对复杂。Kerberos这个名字来历于希腊神话,是冥界守护神兽的名字。Kerberos是一个三头怪兽,之所以用它来定名一种完全认证和谈,是因为全部认证过程触及到三方:客户端、办事端和KDC(Key Distribution Center)。在Windows域环境中,KDC的角色由DC(Domain Controller)来担负。

image

  某个用户采取某个域帐号登录到某台主机,并长途拜候处于不异域中另外一台主机时,若何对拜候者和被拜候者进行身份验证(这是一种双向的验证)?这就是Kerberos需要解决的场景。接下来我尽可能以比较直白的说话来介绍我所知道的Kerberos认证的全部流程。

  Kerberos实际上是一种基于单据(Ticket)的认证编制。客户端要拜候办事器的资本,需要起首采办办事端承认的单据。也就是说,客户端在拜候办事器之前需要预先买好票,等候办事验票以后才能出场。在这之前,客户端需要先买票,可是这张票不克不及直接采办,需要一张认购权证。客户端在买票之前需要预先获得一张认购权证。这张认购权证和进进办事器的出场券均有KDC发售。右图(点击看大年夜图)一张图根基揭露了Kerberos全部认证的过程。

  2、若何获得“认购权证”?

image

  起首,我们来看看客户端若何获得“认购权证”。这里的认购权证有个专有的名称——TGT(Ticket Granting Ticket),而TGT的是KDC一个首要的办事——认证办事(KAS:Kerberos Authentication Service)。当某个用户经由过程输进域帐号和暗码试图登录某台主机的时辰,本机的Kerberos办事会向KDC的认证办事发送一个认证要求。该要求首要包含两部门内容,明文情势的用户名和颠末加密的用于证实拜候者身份的Authenticator(我其实找不到一个比较贴切的中文翻译没,Authenticator在这里可以理解为仅限于验证双反预先知晓的内容,相当于联系记号)。

  当KDC领遭到要求以后,经由过程AD获得该用户的信息。经由过程获得的暗码信息生成一个秘钥对Authenticator进行解密。假定解密后的内容和已知的内容一致,则证实要求着供给的暗码准确,即肯定了登录者的真实身份。

  KAS成功认证对方的身份以后,会师长教师成一个用于确保该用户和KDC之间通信安然的会话秘钥——Logon Session Key,并采取该用户暗码派生的秘钥进行加密。KAS接着为该用户成立“认购权证”——TGT。TGT首要包含两方面的内容:用户相干信息和Logon Session Key,而全部TGT则经由过程KDC本身的密钥进行加密。最终,被不合密钥加密的Logon Session Key和TGT返回给客户端。(以上的内容对应流程图中的步调1、2)

  3、若何经由过程“认购权证”采办“出场券”?

  颠末上面的步调,客户端获得了采办进进同域中其他主机出场券的“认购凭证”——TGT,和Logon Session Key,它会在本地缓存此TGT和Logon Session Key。假定此刻它需要拜候某台办事器的资本,它就需要仰仗这张TGT向KDC采办响应的出场券。这里的出场券也有一个专有的名称——办事单据(ST:Service Ticket)。

image

  具体来讲,ST是经由过程KDC的另外一个办事TGS(Ticket Granting Service)出售的。客户端先向TGS发送一个ST采办要求,该要求首要包含以下的内容:客户端用户名;经由过程Logon Session Key加密的Authenticator;TGT和拜候的办事器(其实是办事)名。

  TGS领遭到要求以后,现经由过程本身的密钥解密TGT并获得Logon Session Key,然后经由过程Logon Session Key解密Authenticator,进而验证了对方的真实身份。

  TGS存在的一个底子的目有两点:其一是避免让用户的暗码客户端和KDC之间频繁传输而被盗取。其二是因为暗码属于Long Term Key(我们一般不会频繁的更新本身的暗码),让它作为加密密钥的安然系数必定小于一个频繁变换得密钥(Short Term Key)。而这个Short Term Key就是Logon Session Key,它确保了客户端和KDC之间的通信安然。

  TGS完成对客户端的认证以后,会生成一个用于确保客户端-办事器之间通信安然的会话秘钥——Service Session Key,该会话秘钥经由过程Logon Session Key进行加密。然后出售给客户端需要的出场券——ST。ST首要包含两方面的内容:客户端用户信息和Service Session Key,全部ST经由过程办事器暗码派生的秘钥进行加密。最终两个被加密的Service Session Key和ST答复给客户端。(以上的内容对应流程图中的步调3、4)

  4、凭票出场

  客户端领遭到TGS答复后,经由过程缓存的Logon Session Key解密获得Service Session Key。同时它也获得了进进办事器的出场券——ST。那么它在进行办事拜候的时辰便可以借助这张ST凭票出场了。该Serivce Session Key和ST会被客户端缓存。

  可是,办事端在领遭到ST以后,若何确保它是经由过程TGS采办,而不是本身捏造的呢?这很好办,不要忘了ST是经由过程本身暗码派生的秘钥进行加密的。具体的把持过程是如许的,除ST以外,办事要求还附加一份经由过程Service Session Key加密的Authenticator。办事器在领遭到要求以后,先经由过程本身暗码派生的秘钥解密ST,并从中提取Service Session Key。然后经由过程提掏出来的Service Session Key解密Authenticator,进而验证了客户端的真实身份。

  实际上,到今朝为止,办事端已完成了对客户端的验证,可是,全部认证过程还没有结束。谈到认证,良多人都觉得只是办事器对客户端的认证,实际上在大年夜部门场合,我们需要的是双向验证(Mutual Authentication)——拜候者和被拜候者彼此验证对方的身份。此刻办事器已可以确保客户端是它所传播鼓吹的那么用户,客户端还没有确认它所拜候的不是一个垂钓办事呢。

  为体味决客户端对办事器的验证,办事要需要将解密后的Authenticator再次用Service Session Key进行加密,并阐扬给客户端。客户端再用缓存的Service Session Key进行解密,假定和之前的内容完全一样,则可以证实本身正在拜候的办事器和本身具有不异的Service Session Key,而这个会话秘钥不为外人知晓(以上的内容对应流程图中的步调5、6)

  以上的内容仅仅讲述的是基于Kerberos的Windows认证的大年夜体流程,其实不触及到一些细节的东西,好比若何确保时候的同步,若何抵抗Replay Attack等。别的,因为本文对Windows底层的常识有限,不克不及确保所有的内容都是完全准确,如有弊端,还往不吝斧正。

------分隔线----------------------------

推荐内容