目前在防火墙上提供了几种认证方法

用户是指访问网络资源的主提，表示“谁”在进行访问，是网络访问行为的重要标识。

用户分类：

上网用户

内部网络中访问网络资源的主体，如企业总部的内部员工。上网用户可以直接通过FW访问网络资源。

接入用户

外部网络中访问网络资源的主体，如企业的分支机构员工和出差员工。接入用户需要先通过SSL ***、L2TP ***、IPSec ***或PPPoE方式接入到FW，然后才能访问企业总部的网络资源。

管理用户

认证分类：

防火墙通过认证来验证访问者的身份，防火墙对访问正进行的认证方式有：

本地认证

访问者通过Portal认证页面将标识其身份的用户名和密码发送给FW，FW上存储了密码，验证过程在FW上进行，该方式称为本地认证。

服务器认证（Radius，LDAP等）

访问者通过Portal认证页面将标识其身份的用户名和密码发送给FW，FW上没有存储密码，FW将用户名和密码发送至第三方认证服务器，验证过程在认证服务器上进行，该方式称为服务器认证。

RADIUS（Remote Authentication Dial In User Service）、HWTACACS（HuaWei Terminal Access Controller Access Control System）、AD、LDAP（Lightweight Directory Access Protocol）认证服务器，并在认证服务器上存储了用户/组和密码等信息。对于RADIUS、HWTACACS服务器，管理员需要根据现有的组织结构，在FW上手动创建或者使用文件批量导入相应的用户/组。对于AD或LDAP服务器，管理员可以将AD或LDAP服务器中的用户信息导入到FW上，以便后续管理员可以在FW上通过策略来控制不同用户/组对网络的访问行为。

单点登录

访问者将标识其身份的用户名和密码发送给第三方认证服务器，认证通过后，第三方认证服务器将访问者的身份信息发送给FW。FW只记录访问者的身份信息不参与认证过程，该方式称为单点登录（Single Sign-On）。

短信认证

访问者通过Portal认证页面获取短信验证码，然后输入短信验证码即通过认证。FW通过校验短信验证码认证访问者。

认证的目的：

在FW上部署用户管理与认证，将网络流量的IP地址识别为用户，为网络行为控制和网络权限分配提供了基于用户的管理维度，实现精细化的管理：

基于用户进行策略的可视化制定，提高策略的易用性。基于用户进行威胁、流量的报表查看和统计分析，实现对用户网络访问行为的追踪审计。解决了IP地址动态变化带来的策略控制问题，即以不变的用户应对变化的IP地址。上网用户访问网络的认证方式：

免认证：

FW通过识别IP/MAC和用户的双向绑定关系，确定访问者的身份。进行免认证的访问者只能使用特定的IP/MAC地址来访问网络资源。

会话认证：

当用户访问HTTP业务时，FW向用户推送认证页面，触发身份认证。

一般指的都是本地认证） ----内置Portal认证

先发起HTTP/HTTPS业务访问-------防火墙推送重定向认证页面-----------客户输入用户名和密码----------认证成功，如果设置跳转到最近的页面，就跳转。如果没有设置跳转，就不跳转

事前认证

当用户访问非HTTP业务时，只能主动访问认证页面进行身份认证。

单点认证

AD单点登录：企业已经部署了AD（Active Directory）身份验证机制，AD服务器上存储了用户/组和密码等信息。管理员可以将AD服务器上的组织结构和账号信息导入到FW。对于AD服务器上新创建的用户信息，还可以按照一定的时间间隔定时导入。以便后续管理员可以在FW上通过策略来控制不同用户/组对网络的访问行为。

认证时，由AD服务器对访问者进行认证，并将认证信息发送至FW，使FW能够获取用户与IP地址的对应关系。访问者通过AD服务器的认证后，就可以直接访问网络资源，无需再由FW进行认证，这种认证方式也称为“AD单点登录”。

Agile Controller单点登录

RADIUS单点登录

RADIUS认证原理：

图：旁路模式下RADIUS单点登录示意图

RADIUS单点登录交互过程如下:

访问者向接入设备NAS发起认证请求。

NAS设备转发认证请求到RADIUS服务器，RADIUS服务器对用户账号和密码进行校验，并将认证通过的结果返回给NAS设备。NAS设备向RADIUS服务器发送计费开始报文，标识用户上线。

FW解析计费开始报文获取用户和IP地址的对应关系，同时在本地生成在线用户信息。不同部署方式，FW获取计费开始报文的方式不同：

直路：FW直接对经过自身的RADIUS计费开始报文进行解析。

旁路：NAS设备向RADIUS服务器发送计费开始报文的同时还会向FW发送一份，FW对计费开始报文进行解析并对NAS设备做出应答。

此种部署方式需要NAS设备支持向FW发送计费开始报文的功能。

