身份和访问管理:平台和基础结构 第 4 章:设计基础结构

来源:百度文库 编辑:神马文学网 时间:2024/04/28 11:53:58
show toc
Microsoft 标识和访问管理
平台和基础结构
第 4 章:设计基础结构
发布日期: 2004年05月11日 | 更新日期: 2006年12月06日
Contoso 就身份和访问管理对多个厂商的平台进行了评估,其中也包括 Microsoft 的产品。根据公司的要求,Contoso 最终选择了 Microsoft 身份和访问管理平台。本章将讨论促成该决定的基础结构设计。
本页内容
解决方案概念
解决方案体系结构
启用的解决方案情境
解决方案概念
Contoso 所需的关键功能由 Microsoft 身份和访问管理平台的下列特性来提供:

Microsoft® Active Directory® 目录服务遵从因特网工程工作小组 (IETF) RFC 3377 — LDAP (version 3.0)。

保存客户和合作伙伴信息的 Extranet Active Directory 可以驻留在周边网络中,可以在没有建立与内部目录信任关系的情况下支持员工的身份验证。

Active Directory 为用户凭证的加密提供了多种选项。由于与强大的网络身份验证协议(如 Kerberos 版本5 身份验证协议、安全套接字层 (SSL) 或传输层安全性 (TLS) 客户端身份验证)的集成,凭证不会流散到目录之外。

Microsoft Windows Server™ 2003 中的 Active Directory 通过 Kerberos 版本5 协议和 Digest 身份验证协议来支持基于密码的凭证。Active Directory 也通过 Kerberos 版本5、SSL 或 TLS 协议支持用于客户端身份验证的公钥基础结构 (PKI) 凭证。

通过使用 Kerberos 版本5、SSL 和 TLS 协议,Active Directory 提供了完美的身份验证。

桌面客户端操作系统(例如 Microsoft Windows® 2000 Professional、Windows® XP Professional 和运行 UNIX 或 Linux 的工作站)都可以与服务器操作系统进行无缝地互操作,通过 Kerberos 版本5、轻量级目录访问协议 (LDAP) 和其他基于标准的协议来进行身份验证和授权。

Windows Server 2003 和很多客户端操作系统都能够进行互操作,使用在登录过程中计算或取得的默认凭证对用户进行身份验证。这种身份验证对用户是透明的,能够满足 SSO 用户体验的要求。

Windows Server 2003 使用访问控制列表 (ACL) 以及基于角色的授权。Active Directory 拥有强健且灵活的机制,能够通过组成员关系来表现权限。

Windows Server 2003 目录和安全服务拥有多种层次的信任,包括跨林信任、外部信任、PKI 信任以及与 UNIX Kerberos 领域的跨领域信任。

安装了 Active Directory 的 Windows Server 2003 提供了详尽的审核功能,可用于系统中执行的所有身份验证、信任、授权以及配置操作。
返回页首
解决方案体系结构
这个解决方案体系结构包括下列组件:

目录服务

身份验证方式

授权方式

信任机制

身份验证生命周期管理

具有身份意识的应用程序
目录服务
Contoso 身份和访问管理平台的成功运行要求 Contoso 团队确定一个用于创建身份信息的权威机构和一个用于存储应用程序和身份信息的权威位置。同时,该团队也需要实现目录间适当的属性信息流。
目前,该组织基础结构中的目录服务配置如下:

一个 Intranet Active Directory 林。

一个 Extranet Active Directory 林。

一台 Sun One Directory Server 5.1 (以前称为 iPlanet Directory Server)。
由于 Extranet Active Directory 林仅包含员工的影子帐户,因此不能用作权威目录服务。在重新编写依赖 Sun One Directory Server 5.1 的应用程序,使其能在 Active Directory 中运行后,这台服务器将退役。
Intranet Active Directory 林为目前 Contoso 的用户帐户提供集中的存储。因此,公司选择 Intranet Active Directory 来作为所有目录和应用程序特有信息的权威机构。
Contoso 团队将使用身份集成产品来复制某些目录对象,以实现:

