活动目录在构建核心过程中的八个关键点(下)-阿里云开发者社区

开发者社区> 安全> 正文

活动目录在构建核心过程中的八个关键点(下)

简介:

5. LDAP协议简介

LDAP的英文全称是Lightweight Directory Access Protocol,简称为LDAP。它是基于X.500标准的,但是又比它简单许多,并且可以根据需要定制的一种目录服务协议。与X.500不 同,LDAP支持TCP/IP,这对访问Internet是必须的。LDAP的核心规范在RFC中都有定义,所有与LDAP相关的RFC都可以在 LDAPman RFC网页中找到。

目录服务的工作模型是客户机/服务器模型。1988年,CCITT组织首先创建了X.500标准全面描述了这一模型,包括目录服务器的目录结构、命 名方法、搜索机制以及用于客户机与服务器通信的协议DAP(Directory Access Protocol)。此标准很快被ISO组织引用,编号为ISO 9594。但是,在实际应用的过程中,X.500存在着不少障碍。由于DAP这种应用层的协议是严格遵照复杂的ISO七层协议模型制定的,对相关层协议环 境要求过多,在许多小系统上无法使用,TCP/IP协议体系的普及更使这种协议越来越不适应需要。在这种情况下,DAP的简化版棗LDAP应运而生。早期 设计的LDAP服务器不是独立的目录服务器,主要扮演LDAP客户机与X.500服务器间网关的角色,既是LDAP的服务器又是X.500的客户机。

如今的LDAP服务器可取代X.500服务器而独立提供服务。LDAP服务器的目录组织以“条目”为基本单位,结构类似树形,每一个条目即是树上的 一个分枝节点或叶子。一个条目由多个“属性”组成,每个属性又由一个“类型”和一到多个“值”组成。LDAP协议直接基于面向连接的TCP协议实现,定义 了LDAP客户机和LDAP服务器间的通信过程和信息格式。LDAP服务器在服务端口(缺省端口号为389)监听,收到客户机的请求后,建立连接,开始会 话。活动目录与DNS协议的结合的意义在于使内部网与外部网命名方式保持一致,这样便于整个网络的管理。

LDAP协议是用于查询和检索活动目录信息的目录访问协议。由于它是基于工业标准的目录服务协议,使用 LDAP 的程序可以发展成与其他目录服务共享活动目录信息,这些目录服务同样支持LDAP。活动目录使用LDAP 目录访问协议作为它与其他应用或者目录服务交换信息的手段。LDAP已经成为 目录服务的标准,它比X.500 DAP 协议更为简单实用一些。Microsoft 已经在Exchange Server 系统中提供了LDAP v2 和LDAP v3 的支持, 在Windows Server的活动目录服务中将提供更为全面的支持。
 

6. AD服务与DNS的关系

DNS(Domain Name Server, 域名服务器)是活动目录的基础。总结来说,AD用于组织资源,DNS用于寻找资源。在活动目录中命名策略基本按照Internet标准来实现,遵照DNS 和LDAP3.0两种标准,活动目录中的域和DNS系统中的域采用完全相同的命名方式,即活动目录中的域名就是DNS域名。那么在活动目录中依赖于DNS 作为定位服务,实现将名字解析为IP地址。

所以构建活动目录时,必须同时安装配置相应的DNS,无论用户实现IP地址解析还是登录验证,都利用DNS在活动目录中定位服务器。活动目录与 DNS系统的这种紧密集成,意味着活动目录同时非常适合于Internet和Intranet环境,这也是微软创建适用于Internet的网络操作系统 的思想的一种体现。企业可以把活动目录直接连接到Internet以简化与客户和合作伙伴之间的信息通讯。

另外,DNS服务允许客户使用DNS动态更新协议(RFC 2136)来动态更新资源记录,通过缩短手工管理这些相同记录的时间,提高DNS管理的性能。运行Windows Server的计算机能动态地注册他们的DNS名称和IP地址。

下图给出了AD与DNS的关系,以及对于域中一台具体的计算机,AD命名与DNS命名的对应关系:

 

7. AD中组策略简介

组策略是Active Directory中非常重要的一项技术。组策略是一个允许执行针对用户或计算机进行配置的基础架构。通俗地说,组策略和注册表类似,是一项可以修改用户 或计算机设置的技术。组策略和注册表的区别主要在于:注册表只能针对一个用户或一台计算机进行设置,但组策略却可以针对多个用户和多台计算机进行设置。举 个例子,在一个拥有1000用户的企业中,如果用注册表来进行配置,可能需要在1000台计算机上分别修改注册表。但如果改用组策略,那只要创建好组策 略,然后通过一个合适的级别部署到1000台计算机上就可以了。

组策略和Active Directory结合使用,可以部署在OU,站点和域的级别上,当然也可以部署在本地计算机上,但部署在本地计算机并不能使用组策略中的全部功能,只有 和Active Directory配合,组策略才可以发挥出全部潜力。组策略部署在不同级别的优先级是不同的,本地计算机<站点<域<OU。管理员可 以根据管理任务,为组策略选择合适的部署级别。