镜像引流：NAS设备和RADIUS服务器之间交互的计费开始报文不经过FW，需要通过交换机镜像或分光器分光的方式复制一份计费开始报文到FW。FW对计费开始报文进行解析后丢弃。

访问者注销时，NAS设备向RADIUS服务器发送计费结束报文，标识用户下线。FW获取计费结束报文并解析用户和IP对应关系，然后删除本地保存的在线用户信息，完成注销过程。

另外在用户在线期间，NAS设备还会定时向RADIUS服务器发送计费更新报文维持计费过程，FW获取计费更新报文后将刷新在线用户的剩余时间。

接入用户访问网络资源的认证方式：

使用SSL *** 技术

访问者登录SSL ***模块提供的认证页面来触发认证过程，认证完成后，SSL ***接入用户可以访问总部的网络资源。

使用IPSec ***技术

分支机构与总部建立IPSec ***隧道后，分支机构中的访问者可以使用事前认证、会话认证等方式触发认证过程，认证完成后，IPSec ***接入用户可以访问总部的网络资源。

L2TP ***接入用户

用户认证原理用户组织结构：

用户是网络访问的主体，是FW进行网络行为控制和网络权限分配的基本单元。

认证域：用户组织结构的容器。区分用户，起到分流作用

用户组/用户：分为： 父用户组 子用户组 。

注意：一个子用户组只能属于一个父用户组

用户： 必配： 用户名 密码，其它都可以可选

用户属性：账号有效期 允许多人登录 IP/MAC绑定（不绑定 单向 双向）

安全组：横向组织结构的跨部门群组。指跨部门的用户

规划树形组织结构时必须遵循如下规定：default认证域是设备默认自带的认证域，不能被删除，且名称不能被修改。设备最多支持20层用户结构，包括认证域和用户，即认证域和用户之间最多允许存在18层用户组。每个用户组可以包括多个用户和用户组，但每个用户组只能属于一个父用户组。一个用户只能属于一个父用户组。用户组名允许重名，但所在组织结构的全路径必须确保唯一性。用户和用户组都可以被策略所引用，如果用户组被策略引用，则用户组下的用户继承其父组和所有上级节点的策略。用户、用户组、安全的来源：手动配置CSV格式导入（批量导入）服务器导入设备自动发现并创建在线用户：

用户访问网络资源前，首先需要经过FW的认证，目的是识别这个用户当前在使用哪个IP地址。对于通过认证的用户，FW还会检查用户的属性（用户状态、账号过期时间、IP/MAC地址绑定、是否允许多人同时使用该账号登录），只有认证和用户属性检查都通过的用户，该用户才能上线，称为在线用户。

FW上的在线用户表记录了用户和该用户当前所使用的地址的对应关系，对用户实施策略，也就是对该用户对应的IP地址实施策略。

用户上线后，如果在线用户表项超时时间内（缺省30分钟）没有发起业务流量，则该用户对应的在线用户监控表项将被删除。当该用户下次再发起业务访问时，需要重新进行认证。

管理员可以配置在线用户信息同步，查看到已经通过认证的在线用户，并进行强制注销、全部强制注销、冻结和解冻操作。

用户认证总体流程：

图：认证流程示意图认证策略:

认证策略用于决定FW需要对哪些数据流进行认证，匹配认证策略的数据流必须经过FW的身份认证才能通过。

缺省情况下，FW不对经过自身的数据流进行认证，需要通过认证策略选出需要进行认证的数据流。

如果经过FW的流量匹配了认证策略将触发如下动作：

会话认证：访问者访问HTTP业务时，如果数据流匹配了认证策略，FW会推送认证页面要求访问者进行认证。事前认证：访问者访问非HTTP业务时必须主动访问认证页面进行认证，否则匹配认证策略的业务数据流访问将被FW禁止。免认证：访问者访问业务时，如果匹配了免认证的认证策略，则无需输入用户名、密码直接访问网络资源。FW根据用户与IP/MAC地址的绑定关系来识别用户。单点登录：单点登录用户上线不受认证策略控制，但是用户业务流量必须匹配认证策略才能基于用户进行策略管控。

认证匹配依据：

源安全区域、目的安全区域、源地址/地区、目的地址/地区。

注意：认证策略在匹配是遵循从上往下的匹配策略。

缺省情况下，FW通过8887端口提供内置的本地Portal认证页面，用户可以主动访问或HTTP重定向至认证页面（https://接口IP地址:8887）进行本地Portal认证。

在线用户信息同步功能的服务端口，缺省值是8886。