为 Extranet 林中所有“销售部”成员创建帐户。

使用 Active Directory 中的一个属性来判断哪些员工来自最近收购的公司。

将这些帐户复制到 Lotus Notes Release 6.5.4 和 Sun ONE Directory Server 5.1。
Intranet Active Directory 林
这个 Intranet 林由一个空的根域 corp.contoso.com 和一个唯一的子域 na.corp.contoso.com 组成。na.corp.contoso.com 域包含有下列组织单元 (OU):

员工

Solaris 工作站

Windows 客户端



禁用的

联系人
在 Windows Server 2003 中安装 Active Directory 以及创建 OU 的操作说明请参考相关产品文档。
Extranet Active Directory 林
Extranet 林包含有一个唯一的域 perimeter.contoso.com。perimeter.contoso.com 域在 Windows Server 2003 功能层上运行,包含有下列 OU:

员工

试用用户


Intranet 林和 Extranet 林之间没有信任关系。本章稍后有关信任的小节将讨论其原因。
图 4.1 显示了 Contoso 的 Active Directory 结构。

图 4.1.Contoso 的 Active Directory 逻辑结构
有关 Active Directory 的更多信息,请参考“Windows Server 2003 Active Directory ”页面。
其他指南,请参考“设计和部署目录和安全服务 ”页面。
身份验证方式
Contoso 根据每种身份验证方式的特点以及公司将要采用的运行环境来选择身份验证方式。筛选的结果是 Intranet 目录采用单一的身份验证方式, Extranet 目录采用三种方式,如下两图所示。

图 4.2.Contoso 基础结构中 Intranet 身份验证和授权的机制
查看大图

图 4.3.Contoso 基础结构中 Extranet 身份验证和授权的机制
Intranet 目录的身份验证
Intranet 中所采用的主要身份验证机制是 Windows Server 2003 和 Windows XP Professional 都支持的 Kerberos 版本5 协议。很多其他的平台也包括 Kerberos 协议库,特别是各种版本的 UNIX,也包括 Linux。由于 Kerberos 版本5 是一个基于标准、高度安全的网络协议,因此 Contoso 将在任何可能的地方使用该协议。很多平台都使用 Kerberos 版本5 协议的身份验证,因此这个协议为实现互操作提供了一个良好的基础。
在 Intranet 中,所有受控的客户端计算机(包括运行 Windows XP Professional 和 Sun Solaris 操作系统的计算机)都使用 Kerberos 版本5 协议登录到 Intranet 林中的帐户。在他们登录后,用户仍使用 Kerberos 版本5 协议来对特定的资源进行身份验证。
Extranet 目录的身份验证
由于目前 Contoso 环境中面向 Internet 的应用程序的 Web 客户端仍不支持 Kerberos 版本5 身份验证协议,因此 Extranet 采用了多种不同的身份验证方式。在 Contoso 周边网络中驻留有三个外部、面向 Internet 的应用程序,它们使用下列身份验证方式:

Microsoft Passport。

基于 Microsoft Windows Forms 的身份验证。

安全套接字层 (SSL) 和传输层安全性 (TLS) 客户端证书身份验证。
所有这三种身份验证机制都使用 Extranet Active Directory 林作为身份存储。 Extranet 域中包含有针对 Passport 和客户端证书身份验证的用户帐户,并包含用于 Windows Forms 身份验证的密码凭证。
授权方式
Contoso 将要采用的主要授权方式利用文件和打印服务器(未在图 4.3 上显示)上的访问控制表 (ACL)。但是,Contoso 还将通过 Windows Server 2003 中的授权管理器来应用基于角色的访问控制。授权管理员与 Internet Information Services (IIS) 6.0 进行交互,既能提供 URL 层的授权,也能为访问 Web 应用程序提供更为详尽的应用程序层权限。
Contoso 将利用安全组来组织用户,例如根据部门或角色。这些安全组将能够简化用户的权限授予,减少在用户工作更改时所涉及的管理操作。
信任
在考虑建立 Extranet 目录和 Intranet 基础结构目录之间的联盟关系时,Contoso 团队拥有下列选择:

