- 论坛徽章:
- 0
|
Planning Your Directory Data -LDAP第二讲
原文：http://www.chinaunix.net/cgi-bin/bbs/topic.cgi?forum=3&topic=19341&show=0
目录数据就是目录服务中所包含的信息。这些数据包括一些公共信息，如用户名称、联系信息(例如电子邮件地址和电话号码)、组标识和组成员关系。目录服务设计工作的很大一部分就是规划目录的内容。
在本章中将介绍与规划目录内容有关的一些问题和策略。这一章将分为如下几部分：
数据规划概述----本节将概要介绍在进行目录内容规划时所执行的一些规划操作。
目录数据简介----本节将介绍在目录中应该包括哪些内容，不应该包括哪些内容。本节还将提供关于适合包含在目录的数据以及不适合包含目录中的数据的一些范例。
数据规划---本节将提供关于如何完成数据规划任务的一些建议。
进行现场调查----本节将介绍关于如何为目录数据进行现场调查的一些建议。
分析现场调查----本节将介绍如何完成目录中的数据管理。其中将介绍数据控制、数据所有权和数据访问等概念。最后，还将提供一些关于如何对现场调查结果和数据分析进行文档记录的一些建议。
数据规划概述
规划目录的数据是目录规划活动中最重要的一方面。因而，应该为数据规划预留足够的时间。你将会花费大量时间对企业进行调查，以了解到管理目录信息的所有数据存储。在进行调查时，需要了解哪种数据管理得不好，哪些进程可能效率不高、不恰当或不存在，以及哪些希望有的数据根本就不存在。所有这些问题都需要在数据规划阶段解决。
数据规划活动应该包括：
确定你想要部署哪些支持目录的应用程序以及它们的数据需求。
调查企业，以了解数据都来自哪些地方(例如NT或Netware目录，PBX系统，人力资源数据库，电子邮件系统等等)。
确定谁需要访问数据。特别地，要注意企业的关键任务应用程序。了解那些应用程序是否能够访问和/或更新目录。
对于所有数据，确定控制数据的位置。
对于所有数据，确定谁拥有这些数据；也就是说，谁负责确保这些数据是最新的。
如果打算从其他来源导入数据，则还需要制订一种用于批量导入和增量更新的策略。作为这条策略的一部分，应该试图在一个位置控制给定数据，并限制可以更改该数据的应用程序数量为一个尽可能少的易于识别的组。这样将有助于确保数据的完整性并在很大程度上减少企业的管理开销。
在管理数据源时，要记住越简单越好的原则。
进行文档记录。
下一节将详细介绍数据规划活动。
目录数据简介
在目录中所包含的数据类型取决于你，但是有些类型的数据比其他一些类型更适合于目录服务；写入操作要比读取操作昂贵得多，因为它们减慢了服务器的性能。
数据必须可以用“属性-数据”格式表示(例如surname=jensen)。
应该有多个应用对数据感兴趣。例如，许多人和应用程序都可能会关心职员的名称或打印机的物理位置。
能够从多个物理位置访问将会很有用。例如，某一个职员对于某一个软件应用程序的参数设置可能不太适合包括在目录中，因为只有一个应用程序需要访问该信息。但是，如果该应用程序能够从目录中读取参数设置，则把参数设置信息包括在目录中将会非常有帮助。这样做可以使得用户能够根据她自己的参数设置与应用程序交互，而不管该用户处于企业内的哪个物理位置。
目录数据范例
下面是一些典型的目录数据范例：
个人联系信息，例如电话号码，家庭地址，以及邮件地址
个人的描述性信息，例如职员编号，工作头衔，管理者身份，以及工作相关信息
单位的联系信息，例如电话号码，所在地址，管理者身份，以及业务描述
设备信息，例如打印机的物理位置，打印机类型，该打印机是否支持彩色打印，以及其打印速度(每分钟可以打印多少页)
公司合作伙伴和客户联系信息和帐单信息
合约信息，例如客户的名称，到期时间，工作描述，价格信息，以及客户和企业内负责该合约职员的联系信息
个人的软件参数设置或软件配置信息
资源位置，例如到WEB服务器的指针，或特定文件或应用程序的文件系统位置
目录不应该包括的内容
目录服务不是文件系统，不是文件服务器，不是FTP服务器，不是WEB服务器，也不是关系数据库。因而，如果你想要在目录中包括大型的没有结构的对象，则应该考虑另外使用更适合该任务的服务器。但是，可以通过使用FTP、HTTP或其他类型的URL，在目录服务内存储指向到这些类型应用的指针。
记住目录服务并不是对关系数据库的替代，但是你可以使用关系数据库来存储目录数据(关于详细情况请参见“Netscape Directory Server”)。因而，你应该避免把任何需要关系数据模型的数据放到目录中。
另外，因为目录主要适合于读取操作，所以还应该避免把快速变化的信息放到目录中。减少目录服务中的写入操作次数，可以提高整体搜索性能。
数据规划
一般来说，数据规划应该由访问目录服务的应用程序以及这些应用程序的数据需求来驱动。经常与目录服务一起使用的一些应用程序有：
目录浏览器应用程序，例如联机电话簿。决定你想要用户在通过目录服务执行电话簿查询时可以获取哪些信息(例如电子邮件地址，电话号码，职员名称，等等)，并确认把这些信息放到了目录中。
电子邮件应用程序，尤其是电子邮件服务器。不同的电子邮件服务器可能需要不同类型的信息。所有的电子邮件服务器都需要目录中有电子邮件地址、用户姓名和路由信息。但是，还有一些电子邮件服务器可能需要一些更高级的信息，例如存储用户邮箱的磁盘位置，假期外出留言信息，以及协议信息(例如IMAP和POP)。
支持目录服务的人力资源(HR)应用程序。这些应用程序主要需求为个人信息，例如身份证号，家庭地址，家庭电话号码，生日，薪水，和职务等。
在规划目录数据时，不仅要规划当前想要放入目录中数据，还要试图确定在未来一段时间内需要包括在目录中的数据。尽管不是严格需要，但是提前进行规划有助于提供目录服务的灵活性，以便在企业中承担更为重要的任务。
在规划时，需要考虑如下内容：
当前想要在目录中包括哪些东西？也就是说，你希望通过部署目录来解决的最紧迫的问题是什么？最先使用的支持目录的应用程序需要什么数据？
你认为在将来可能需要存储到目录的数据是什么？尽管这是一个最难考虑的问题，但是这样做将会得到回报的。至少，这种规划将有助于标识出你本来可能还没有了解到的数据存储(即管理信息的位置)。
如果你想要使用目录服务器不仅仅用于Netscape服务器管理，则还需要规划将要存储到目录中的信息类型。除了Netscape服务器之外，你可能还会发现想包括如下类型的信息：
合约和客户帐户
薪水册
物理设备
家庭联系信息
企业内不同位置的办公室联系信息
进行现场调查
为了标识出想要包括在目录中的所有数据，应该执行数据存储的现场调查。也就是说，应该调查企业内的任何相关数据。作为调查的一部分，你应该：
找出企业内所有管理信息的单位。通常这些单位包括信息服务(IS)，人力资源(HR)，薪水册，会计部门。
标识出企业用来维护这些信息的工具和过程。通常包括网络操作系统(Windows NT, Novell Netware, UNIX NIS)，电子邮件系统，安全系统，PBX(电话交换)系统，以及人力资源应用程序。
确定把这些数据全部集中存放会对管理组织产生哪些影响。在最优情况下不会有影响，但是通常你都会发现集中数据管理都需要新的工具和新的过程。有时候这种信息集中化可能会导致某些单位需要增加人员，而有些单位则需要削减人员(实际上，从整体上来说人员数量将会减少，同时过程的效率会更高)。
由于目录服务对其产生影响的单位数量可能很多，所以有可能需要成立一个目录部署小组，在其中包括来自每个影响单位的人员。例如，一个公司通常会包括人力资源(HR)部门，财会部门，一个或多个制造单位，一个或多个销售单位，一个或多个开发单位。在小组中包括来自这些受影响单位的代表，将有助于更加快速地完成调查工作。更重要地是，这将更加有助于听取用户意见。直接涉到所有受影响单位，在从本地数据存储迁移到集中化目录服务时可能需要很长的历程。
最后，你可以需要进行多次现场调查。对于那些在多个城市或国家都有办公室的大型企业来说尤其如此。你可能会发现信息需求是如此的复杂，以至于你将不得不允许不同的单位在其本地办公室(而不是单个的集中控制服务器)控制信息。在这种情况下，应该对每个负责控制信息的办公室进行现场调查。在这个过程完成之后，每次调查的结果都应该返回到中心小组(可能由来自不同办公室的代表组成)，以供在设计企业数据方案和目录树时使用。
方案设计将在第四章“规划目录方案”中介绍。目录树设计将在第六章“目录树设计”中介绍。
分析现场调查结果
在标识出企业的全部重要数据之后，你必须确定这些数据是否能够或应该存储到目录中。你还必须确定是否所有需要访问这些数据的人和应用程序都能够从目录中读取数据和/或写入数据到目录中。例如，你可以想要把每一个职员的家庭地址存储到目录中，但是如果你的财务应用程序不能够获取该信息，则你必须在多个位置管理这些信息。关于在目录中应该维护什么类型的数据，以及什么时候开始在目录中维护这些数据等的决策，将主要受以下几种因素的影响：
不同的老应用程序(例如电子邮件应用程序)以及用户所需要的数据。
老应用程序与LDAP目录服务进行通信的能力。你的数据分析将会涉及到确定控制数据的位置，谁将拥有这些数据，以及谁能够读取这些数据。你还应该对决策仔细地进行文档记录。这些活动将在下面各节中予以介绍。
数据控制
只有当数据必须存放在多个物理位置时，数据控制才是重要的。当你使用复制或使用不能与LDAP进行通信的应用程序，将会发生这种情况。
用于复制的数据控制
如果你使用复制，则必须考虑哪些服务器将控制或提供任何给定数据。这是因为Netscape Directory Server你在单台控制服务器上控制任何给定信息。(关于复制的详细信息，请参见第7章“规划复制”)。
在最简单的情况下，你可以选择在一个目录服务器上控制所有数据，然后将数据复制到一个或多个客户服务器上。在更为复杂的情况下，尤其是对于大型跨国企业来说，你可能会想要在距离数据所代表的人、应用程序或事物比较近的位置控制数据。
跨越多个应用程序的数据控制
如果有的应用程序不能直接与目录服务进行通信，则数据控制将会是一个问题。在这种情况下，最好是保持更改数据的过程以及更改数据的位置尽可能地简单。而且，一旦你决定在一个位置控制某一种数据，例如职员的姓名，则应该尽可能地在相同位置来控制在该位置所包含的所有其他数据，例如职员的家庭地址和电话号码。这使得你可以在当数据库在企业内部不同步时，更加容易地了解到信息所在的最终存储位置。
可以用来进行数据控制的方法包括如下一些：
在目录服务中和所有其他不支持目录的应用程序中控制数据。这是一种最容易实施的情况，因为它不需要你编写客户端脚本，在目录和应用程序之间移动数据。当然，这种方法也意味着如果一个位置的数据发生改变，同时必须有人在所有其他位置进行相同的修改。最终这并不是一种理想的情况，因为它将会导致数据在企业内部变得不同步(目录服务的目的就是为了使数据保持同步)。
在目录服务中控制数据，然后编写脚本或代码，将数据更改导出到相关的应用程序。如果仅有有限几个应用程序不能与目录服务进行通信，则采用这种策略将会比较有效。
在某些非目录服务的应用程序中控制数据，然后编写脚本、程序或网关，将数据导入到目录中。如果你已经标识出一、二个已经用于控制数据的应用程序，并且想将目录服务只用于查询服务(例如公司联机电话簿)，则采用这种策略将会比较有效。
所选择的策略取决于企业的特定需求。但是，不管选择哪一种方法，都应该保持这种方法尽可能地简单、一致。例如，你不应该试图在多个位置控制数据，然后自动在应用程序之间交换数据。这样做将会导致“最后的改变获胜”的情况，并可能会增加管理开销。例如，假设你想要管理一个职员的家庭电话号码。这个信息同时存储在LDAP目录和人力资源(HR)数据库中。根据人力资源应用程序，你可能会编写一个自动运行的应用程序，将数据从LDAP目录传送到HR数据库，或者进行相反方向的传送。但是，如果你试图同时在LDAP目录和HR数据库中同时控制该职员电话号码的更改，将可能会导致这样一种情况，最后更改电话号码的位置将会覆盖其他数据库中的信息。只要最后执行写入操作的应用程序保持正确的数据，这种情况也是可以接受的。但是，如果该信息不再是最新的信息(例如，从备份中恢复了人力资源数据)，则存储在LDAP目录中的正确电话号码将会被破坏。
关于编写客户过滤器的简要介绍，请参见第10章“扩展目录服务”。
数据所有权
数据所有权是指负责确保数据是最新数据的人或单位。在规划数据管理时，你需要决定让谁具有写入数据的能力。一些常用的策略包括：
除了少数目录内容管理员之外，只允许其他人对目录进行只读访问。
允许每个用户管理关于他们自身信息的一个策略性子集。这些信息可能包括他们的口令，关于他们自身及他们在公司中角色的描述性信息，他们的驾驶执照号码，以及联系信息(例如电话号码或办公室房间号)。
允许一个人的经理写入关于这个人的信息的某个策略性子集，例如联系信息或职位。
允许单位的管理者创建和管理该单位的条目。实质上，这将会使得企业的管理者同时成为了目录内容管理员。
创建不同的组以定义角色，例如人力资源，财务，或会计。允许这些角色只能够访问该组所需要的数据，尤其是敏感性数据，例如薪酬信息，身份证号(在美国为社会安全号)，家庭电话号码和地址。
当你执行分析并决定谁能写入数据时，你可能会发现个人也需要具有对相同信息的写入权限。例如，你将想要一些信息系统(IS)或目录管理组具有对职员口令的写入权限。你还会想让职员自己具有更改他们自己的口令的权限。尽管通常会需要允许多个人具有对相同信息的写入权限，但是你还是应该保持这个组尽可能地小，并且容易标识。这样做将会更容易保证数据的完整性。
关于设置目录访问控制的详细信息，请参见第5章“规划安全策略”。
确定数据访问
除了确定数据所有权之外，还必须决定谁能够读取信息。例如，你可能会决定在目录中存储职员的家庭电话号码。对于大多数单位这可能是有用的信息，包括职员的经理和人力资源单位。通常，你还将想要职员自己能够访问这些信息，以便于确认。但是，家庭联系信息也是一种敏感性信息。因此你必须要确定是否需要让这些信息在整个企业内都可以访问。
因此，对于目录中存储的每一种信息，必须决定如下内容：
数据是否可以匿名读取？LDAP协议本身支持匿名访问，并且它常常用于公共信息查询，例如办公室位置，电子邮件地址，办公电话号码(语音和传真)，等等。匿名访问的缺点是能够访问目录就能够访问信息。因此，你很少会需要使用这种功能。
数据是否能够在企业内部任何地址被读取？你可以设置访问控制，使得在读取特定信息之前，需要先登录目录服务。通常你将会需要选择这种情况的访问，以确保只有企业内部成员才能够访问到目录信息。这种访问控制还允许你查看谁正在访问给定信息，因为可以在目录的访问日志中获取用户的登录信息。
是否有一组可以标识出的人或应用程序需要读取数据？任何拥有数据写入权限的人通常也需要读取权限(当然，口令写入权限是一种例外)。但是，还会有一些数据只有特定单位或项目组才需要。尽可能早地标识出这些访问需求，将有助于确定需要在目录中创建哪些组和哪些访问控制。
关于分组管理的详细信息，请参见“规划分组”。
在对每一种目录数据进行决策时，实质上是对目录定义一种安全策略。在这里所做的决策将在很大程度上受站点的本质以及站点已有的安全类型影响。例如，如果站点有一个防火墙，或者根本就不具有到Internet的直接访问，则支持匿名访问将会比把目录直接放到因特网上要自由得多。
关于安全策略的创建以及实施安全策略的方法，将在第5章“规划安全策略”中详细介绍。
对现场调查进行文档记录
由于这一规划活动的复杂性，对数据分析结果进行文档记录是相当重要的。一种解决这个问题的方法是创建一个简单表，概要记录所有决策和重要事件。你可以用自己选择的字处理软件包来建立这个表，或者使用电子表格，以便可以更加容易地存储和搜索这个表的内容。
下表是关于你可能想要建立以帮助进行数据规划的一个简单范例。该表标识出了每种已标识数据的数据所有权和数据访问权限。
Data Name
Owner
Master Server/Application
Self Read/Write
Global Read
HR Writable
IS Writable
Employee name
HR
People Soft
Read-only
Yes (anonymous)
Yes
Yes
User password
IS
Directory US-1
Read/Write
No
No
Yes
Home phone number
HR
People Soft
Read/Write
No
Yes
No
Employee location
IS
Directory US-1
Read-only
Yes (must login)
No
Yes
Office phone number
Facilities
Phone switch
Read-only
Yes (anonymous)
No
No
例如，这个目录必须标识出职员的姓名。表中的每一栏代表了存储在目录中的职员姓名的如下信息：
Owner ---- 这一信息的所有者是人力资源部(他们是负责更新或更改该信息的单位)。
Mater Server/Application ---- 管理职员姓名信息的应用程序是一个叫作People Soft的人力资源应用程序。
Self Read/Write ---- 个人能够读取他们自己的姓名，但是不能写入(或更改)。
Global Read ---- 职员姓名可以被每一个能访问该目录的人员匿名读取。
HR Writable ---- HR组的成员可以更改、添加或删除目录中的职员名称。
IS Writable ---- IS组(信息服务)的成员可以更改、添加或删除目录中的职员名称。
目录方案设计
数据分析的最后一步是设计目录方案。实质上，方案设计就是将所发现的数据映射到适当的名称和句法。你还将决定将在要目录中包含哪些条目(人，设备，单位，等等)，并且这些将确定给定条目类型的实际属性。
通常你将会需要扩展标准目录方案，以支持企业的需求。因此，你应该在数据分析表中留出一些空间，以标识将要用于代表特定数据的属性名称和对象类结构。另外，你还需要记录其他方案相关的信息，例如数据类型的句法，存储数据条目所使用的对象类，等等。
下一章将介绍目录方案，属性的概述，对象类结构，以及方案扩展。此外，“自定义方案”一节还将提供关于管理目录方案的一些信息。
以上由WindowsNT翻译，水平有限，请多多包涵。 |
|
免费注册
楼主: hutao
发表于 2002-12-26 10:15