用户认证配置思路会话认证配置思路：第一步： 基本配置（通信正常） 第二步：新建用户（供本地认证使用） 第三步：认证选项设置重定向跳转到最近的页面 注意：要点应用 第四步：默认重定向的认证端口为8887，需要放行安全策略 ip service-set authro_port type object service 0 protocol tcp source-port 0 to 65535 destination-port 8887 sec-policy rule name trust_loacl source-zone trust destination-zone local service authro_port action permit 第五步：配置认证策略 auth-policy rule name trust_untrust source-zone trust destination-zone untrust source-address 10110 mask 2552552550 action auth -------------------默认不认证，修改为认证 第六步：检查 成功以后必须要有在线用户 12345678910111213141516171819202122232425262728291234567891011121314151617181920212223242526272829免认证配置思路：配置： auth-policy rule name no_auth source-zone trust destination-zone untrust source-address 10112 mask 255255255255 action no-auth 12345671234567AD单点登录配置流程：

插件

Server服务器部分

第一步：安装AD域

第二步：安装DNS服务器----配置转发器

第三步：下载AD SSO（在防火墙下载）

第四步：AD域新建组织单元，新建组，新建用户（关联权限）

第五步：PC 加域（DNS修改为服务器地址）

第六步：安装AD SSO (建议安装二次AD SSO）

联动AD域联动FW

第七步：组策略配置登录和注销脚本

调用AD SSO产生的login

格式;

服务器地址 运行端口（AD SSO是一样） 0/1 设置密钥（Huawei@123）

第八步：PC刷新组策略

防火墙部分

第一步：新建防火墙与AD服务器联动

第二步：新建认证域

第三步：把AD服务器用户导入FW ，新建导入策略

第四步： 修改认证域新用户，新用户调用导入策略

第五步：导入用户，到用户列表检查

第六步：配置认证策略

Trust区域到服务器区域（DMZ）不能做认证

第七步：配置安全策略，匹配条件只能是AD域的用户

注意：

FW本地到AD服务器的安全策略

AD服务器到FW本地安全策略

DNS的策略

检查：

一定要看到在线用户-----采用单点登录

参考文档：华为HedEx防火墙文档。

DN：Distinguished Name，可以叫做条目区分名。在一个目录中这个名称总是唯一的，也是用来标识一个节点的主要方式。它有若干属性：

1、CN=CommonName 为用户名或服务器名，最长可以到80个字符，可以为中文；

2、OU=OrganizationUnit为组织单元，最多可以有四级，每级最长32个字符，可以为中文；

3、DC= DomainComponent 为目录结构

4、O=Organization为组织名，可选，可以3—64个字符长

5、C=Country为国家名，可选，为2个字符长

LDAP（轻量级目录访问协议，Lightweight Directory Access Protocol)是实现提供被称为目录服务的信息服务。目录服务是一种特殊的数据库系统，其专门针对读取，浏览和搜索操作进行了特定的优化。目录一般用来包含描述性的，基于属性的信息并支持精细复杂的过滤能力。目录一般不支持通用数据库针对大量更新操作操作需要的复杂的事务管理或回卷策略。而目录服务的更新则一般都非常简单。这种目录可以存储包括个人信息、web链结、jpeg图像等各种信息。为了访问存储在目录中的信息，就需要使用运行在TCP/IP 之上的访问协议—LDAP。

LDAP目录中的信息是是按照树型结构组织，具体信息存储在条目(entry)的数据结构中。条目相当于关系数据库中表的记录；条目是具有区别名DN （Distinguished Name）的属性（Attribute），DN是用来引用条目的，DN相当于关系数据库表中的关键字（Primary Key）。属性由类型（Type）和一个或多个值（Values）组成，相当于关系数据库中的字段（Field）由字段名和数据类型组成，只是为了方便检索的需要，LDAP中的Type可以有多个Value，而不是关系数据库中为降低数据的冗余性要求实现的各个域必须是不相关的。LDAP中条目的组织一般按照地理位置和组织关系进行组织，非常的直观。LDAP把数据存放在文件中，为提高效率可以使用基于索引的文件数据库，而不是关系数据库。类型的一个例子就是mail，其值将是一个电子邮件地址。

LDAP的信息是以树型结构存储的，在树根一般定义国家(c=CN)或域名(dc=com)，在其下则往往定义一个或多个组织 (organization)(o=Acme)或组织单元(organizational units) (ou=People)。一个组织单元可能包含诸如所有雇员、大楼内的所有打印机等信息。此外，LDAP支持对条目能够和必须支持哪些属性进行控制，这是有一个特殊的称为对象类别(objectClass)的属性来实现的。该属性的值决定了该条目必须遵循的一些规则，其规定了该条目能够及至少应该包含哪些属性。例如：inetorgPerson对象类需要支持sn(surname)和cn(common name)属性，但也可以包含可选的如邮件，电话号码等属性。

什么是LDAP

LDAP的英文全称是Lightweight Directory Access Protocol，一般都简称为LDAP。它是基于X500标准的，

但是简单多了并且可以根据需要定制。与X500不同，LDAP支持TCP/IP，这对访问Internet是必须的。LDAP