跨林信任

PKI 合格的次级关系

影子帐户
跨林信任
Windows Server 2003 实现了林间的信任关系。在 Contoso 环境中,曾经考虑过这种方法。这样使用 Extranet 应用程序的员工就可以通过这种信任关系通过内部目录的身份验证。
公司长远的想法是创建和部署能够利用端到端身份验证的应用程序。在实现这一目标之前,公司必须对 Intranet 络的安全性进行全面的分析,然后根据需要采取正确的行动,修补所发现的问题。
最后,Contoso 决定不在组织的环境中采取这类的信任。对 Contoso 情境的安全性关注以及公司应用程序情境目前仍不需要这种信任关系的事实共同促成了这一决定。在 Contoso 的案例中,主要的关注点是 Intranet 的安全性,而不是内外林间信任关系所带来的额外应用程序功能。
当然,您所在组织也可能拥有需要实施跨林信任的情境。例如,外部用户可能需要在外部服务器上进行身份验证,然后访问组织 Intranet 中的信息。在这种情况下,您可能需要使用户身份和应用程序请求从 Web 服务器传输到应用程序数据源。您可以通过 Kerberos 版本5 协议新的委派特性以及 Windows Server 2003 中的跨林信任机制来实现这类情境。
PKI 品质的次级关系
公钥基础结构 (PKI) 使组织能够使用公钥加密的方法安全地在公共网络中交换数据。PKI 包括颁发数字证书的证书颁发机构 (CA)、存储证书的目录(包括 Windows 2000 Server 和 Windows Server 2003 中的 Active Directory)以及颁发在网络中安全实体的 X.509 证书。PKI 会检验基于证书的凭证,确保证书未被撤回、破坏或修改。
合格的次级关系是一种跨 CA 层级结构的过程,使用基本、策略、命名和应用程序限制条件来限制哪些来自合作伙伴 CA 层级结构(或来自同一组织中的次级层级结构)的证书可以被接受您可以使用合格的次级关系来定义您的组织信任哪些合作伙伴 PKI 所颁发的证书。合格的次级关系也能够根据策略来划分和控制组织中的证书颁发。
根据 Microsoft 的最佳实践,Contoso 实施了一个三层的 PKI 基础结构,包括一个颁发证书的 CA、一个离线的中间机构以及一个离线的根 CA。然后 Contoso 的 IIS 管理员向证书颁发机构请求服务器证书,在 IIS 上启用对 Internet Web 应用程序的 SSL 加密。Contoso 也针对员工启用了 Active Directory 中的用户证书自登记策略,并启用了 Active Directory Mapper 和 IIS 中的客户端证书映射。
有关跨林信任和 PKI 合格的次级关系的更多信息,请参考 Microsoft.com 中的下列页面:

使用 Windows Server 2003 规划和实施证书跨越和合格的次级关系

公钥策略的概念