组策略对象存储在两个位置,链接GPO(Group Policy Object)的Active Directory容器和域控制器上的Sysvol文件夹。GPO是组策略设置的集合,是存储在Active Directory中的一个虚拟对象。GPO由组策略容器和组策略模板组成,组策略容器包含GPO的属性信息,存储在域中每台域控制器活动目录中;组策略 模板包含GPO的数据,存储在系统盘的/Policies子目录下。

组策略管理可以通过组策略编辑器和组策略管理控制台,组策略编辑器是Windows操作系统中自带的组策略管理工具,可以修改GPO中的设置。组策 略管理控制台则是功能更强大的组策略编辑工具,组策略管理控制台可以创建,管理,部署GPO,最新的GPMC可以从微软网站下载。
 

8. 基于AD的认证过程

8.1 NTLM认证

NTLM是用于Windows NT和 Windows 2000/2003/2008 Server 工作组环境的身份验证协议。下图给出了NTLM认证的过程,其基本流程如下:

1) 用户请求访问。用户尝试通过提供用户凭据登录到客户端。登录前,客户端计算机缓存密码的哈希值。客户端向服务器发送一个请求,该请求包括用户名以及纯文本格式的请求。

2) 服务器发送质询消息。服务器生成一个称为质询的 16 字节随机数(即 NONCE),并将它发送到客户端。

3) 客户端发送应答消息。客户端使用由用户的密码生成的一个密码哈希值来加密服务器发送的质询。它以应答的形式将这个加密的质询发回到服务器。

4) 服务器将质询和应答发送到域控制器。服务器将用户名、原始质询以及应答从客户端计算机发送到域控制器。

5) 域控制器比较质询和应答以对用户进行身份验证。域控制器获取该用户的密码哈希值,然后使用该哈希值对原始质询进行加密。接下来,域控制器将加密的质询与客户端计算机的应答进行比较。如果匹配,域控制器则发送该用户已经过身份验证的服务器确认。

6) 服务器向客户端发送应答。假定凭据有效,服务器授予对所请求的服务或资源的客户端访问权。

8.2 Kerberos认证

当客户端对网络服务进行身份验证之后,kerberos v5 协议遵循以下步骤:

1) 客户端从 KDC 请求TGT.

用户试图通过提供用户凭据登录到客户端。客户端计算机上的 Kerberos 服务向密钥发行中心(KDC) 发送一个 Kerberos 身份验证服务请求。该请求包含用户名、请求票证授予票证(ticket-granting ticket,TGT)所获取的服务信息,以及使用用户的长期密钥(即密码)加密的时间戳。(在Windows 2000 Server/Windows Server 2003/ Windows Server 2008操作系统上,域控制器充当 KDC,而 Active Directory 宿主安全帐户数据库)

2) 身份验证服务发送加密的

TGT 和会话密钥。KDC 为来自 Active Directory 的用户获取长期密钥(即密码),然后解密随请求一起传送的时间戳。如果该时间戳有效,则用户是真正的用户。KDC 身份验证服务创建一个登录会话密钥,并使用用户的长期密钥对该副本进行加密。然后,该身份验证服务创建一个 TGT,它包括用户信息和登录会话密钥。最后,该身份验证服务使用自己的密钥加密 TGT,并将加密的会话密钥和加密的 TGT 传递给客户端。

3) 客户端从 TGT 请求服务器访问。

客户端使用其长期密钥(即密码)解密登录会话密钥,并在本地缓存它。此外,客户端还将加密的 TGT 存储在它的缓存中。访问网络服务时,客户端向 KDC 票证授予服务(ticket-granting service,TGS)发送一个包含信息的请求,这些信息包括用户名、使用用户登录会话密钥加密的验证者消息、TGT,以及用户想访问的服务(和服务 器)名称。

4) TGS 发送加密的会话密钥和票证。

KDC 上的 TGS 使用自己的密钥解密 KDC 并提取登录会话密钥。它使用该登录会话密钥解密验证者消息(通常是时间戳)。如果验证者消息成功解密,TGS 从 TGT 提取用户信息,并使用用户信息创建一个用于访问该服务的服务会话密钥。它使用该用户的登录会话密钥对该服务会话密钥的一个副本进行加密,创建一个具有服务 会话密钥和用户信息的服务票证,然后使用该服务的长期密钥(密码)对该服务票证进行加密。然后,TGS 将加密的服务会话密钥和服务票证添加到客户端。

5) 客户端发送服务票证。客户端访问服务时,向服务器发送一个请求。该请求包含验证者消息(时间戳),该消息使用服务会话密钥和服务票证进行加密。

6) 服务器发送加密的时间戳以进行客户端验证。

服务器解密服务票证并提取服务会话密钥。通过使用服务会话密钥,服务器解密验证者消息(时间戳)并计算它。如果验证者通过测试,则服务器使用服务会 话密钥对验证者(时间戳)进行加密,然后将验证者传回到客户端。客户端解密时间戳,如果该时间戳与原始时间戳相同,则该服务是真正的,客户端继续连接。





本文转自 149banzhang 51CTO博客,原文链接:http://blog.51cto.com/149banzhang/712704,如需转载请自行联系原作者

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
+ 订阅

云安全开发者的大本营

其他文章