的核心规范在RFC中都有定义，所有与LDAP相关的RFC都可以在LDAPman RFC网页中找到。现在LDAP技术不仅

发展得很快而且也是激动人心的。在企业范围内实现LDAP可以让运行在几乎所有计算机平台上的所有的应

用程序从LDAP目录中获取信息。LDAP目录中可以存储各种类型的数据：电子邮件地址、邮件路由信息、人力

资源数据、公用密匙、联系人列表，等等。通过把LDAP目录作为系统集成中的一个重要环节，可以简化员工

在企业内部查询信息的步骤，甚至连主要的数据源都可以放在任何地方。

LDAP目录的优势

如果需要开发一种提供公共信息查询的系统一般的设计方法可能是采用基于WEB的数据库设计方式，即前端

使用浏览器而后端使用WEB服务器加上关系数据库。后端在Windows的典型实现可能是Windows NT + IIS + Acess

数据库或者是SQL服务器，IIS和数据库之间通过ASP技术使用ODBC进行连接，达到通过填写表单查询数据的功能；

后端在Linux系统的典型实现可能是Linux+ Apache + postgresql，Apache和数据库之间通过PHP3提供的函数进

行连接。使用上述方法的缺点是后端关系数据库的引入导致系统整体的性能降低和系统的管理比较繁琐，因为需

要不断的进行数据类型的验证和事务的完整性的确认；并且前端用户对数据的控制不够灵活，用户权限的设置一

般只能是设置在表一级而不是设置在记录一级。

目录服务的推出主要是解决上述数据库中存在的问题。目录与关系数据库相似，是指具有描述性的基于属性的记

录集合，但它的数据类型主要是字符型，为了检索的需要添加了BIN（二进制数据）、CIS（忽略大小写）、CES

（大小写敏感）、TEL（电话型）等语法（Syntax），而不是关系数据库提供的整数、浮点数、日期、货币等类型，

同样也不提供象关系数据库中普遍包含的大量的函数，它主要面向数据的查询服务（查询和修改操作比一般是大于

10:1），不提供事务的回滚（rollback）机制，它的数据修改使用简单的锁定机制实现All-or-Nothing，它的目标

是快速响应和大容量查询并且提供多目录服务器的信息复制功能。

现在该说说LDAP目录到底有些什么优势了。现在LDAP的流行是很多因数共同作用的结果。可能LDAP最大的优势是：

可以在任何计算机平台上，用很容易获得的而且数目不断增加的LDAP的客户端程序访问LDAP目录。而且也很容易

定制应用程序为它加上LDAP的支持。

LDAP协议是跨平台的和标准的协议，因此应用程序就不用为LDAP目录放在什么样的服务器上操心了。实际上，LDAP

得到了业界的广泛认可，因为它是Internet的标准。产商都很愿意在产品中加入对LDAP的支持，因为他们根本不用

考虑另一端（客户端或服务端）是怎么样的。LDAP服务器可以是任何一个开发源代码或商用的LDAP目录服务器（或

者还可能是具有LDAP界面的关系型数据库），因为可以用同样的协议、客户端连接软件包和查询命令与LDAP服务器

进行交互。与LDAP不同的是，如果软件产商想在软件产品中集成对DBMS的支持，那么通常都要对每一个数据库服务

器单独定制。不象很多商用的关系型数据库，你不必为LDAP的每一个客户端连接或许可协议付费 大多数的LDAP服务

器安装起来很简单，也容易维护和优化。

LDAP服务器可以用“推”或“拉”的方法复制部分或全部数据，例如：可以把数据“推”到远程的办公室，以增加

数据的安全性。复制技术是内置在LDAP服务器中的而且很容易配置。如果要在DBMS中使用相同的复制功能，数据库

产商就会要你支付额外的费用，而且也很难管理。

LDAP允许你根据需要使用ACI（一般都称为ACL或者访问控制列表）控制对数据读和写的权限。例如，设备管理员可

以有权改变员工的工作地点和办公室号码，但是不允许改变记录中其它的域。ACI可以根据谁访问数据、访问什么数

据、数据存在什么地方以及其它对数据进行访问控制。因为这些都是由LDAP目录服务器完成的，所以不用担心在客

户端的应用程序上是否要进行安全检查。

LDAP（Lightweight Directory Acess Protocol）是目录服务在TCP/IP上的实现（RFC 1777 V2版和RFC 2251

V3版）。它是对X500的目录协议的移植，但是简化了实现方法，所以称为轻量级的目录服务。在LDAP中目录是按照

树型结构组织，目录由条目（Entry）组成，条目相当于关系数据库中表的记录；条目是具有区别名DN（Distinguished

Name）的属性（Attribute）集合，DN相当于关系数据库表中的关键字（Primary

Key）；属性由类型（Type）和多个值（Values）组成，相当于关系数据库中的域（Field）由域名和数据类型组成，