公钥策略使用说明
有关部署 Microsoft 证书服务的更多信息,请下载并阅读第 16 章“设计公钥基础结构".
影子帐户
Contoso 选择的联合设计方案在周边网络应用程序中对内部用户(员工)进行身份验证,在外部 Active Directory 中创建影子帐户。这些影子帐户仅用于基于证书的身份验证。影子帐户仅包含与 Extranet 应用程序相关的有限授权信息,例如姓名和组成员关系,但是不包含用户的帐户密码。
销售部员工使用这些影子帐户来访问驻留在周边网络中的应用程序。由于对于外部应用程序访问来说,这些影子帐户已经足够了,因此内外林之间没有建立信任关系。
身份生命周期管理
为了管理数字身份的生命周期,Contoso 选择了具有 Service Pack 1 的 Microsoft Identity Integration Server 2003 Enterprise Edition (MIIS 2003 with SP1)。这个产品提供了必要的身份集成支持,包括数字身份的有效同步、配置和取消配置等。它也提供了多种管理代理,可以连接到 Contoso 环境中的多种不同的身份存储。
Contoso 使用 Microsoft 证书服务和策略配置来启用用户帐户的自登记。这种自登记功能使得用户帐户管理更为简单且经济合算。在 Microsoft 身份和访问管理框架中,使用客户端证书的用户身份验证访问最为适合各种情境,并能带来显著的安全收益。
例如,客户端证书身份验证能够避免使用密码对周边网络中“销售和联系人”应用程序服务器进行身份验证所关联的安全风险。由于外部客户和合作伙伴不需要基于证书的身份验证,因此 Contoso 仅在公司 Intranet 络中部署了证书服务和自登记。
具有身份意识的应用程序
为了支持具有身份意识的应用程序的开发,Contoso 实施了一个相关策略,即在任何可能的地方使用 Kerveros 版本5 身份验证协议以及 Active Directory。如果应用程序(例如 Extranet 应用程序)无法使用 Kerberos 协议进行身份验证,那么商业到商业 (B2B) 的应用程序将使用基于 Windows 表单的身份验证,商业到消费者 (B2C) 的应用程序将使用 Microsoft Passport,而商业到员工 (B2E) 的应用程序将使用智能卡证书(在将来)。
对固定对象(例如目录中的文件和条目)的授权将由访问控制列表 (ACL) 来提供。基于 Web 的应用程序将使用基于角色的访问,这种访问将利用“授权管理器”。
Contoso 网络
图 4.4 显示了 Contoso 身份和访问管理体系结构的完整实施情况。

图 4.4.Contoso 身份和访问管理基础结构的网络布局
查看大图
Contoso 身份和访问管理技术体系结构的实施包括下列内容:

一个将外部 Active Directory 和 Intranet 络分隔开来的防火墙。

Internet 与 Intranet 络没有直接的连接。

Internet 与外部 Active Directory 没有直接的连接。

一个用于 Extranet 的独立的林。

Extranet 中两台运行 IIS 6.0 的 Web 服务器,驻留公司为销售员工和客户提供的应用程序。

一个周边网络 Web 服务器,驻留证书撤回列表 (CRL) 分发点,检查用户用来对外部应用程序进行身份验证的证书。

一个 Lotus Notes Release 6.5.4 应用程序和一个 Sun ONE Directory Server 5.1,提供 Intranet 的部分服务。

Intranet 中的证书服务。
Contoso 身份和访问管理平台建立在由 Microsoft 及许多领先的硬件和软件厂商开发的 Windows Server System 参考体系结构 (WSSRA) 基础上。WSSRA (以前称为 Microsoft Systems Architecture 2.0 或 MSA)提供了经测试的逐步操作说明,解释如何在 Microsoft 基础上实现大规模 IT 基础结构。
更多有关 WSSRA 的信息,请参考Windows Server System 参考体系结构 页面。
本文档的附录 A 提供了在 Virtual PC (VPC) 2004 测试环境中配置 Contoso 环境所需的设置。
返回页首
启用的解决方案情境
Microsoft 平台基础结构启用了下列解决方案:

跨多个目录的身份聚合和同步。

密码管理,包括对多个目录的密码传播。

Intranet 访问管理,包括与 Active Directory 的 UNIX 和 SAP 集成。

Extranet 访问管理,包括对 B2B、B2C 和 B2E 环境的支持。

开发具有身份意识的 ASP .NET 应用程序,包括对 Intranet 和 Extranet 应用程序开发的支持。
该公司的基本策略是使用自动的有效过程来替代手动、低效的数字身份管理过程。本系列的其他文章将更为详细地介绍下面的这些目标领域。
身份聚合和同步
为了提供组织内的身份聚合和同步,Contoso 选择使用具有 SP1 的 MIIS 2003 作为身份集成产品,这个产品将与公司所有的目录服务和其他身份存储进行集成,包括:

Intranet Active Directory 林。

Extranet Active Directory 林(包含客户、合作伙伴以及员工的影子帐户)。