只是为了方便检索的需要，LDAP中的Type可以有多个Value，而不是关系数据库中为降低数据的冗余性要求实现的各

个域必须是不相关的。LDAP中条目的组织一般按照地理位置和组织关系进行组织，非常的直观。LDAP把数据存放在

文件中，为提高效率可以使用基于索引的文件数据库，而不是关系数据库。LDAP协议集还规定了DN的命名方法、存

取控制方法、搜索格式、复制方法、URL格式、开发接口等

LDAP对于这样存储这样的信息最为有用，也就是数据需要从不同的地点读取，但是不需要经常更新。

例如，这些信息存储在LDAP目录中是十分有效的：

l 公司员工的电话号码簿和组织结构图

l 客户的联系信息

l 计算机管理需要的信息，包括NIS映射、email假名，等等

l 软件包的配置信息

l 公用证书和安全密匙

什么时候该用LDAP存储数据

大多数的LDAP服务器都为读密集型的操作进行专门的优化。因此，当从LDAP服务器中读取数据的时候会比从专门为

OLTP优化的关系型数据库中读取数据快一个数量级。也是因为专门为读的性能进行优化，大多数的LDAP目录服务器

并不适合存储需要需要经常改变的数据。例如，用LDAP服务器来存储电话号码是一个很好的选择，但是它不能作为

电子商务站点的数据库服务器。

如果下面每一个问题的答案都是“是”，那么把数据存在LDAP中就是一个好主意。

l 需要在任何平台上都能读取数据吗？

l 每一个单独的记录项是不是每一天都只有很少的改变？

l 可以把数据存在平面数据库（flat database）而不是关系型数据库中吗？换句话来说，也就是不管什么范式不

范式的，把所有东西都存在一个记录中（差不多只要满足第一范式）。

最后一个问题可能会唬住一些人，其实用平面数据库去存储一些关系型的数据也是很一般的。例如，一条公司员工

的记录就可以包含经理的登录名。用LDAP来存储这类信息是很方便的。一个简单的判断方法：如果可以把保数据存

在一张张的卡片里，就可以很容易地把它存在LDAP目录里。

安全和访问控制

LDAP提供很复杂的不同层次的访问控制或者ACI。因这些访问可以在服务器端控制，这比用客户端的软件保证数据的

安全可安全多了。

用LDAP的ACI，可以完成：

l 给予用户改变他们自己的电话号码和家庭地址的权限，但是限制他们对其它数据（如，职务名称，经理的登录名，

等等）只有“只读”权限。

l 给予“HR-admins"组中的所有人权限以改变下面这些用户的信息：经理、工作名称、员工号、部门名称和部门号。

但是对其它域没有写权限。

l 禁止任何人查询LDAP服务器上的用户口令，但是可以允许用户改变他或她自己的口令。

l 给予经理访问他们上级的家庭电话的只读权限，但是禁止其他人有这个权限。

l 给予“host-admins"组中的任何人创建、删除和编辑所有保存在LDAP服务器中的与计算机主机有关的信息

l 通过Web，允许“foobar-sales"组中的成员有选择地给予或禁止他们自己读取一部分客户联系数据的读权限。这

将允许他们把客户联系信息下载到本地的笔记本电脑或个人数字助理（PDA）上。（如果销售人员的软件都支持LDAP，

这将非常有用）

l 通过Web，允许组的所有者删除或添加他们拥有的组的成员。例如：可以允许销售经理给予或禁止销售人员改变Web

页的权限。也可以允许邮件假名（mail aliase）的所有者不经过IT技术人员就直接从邮件假名中删除或添加用户。

“公用”的邮件列表应该允许用户从邮件假名中添加或删除自己（但是只能是自己）。也可以对IP地址或主机名加以

限制。例如，某些域只允许用户IP地址以192168200开头的有读的权限，或者用户反向查找DNS得到的主机名必须

为foobarcom。

LDAP目录树的结构

LDAP目录以树状的层次结构来存储数据。如果你对自顶向下的DNS树或UNIX文件的目录树比较熟悉，也就很容易掌握

LDAP目录树这个概念了。就象DNS的主机名那样，LDAP目录记录的标识名（Distinguished Name，简称DN）是用来读取

单个记录，以及回溯到树的顶部。后面会做详细地介绍。

为什么要用层次结构来组织数据呢？原因是多方面的。下面是可能遇到的一些情况：

l 如果你想把所有的美国客户的联系信息都“推”到位于到西雅图办公室（负责营销）的LDAP服务器上，但是你不想

把公司的资产管理信息“推”到那里。

l 你可能想根据目录树的结构给予不同的员工组不同的权限。在下面的例子里，资产管理组对“asset-mgmt"部分有完

全的访问权限，但是不能访问其它地方。

l 把LDAP存储和复制功能结合起来，可以定制目录树的结构以降低对WAN带宽的要求。位于西雅图的营销办公室需要每

分钟更新的美国销售状况的信息，但是欧洲的销售情况就只要每小时更新一次就行了。

刨根问底：基准DN

LDAP目录树的最顶部就是根，也就是所谓的“基准DN"。基准DN通常使用下面列出的三种格式之一。假定我在名为FooBar

的电子商务公司工作，这家公司在Internet上的名字是foobarcom。

o="FooBar, Inc", c=US

（以X500格式表示的基准DN）

在这个例子中，o=FooBar, Inc 表示组织名，在这里就是公司名的同义词。c=US 表示公司的总部在美国。以前，一般

都用这种方式来表示基准DN。但是事物总是在不断变化的，现在所有的公司都已经（或计划）上Internet上。随着

Internet的全球化，在基准DN中使用国家代码很容易让人产生混淆。现在，X500格式发展成下面列出的两种格式。

o=foobarcom

（用公司的Internet地址表示的基准DN）

这种格式很直观，用公司的域名作为基准DN。这也是现在最常用的格式。

dc=foobar, dc=com

（用DNS域名的不同部分组成的基准DN）

就象上面那一种格式，这种格式也是以DNS域名为基础的，但是上面那种格式不改变域名（也就更易读），而这种格式

把域名：foobarcom分成两部分 dc=foobar, dc=com。在理论上，这种格式可能会更灵活一点，但是对于最终用户来说

也更难记忆一点。考虑一下foobarcom这个例子。当foobarcom和gizmocom合并之后，可以简单的把“dc=com"当作基

准DN。把新的记录放到已经存在的dc=gizmo, dc=com目录下，这样就简化了很多工作（当然，如果foobarcom和wocketedu

合并，这个方法就不能用了）。如果LDAP服务器是新安装的，我建议你使用这种格式。再请注意一下，如果你打算使用活动

目录（Actrive Directory），Microsoft已经限制你必须使用这种格式。

更上一层楼：在目录树中怎么组织数据

在UNIX文件系统中，最顶层是根目录（root）。在根目录的下面有很多的文件和目录。象上面介绍的那样，LDAP目录也是

用同样的方法组织起来的。

在根目录下，要把数据从逻辑上区分开。因为历史上（X500）的原因，大多数LDAP目录用OU从逻辑上把数据分开来。OU

表示“Organization Unit"，在X500协议中是用来表示公司内部的机构：销售部、财务部，等等。现在LDAP还保留ou=这

样的命名规则，但是扩展了分类的范围，可以分类为：ou=people, ou=groups, ou=devices，等等。更低一级的OU有时用

来做更细的归类。例如：LDAP目录树（不包括单独的记录）可能会是这样的：

dc=foobar, dc=com

ou=customers

ou=asia

ou=europe

ou=usa

ou=employees

ou=rooms

ou=groups

ou=assets-mgmt

ou=nisgroups

ou=recipes

单独的LDAP记录

DN是LDAP记录项的名字

在LDAP目录中的所有记录项都有一个唯一的“Distinguished Name"，也就是DN。每一个LDAP记录项的DN是由两个部分

组成的：相对DN（RDN）和记录在LDAP目录中的位置。

RDN是DN中与目录树的结构无关的部分。在LDAP目录中存储的记录项都要有一个名字，这个名字通常存在cn（Common Name）

这个属性里。因为几乎所有的东西都有一个名字，在LDAP中存储的对象都用它们的cn值作为RDN的基础。如果我把最喜欢的

吃燕麦粥食谱存为一个记录，我就会用cn=Oatmeal Deluxe作为记录项的RDN。

l 我的LDAP目录的基准DN是dc=foobar,dc=com

l 我把自己的食谱作为LDAP的记录项存在ou=recipes

l 我的LDAP记录项的RDN设为cn=Oatmeal Deluxe

上面这些构成了燕麦粥食谱的LDAP记录的完整DN。记住，DN的读法和DNS主机名类似。下面就是完整的DN：

cn=Oatmeal Deluxe,ou=recipes,dc=foobar,dc=com

举一个实际的例子来说明DN

现在为公司的员工设置一个DN。可以用基于cn或uid（User ID），作为典型的用户帐号。例如，FooBar的员工Fran Smith

（登录名：fsmith）的DN可以为下面两种格式：

uid=fsmith,ou=employees,dc=foobar,dc=com

（基于登录名）

LDAP（以及X500）用uid表示“User ID"，不要把它和UNIX的uid号混淆了。大多数公司都会给每一个员工唯一的登录名，

因此用这个办法可以很好地保存员工的信息。你不用担心以后还会有一个叫Fran Smith的加入公司，如果Fran改变了她的

名字（结婚？离婚？或宗教原因？），也用不着改变LDAP记录项的DN。