Sun One Directory Server 5.1 (以前称为 iPlanet Directory Server)。

Lotus Notes Release 6.5.4。
有关该主题的更多信息,请参考本系列中的《身份聚合和同步》。
密码管理
为了实施有效密码管理,Contoso 选择了下列组件:

Active Directory 中的组策略,强制实施密码强度、复杂程度和过期时间。

一个自定义的密码筛选器和通知动态链接库 (DLL),使得用户能够更改 Active Directory 中的密码,然后将他们更改后的密码传播的其他目录和身份存储。

具有管理代理 (MA) 的 MIIS 2003,管理所有已连接目录中的密码更改。

一个使用 Windows Management Instrumentation (WMI) 的自定义 Windows Service,提供 Active Directory 域控制器和 MIIS 2003 MA 之间的联系。这种组合将能够把密码更改传输到 Lotus Notes Release 6.5.4 和 Sun One Directory Server 5.1。

一个 MIIS 2003 提供的自定义 Web 应用程序,使得帮助台操作人员能够在一个位置重新设置用户密码。然后,MIIS 2003 将把密码更改传递到所有连接的目录中。
更多相关信息,请参考本系列的《密码管理》。
Intranet 访问管理
对于 Intranet 访问管理,Contoso 统一使用下列配置:

对于身份验证和数据保护,使用 Kerberos 版本5 身份验证协议。

将 Active Directory 域控制器作为密钥分发中心 (KDC),用于使用 Kerberos 版本5 协议的身份验证。

在 SAP R/3 和 UNIX 工作站中对使用 Kerberos 版本5 协议的身份验证启用应用程序支持。
更多相关信息,请参考本系列的《Intranet 访问管理》。
Extranet 访问管理
对于 Extranet 访问管理,Contoso 选择了下列体系结构来向合作伙伴、客户及员工授权对 Web 应用程序的访问:

一个外部 Active Directory 林,用于管理所有的外部用户帐户。

自注册功能,用于在 Active Directory 中建立客户帐户。

Microsoft Passport Services,用于实现客户身份验证和 SSO。

使用 SSL 加密的基于表单的身份验证,用于保护合作伙伴身份验证序列。

MIIS 2003,用于在外部 Active Directory 林中提供员工影子帐户。

Microsoft Windows Authorization Manager,用于基于角色的授权。

针对 PKI 的 Microsoft Certificate Services。

用于驻留 Web 应用程序的 IIS 6.0。

Microsoft Internet Security and Acceleration Server (ISA),提供一个周边网络,并实现内部和 Extranet 络间的访问控制。
更多相关信息,请参考本系列的《 Extranet 访问管理》。
开发具有身份意识的 ASP.NET 应用程序
为了确保开发具有身份意识的应用程序时的一致性,Contoso 统一使用下列方法:

对于 Intranet 应用程序,使用 Kerberos 版本5 协议。

在应用程序 Web 服务器和后端资源间使用 Kerberos 身份验证。

使用集成 Active Directory 的身份验证和授权,这将为应用程序提供唯一的目录服务。

在后端服务器资源中的 Web 应用程序和 ACL 上使用基于角色的访问控制。
更多相关消息,请参考本系列的《开发具有身份意识的 ASP.NET 应用程序》一文。
返回页首第 4 页,共 9 页

本文内容
•第 1 章:《平台和基础结构》的简介
•第 2 章:选择平台的各种方法
•第 3 章:问题和要求
• 第 4 章:设计基础结构
•第 5 章:实施基础结构
•第 6 章:运行基础结构
•附录 A – Microsoft 身份和访问管理系列的配置设置
•链接
•致谢

下载
获取 Microsoft 身份与访问管理系列文章
更新通知
注册以了解有关更新和新版本的信息
反馈
将您的意见和建议发送给我们

 适合打印机打印的版本 通过电子邮件发送此页面
个人信息中心 |联系我们 |新闻邮件
©2008 Microsoft Corporation. 版权所有.  与我们联系 |保留所有权利 |商标 |隐私权声明