cn=Fran Smith,ou=employees,dc=foobar,dc=com

（基于姓名）

可以看到这种格式使用了Common Name（CN）。可以把Common Name当成一个人的全名。这种格式有一个很明显的缺点就是：

如果名字改变了，LDAP的记录就要从一个DN转移到另一个DN。但是，我们应该尽可能地避免改变一个记录项的DN。

定制目录的对象类型

你可以用LDAP存储各种类型的数据对象，只要这些对象可以用属性来表示，下面这些是可以在LDAP中存储的一些信息：

l 员工信息：员工的姓名、登录名、口令、员工号、他的经理的登录名，邮件服务器，等等。

l 物品跟踪信息：计算机名、IP地址、标签、型号、所在位置，等等。

l 客户联系列表：客户的公司名、主要联系人的电话、传真和电子邮件，等等。

l 会议厅信息：会议厅的名字、位置、可以坐多少人、电话号码、是否有投影机。

l 食谱信息：菜的名字、配料、烹调方法以及准备方法。

因为LDAP目录可以定制成存储任何文本或二进制数据，到底存什么要由你自己决定。LDAP目录用对象类型

（object classes）的概念来定义运行哪一类的对象使用什么属性。在几乎所有的LDAP服务器中，你都要根据

自己的需要扩展基本的LDAP目录

的功能，创建新的对象类型或者扩展现存的对象类型。

LDAP目录以一系列“属性对”的形式来存储记录项，每一个记录项包括属性类型和属性值（这与关系型数据库

用行和列来存取数据有根本的不同）。下面是我存在LDAP目录中的一部分食谱记录：

dn: cn=Oatmeal Deluxe, ou=recipes, dc=foobar, dc=com

cn: Instant Oatmeal Deluxe

recipeCuisine: breakfast

recipeIngredient: 1 packet instant oatmeal

recipeIngredient: 1 cup water

recipeIngredient: 1 pinch salt

recipeIngredient: 1 tsp brown sugar

recipeIngredient: 1/4 apple, any type

请注意上面每一种配料都作为属性recipeIngredient值。LDAP目录被设计成象上面那样为一个属性保存多个值的，

而不是在每一个属性的后面用逗号把一系列值分开。

因为用这样的方式存储数据，所以数据库就有很大的灵活性，不必为加入一些新的数据就重新创建表和索引。更

重要的是，LDAP目录不必花费内存或硬盘空间处理“空”域，也就是说，实际上不使用可选择的域也不会花费你

任何资源。

作为例子的一个单独的数据项

让我们看看下面这个例子。我们用Foobar, Inc的员工Fran Smith的LDAP记录。这个记录项的格式是LDIF，用来

导入和导出LDAP目录的记录项。

dn: uid=fsmith, ou=employees, dc=foobar, dc=com

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

objectclass: foobarPerson

uid: fsmith

givenname: Fran

sn: Smith

cn: Fran Smith

cn: Frances Smith

telephonenumber: 510-555-1234

roomnumber: 122G

o: Foobar, Inc

mailRoutingAddress: fsmith@foobarcom

mailhost: mailfoobarcom

userpassword: 3x1231v76T89N

uidnumber: 1234

gidnumber: 1200

homedirectory: /home/fsmith

loginshell: /usr/local/bin/bash

属性的值在保存的时候是保留大小写的，但是在默认情况下搜索的时候是不区分大小写的。某些特殊的属性

（例如，password）在搜索的时候需要区分大小写。

让我们一点一点地分析上面的记录项。

dn: uid=fsmith, ou=employees, dc=foobar, dc=com

这是Fran的LDAP记录项的完整DN，包括在目录树中的完整路径。LDAP（和X500）使用uid（User ID），不要

把它和UNIX的uid号混淆了。

objectclass: person

objectclass: organizationalPerson

objectclass: inetOrgPerson

objectclass: foobarPerson

可以为任何一个对象根据需要分配多个对象类型。person对象类型要求cn（common name）和sn（surname）

这两个域不能为空。persion对象类型允许有其它的可选域，包括givenname、telephonenumber，等等。

organizational Person给person加入更多的可选域，inetOrgPerson又加入更多的可选域（包括电子邮件信息）。

最后，foobarPerson是为Foobar定制的对象类型，加入了很多定制的属性。

uid: fsmith

givenname: Fran

sn: Smith

cn: Fran Smith

cn: Frances Smith

telephonenumber: 510-555-1234

roomnumber: 122G

o: Foobar, Inc

以前说过了，uid表示User ID。当看到uid的时候，就在脑袋里想一想“login"。

请注意CN有多个值。就象上面介绍的，LDAP允许某些属性有多个值。为什么允许有多个值呢？假定你在用

公司的LDAP服务器查找Fran的电话号码。你可能只知道她的名字叫Fran，但是对人力资源处的人来说她的

正式名字叫做Frances。因为保存了她的两个名字，所以用任何一个名字检索都可以找到Fran的电话号码、

电子邮件和办公房间号，等等。

mailRoutingAddress: fsmith@foobarcom

mailhost: mailfoobarcom

就象现在大多数的公司都上网了，Foobar用Sendmail发送邮件和处理外部邮件路由信息。Foobar把所有用户

的邮件信息都存在LDAP中。最新版本的Sendmail支持这项功能。

Userpassword: 3x1231v76T89N

uidnumber: 1234

gidnumber: 1200

gecos: Frances Smith

homedirectory: /home/fsmith

loginshell: /usr/local/bin/bash

注意，Foobar的系统管理员把所有用户的口令映射信息也都存在LDAP中。FoobarPerson类型的对象具有这

种能力。再注意一下，用户口令是用UNIX的口令加密格式存储的。UNIX的uid在这里为uidnumber。提醒你一下，

关于如何在LDAP中保存NIS信息，有完整的一份RFC。在以后的文章中我会谈一谈NIS的集成。

LDAP复制

LDAP服务器可以使用基于“推”或者“拉”的技术，用简单或基于安全证书的安全验证，复制一部分或者所

有的数据。

例如，Foobar有一个“公用的”LDAP服务器，地址为ldapfoobarcom，端口为389。Netscape Communicator

的电子邮件查询功能、UNIX的“ph"命令要用到这个服务器，用户也可以在任何地方查询这个服务器上的员工

和客户联系信息。公司的主LDAP服务器运行在相同的计算机上，不过端口号是1389。

你可能即不想让员工查询资产管理或食谱的信息，又不想让信息技术人员看到整个公司的LDAP目录。为了解决

这个问题，Foobar有选择地把子目录树从主LDAP服务器复制到“公用”LDAP服务器上，不复制需要隐藏的信息。

为了保持数据始终是最新的，主目录服务器被设置成即时“推”同步。这些种方法主要是为了方便，而不是安全，

因为如果有权限的用户想查询所有的数据，可以用另一个LDAP端口。

假定Foobar通过从奥克兰到欧洲的低带宽数据的连接用LDAP管理客户联系信息。可以建立从ldapfoobarcom:1389

到munich-ldapfoobarcom:389的数据复制，象下面这样：

periodic pull: ou=asia,ou=customers,o=sendmailcom

periodic pull: ou=us,ou=customers,o=sendmailcom

immediate push: ou=europe,ou=customers,o=sendmailcom

“拉”连接每15分钟同步一次，在上面假定的情况下足够了。“推”连接保证任何欧洲的联系信息发生了变化就

立即被“推”到Munich。

用上面的复制模式，用户为了访问数据需要连接到哪一台服务器呢？在Munich的用户可以简单地连接到本地服务

器。如果他们改变了数据，本地的LDAP服务器就会把这些变化传到主LDAP服务器。然后，主LDAP服务器把这些变化

“推”回本地的“公用”LDAP服务器保持数据的同步。这对本地的用户有很大的好处，因为所有的查询（大多数是读）都在本地的服务器上进行，速度非常快。当需要改变信息的时候，最终用户不需要重新配置客户端的软件，因为LDAP目录服务器为他们完成了所有的数据交换工作。

目录服务：LDAP服务器，一种轻量级的目录访问控制协议上

活动目录：windows activity directory 基于LDAP协议实现的一个软件，此类软件还有OPEN LDAP

域：将公司资源包括电脑，文件服务器，打印机等整合在一起，用统一的账号名来控制这些资源

OU：组织单位，一般是公司的组织架构的体现,是一个容器

安全组：安全组主要用来进行权限分配，也能作为信息分发，根据所属组的员工的共有特性来进行划分，例如性别、在一个Office、一个Team、从事相同的工作等等。

LDAP是轻量目录访问协议，英文全称是Lightweight Directory Access Protocol，一般都简称为LDAP。它是基于X500标准的，但是简单得多并且可以根据需要定制。

LDAP由互联网工程任务组（IETF）的文档RFC定义，使用了描述语言ASN1定义。最新的版本是版本3，由RFC 4511所定义。例如，一个用语言描述的LDAP的搜索如：“在公司邮件目录中搜索公司位于那什维尔名字中含有“Jessy”的有邮件地址的所有人。请返回他们的全名，电子邮件，头衔和简述。”

扩展资料：

LDAP-开发方式

如果需要开发一种提供公共信息查询的系统一般的设计方法可能是采用基于WEB的数据库设计方式，即前端使用浏览器而后端使用WEB服务器加上关系数据库。后端在Windows的典型实现可能是Windows NT + IIS + Acess数据库或者是SQL SERVER，IIS和数据库之间通过ASP技术使用ODBC进行连接，达到通过填写表单查询数据的功能；

-LDAP

-目录访问协议