Active Directory（Windows AD域）

介绍

Active Directory is a technology created by Microsoft that provides a variety of network services, including:

  • LDAP-like1 directory services
  • Kerberos-based authentication
  • DNS-based naming and other network information
  • Central location for network administration and delegation of authority 1
  • Information security and single sign-on for user access to networked based resources2
  • The ability to scale up or down easily 3
  • Central storage location for application data 4
  • Synchronization of directory updates amongst several servers 5

Using the same database, for use primarily in Windows environments, Active Directory also allows administrators to assign policies, deploy software, and apply critical updates to an organization. Active Directory stores information and settings in a central database. Active Directory networks can vary from a small installation with a few computers, users and printers to tens of thousands of users, many different domains and large server farms spanning many geographical locations.

Active Directory was previewed in 1999, released first with Windows 2000 Server edition, and revised to extend functionality and improve administration in Windows Server 2003. Additional improvements were made in Windows Server 2003 R2. Active Directory was refined further in Windows Server 2008 and Windows Server 2008 R2 and was renamed Active Directory Domain Services.

Active Directory was called NTDS (NT Directory Service) in older Microsoft documents. This name can still be seen in some Active Directory binaries.

There is a common misconception that Active Directory provides software distribution. Software distribution is run by a separate service that uses additional proprietary schema attributes that work in conjunction with the LDAP protocol. Active Directory does not automate software distribution, but provides a mechanism by which other services can provide software distribution.

相关资料

    1. MSDN：对AD使用的Schema和Attribute有详细介绍
      http://msdn.microsoft.com/en-us/library/ee663272%28VS.85%29.aspx

AD和LDAP的数据类型映射表

Data Type Mapping between Active Directory and LDAP.

 (在AD中新建LDAP属性时需要参考)

The following table maps the friendly syntax name to the corresponding LDAP sytax OID and ADSTYPEENUM value.

Friendly syntax name

LDAP syntax OID

ADSTYPEENUM data type

AccessPointDN

1.3.6.1.4.1.1466.115.121.1.2

ADSTYPE_CASE_IGNORE_STRING

AttributeTypeDescription

1.3.6.1.4.1.1466.115.121.1.3

ADSTYPE_CASE_IGNORE_STRING

Audio

1.3.6.1.4.1.1466.115.121.1.4

ADSTYPE_OCTET_STRING

Binary

1.3.6.1.4.1.1466.115.121.1.5

ADSTYPE_OCTET_STRING

BitString

1.3.6.1.4.1.1466.115.121.1.6

ADSTYPE_CASE_IGNORE_STRING

Boolean

1.3.6.1.4.1.1466.115.121.1.7

ADSTYPE_BOOLEAN

CaseExactString

1.2.840.113556.1.4.1362

ADSTYPE_CASE_EXACT_STRING

CaseIgnoreString

1.2.840.113556.1.4.1221

ADSTYPE_CASE_IGNORE_STRING

Certificate

1.3.6.1.4.1.1466.115.121.1.8

ADSTYPE_OCTET_STRING

CertificateList

1.3.6.1.4.1.1466.115.121.1.9

ADSTYPE_OCTET_STRING

CertificatePair

1.3.6.1.4.1.1466.115.121.1.10

ADSTYPE_OCTET_STRING

Country

1.3.6.1.4.1.1466.115.121.1.11

ADSTYPE_CASE_IGNORE_STRING

DataQualitySyntax

1.3.6.1.4.1.1466.115.121.1.13

ADSTYPE_CASE_IGNORE_STRING

DeliveryMethod

1.3.6.1.4.1.1466.115.121.1.14

ADSTYPE_CASE_IGNORE_STRING

DirectoryString

1.3.6.1.4.1.1466.115.121.1.15

ADSTYPE_CASE_IGNORE_STRING

DN

1.3.6.1.4.1.1466.115.121.1.12

ADSTYPE_DN_STRING

DSAQualitySyntax

1.3.6.1.4.1.1466.115.121.1.19

ADSTYPE_CASE_IGNORE_STRING

EnhancedGuide

1.3.6.1.4.1.1466.115.121.1.21

ADSTYPE_CASE_IGNORE_STRING

FacsimileTelephoneNumber

1.3.6.1.4.1.1466.115.121.1.22

ADSTYPE_CASE_IGNORE_STRING

Fax

1.3.6.1.4.1.1466.115.121.1.23

ADSTYPE_OCTET_STRING

GeneralizedTime

1.3.6.1.4.1.1466.115.121.1.24

ADSTYPE_UTC_TIME

Time (only site server does this)

1.3.6.1.4.1.1466.115.121.1.24

ADSTYPE_UTC_TIME

Guide

1.3.6.1.4.1.1466.115.121.1.25

ADSTYPE_CASE_IGNORE_STRING

IA5String

1.3.6.1.4.1.1466.115.121.1.26

ADSTYPE_CASE_IGNORE_STRING

INTEGER

1.3.6.1.4.1.1466.115.121.1.27

ADSTYPE_INTEGER

INTEGER8 (not in LDAP, NTDS)

1.2.840.113556.1.4.906

ADSTYPE_LARGE_INTEGER

JPEG

1.3.6.1.4.1.1466.115.121.1.28

ADSTYPE_OCTET_STRING

MailPreference

1.3.6.1.4.1.1466.115.121.1.32

ADSTYPE_CASE_IGNORE_STRING

NameAndOptionalUID

1.3.6.1.4.1.1466.115.121.1.34

ADSTYPE_CASE_IGNORE_STRING

NumericString

1.3.6.1.4.1.1466.115.121.1.36

ADSTYPE_NUMERIC_STRING

ObjectClassDescription

1.3.6.1.4.1.1466.115.121.1.37

ADSTYPE_CASE_IGNORE_STRING

OctetString (not in RFC)

1.3.6.1.4.1.1466.115.121.1.40

ADSTYPE_OCTET_STRING

OID

1.3.6.1.4.1.1466.115.121.1.38

ADSTYPE_CASE_IGNORE_STRING

ORName

1.2.840.113556.1.4.1221

ADSTYPE_CASE_IGNORE_STRING

OtherMailbox

1.3.6.1.4.1.1466.115.121.1.39

ADSTYPE_CASE_IGNORE_STRING

PostalAddress

1.3.6.1.4.1.1466.115.121.1.41

ADSTYPE_CASE_IGNORE_STRING

PresentationAddress

1.3.6.1.4.1.1466.115.121.1.43

ADSTYPE_CASE_IGNORE_STRING

PrintableString

1.3.6.1.4.1.1466.115.121.1.44

ADSTYPE_PRINTABLE_STRING

ObjectSecurityDescriptor

1.2.840.113556.1.4.907

ADSTYPE_NT_SECURITY_DESCRIPTOR

TelephoneNumber

1.3.6.1.4.1.1466.115.121.1.50

ADSTYPE_CASE_IGNORE_STRING

TeletexTerminalIdentifier

1.3.6.1.4.1.1466.115.121.1.51

ADSTYPE_OCTET_STRING

TelexNumber

1.3.6.1.4.1.1466.115.121.1.52

ADSTYPE_CASE_IGNORE_STRING

UTCTime

1.3.6.1.4.1.1466.115.121.1.53

ADSTYPE_UTC_TIME

来源：MSDN Windows Developer Center

http://msdn.microsoft.com/en-us/library/aa772375(VS.85).aspx   

Active Directory 用户RDN属性规则：

Depending upon the LDAP server, the full distinguished name (DN) of user objects may require a certain format. In Microsoft Active Directory (2000 or 2003), the RDN is always "cn=...".

 

AD中比较特殊的几个Attribute

SAM-Account-Name Attribute：
The logon name used to support clients and servers running older versions of the operating system, such as Windows NT 4.0, Windows 95, Windows 98, and LAN Manager. This attribute must be less than 20 characters to support older clients.

SN：
作用未明。

Object-Guid
The unique identifier for an object.

Object-Sid
A binary value that specifies the security identifier (SID) of the user. The SID is a unique value used to identify the user as a security principal.

User-Account-Control （userAccountControl，1.2.840.113556.1.4.8）
Flags that control the behavior of the user account.

userAccountControl是一个整数字段，它一共有三种状态：
ACCOUNTDISABLE（546） | PASSWD_NOTREQD | NORMAL_ACCOUNT （66048）

 

Windows AD(LDAP) over SSL (LDAPS) Certificate

1、Java添加、修改MS AD用户密码&配置AD、CA、SSL，绑定keystore

http://blog.csdn.net/andymu077/article/details/7387350

 

2、Troubleshooting LDAP Over SSL

http://blogs.technet.com/b/askds/archive/2008/03/13/troubleshooting-ldap-over-ssl.aspx

http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

 

3、其它

为 AD LDS 配置 LDAP over SSL 要求  :http://doorgods.blog.163.com/blog/static/78547857201123105729973/

 

4、windows server 2003 Active Directory的安装（带ssl）：测试ssl是否连接正常

http://blog.csdn.net/wuliangyue7/article/details/3332523

测试ssl是否开通，打开ldp，选择在connect选项里选择636端口并把ssl勾上。点确定，操作正确的话应该就能连上了。

 

5、windows 2008配置支持AD域（已完成）
http://freemanluo.blog.51cto.com/636588/380360
 

6、配置CA证书SSL环境，支持写入密码（已完成）
https://wiki.servicenow.com/index.php?title=Configuring_Microsoft_Active_Directory_for_SSL_Access

 

How to search for deleted objects in Windows AD

When an Active Directory object is deleted, it is stored in the Deleted Objects container for a configurable period of time to allow replication of the deletion to occur. By using the Show Deleted Object control (controlType = 1.2.840.113556.1.4.417), in conjunction with search commands, you can view Active Directory objects that have been deleted but not yet garbage collected. These objects are called tombstones. After they are deleted by garbage collection, they no longer exist in the directory database.

search for deleted objects by JDNI:http://java.itags.org/java-core-apis/41469/

 

Service Principal Names (SPN) in Windows AD

http://technet.microsoft.com/zh-cn/library/cc961723%28en-us%29.aspx

http://msdn.microsoft.com/en-us/library/ms677949%28VS.85%29.aspx

Service Principal Names

Service principal names are associated with the security principal (user or groups) in whose security context the service executes. SPNs are used to support mutual authentication between a client application and a service. An SPN is assembled from information that a client knows about a service. Or, it can obtain information from a trusted third party, such as Active Directory. A service principal name is associated with an account and an account can have many service principal names.
For information about registering service principal names in Active Directory at service installation, see the MSDN link on the Web Resources page athttp://windows.microsoft.com/windows2000/reskit/webresources.

Service Principal Names Syntax

A service uses the following elements to compose a service principal name.
The basic syntax of service principal name is as follows:

<service type>/<instance name>:<port number>/<service name>
where the elements of the syntax have the following meanings:

  • service type. Type of service, such as "www" for World Wide Web service or "ldap" for Lightweight Directory Access Protocol.
  • instance name. Name of the instance of the service. Depending upon the service type, it is either the name or IP address of the host running the service.
  • port number. Number of the port used by the service on the host, if it is different from the default for the service type.
  • service name. Name of the service. The name can be the DNS name of a host, of a replicated service, or of a domain; or it can be the distinguished name of a service connection point object or of an RPC service object.
    If service name and instance name are the same, as they are for most host-based services, then a service principal name can be abbreviated to two components:
  • <service type>/<instance name>:<port number>
    If port number is a port number different from the default for the service type specified by service type, you must specify the port number.
  • <service type>/<instance name>

Creating the Service Principal Name

A client creates the service principal name for a service. A service principal name can be one of the following: the DNS name of a domain, the DNS name of a host, or the distinguished name of a service connection point object. The SPN is the same for any method of authentication. When using Kerberos to authenticate itself to a server, the client requests a session ticket for the service principal name; when using certificate-based authentication, the SPN is validated against the contents of the "SubjectName" field of the certificate of the server. http://technet.microsoft.com/zh-cn/library/cc961723%28en-us%29.aspx#mainSection Top of page

Host-Based Service Named in DNS

A host-based service is a service that is identified by the name of the host on which the service runs. In such cases, the service principal name is of the service is as follows:
<service type>/<host name>:<port number>
Or, if the service is using the default port for the service type specified by service type, then the SPN can be abbreviated to the following:
<service type>/<host name> http://technet.microsoft.com/zh-cn/library/cc961723%28en-us%29.aspx#mainSection Top of page

Services Named in the Directory Service

The service principal name for services named in the directory service has the following syntax:
<service type>/<host name>:<port number>/<distinguished name>
where the elements of the syntax have the following meanings:

  • service type. Type of service that is sought (for example, "print").
  • distinguished name. Distinguished name in the format specified by Request for Comments (RFC) 1779 of the Internet Engineering Task Force, of an instance of the service type service type (for example, "cn=bldg26,dc=ntdom,dc=reskit,dc=com").
  • host name. DNS name of the host running an instance of distinguished name.
  • domain name. Name of the domain that contains the account running the service specified by distinguished name (formed from the "dc=" components of distinguished name).
    For example, the service principal name for the print service for the NTDOM group in building 26 at Reskit, whose distinguished name is "cn=bldg26,dc=ntdom,dc=reskit,dc=com", which is running on nonstandard port number 1234 on host "prt1.ntdom.reskit.com", is as follows:
    print/prt1.ntdom.reskit.com:1234/cn=bldg26,dc=ntdom,dc=reskit,dc=com

For more information about service principal names, see the MSDN link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.

 

 “be careful that you do NOT register an SPN to more than one username. A username can have more than one SPN registered but an SPN can only have one username.”
 
Windows 2000、Windows XP 和 Windows Server 2003 成员计算机在其安全通道被重置时（例如，在计算机重启时）会更新其 DNS 主机名和 ServicePrincipalName (SPN) 属性。在 Windows XP 和 Windows Server 2003 成员计算机加入域之后，会首先设置或更新其 SPN 属性，然后才执行所要求的重启。ServicePrincipalNames 按照固定的时间间隔每 22 分钟由 Windows 2000 和 Windows Server 2003 域控制器上的 NETLOGON 服务更新一次。

 

Windows AD用户密码

1、unicodePwd

http://msdn.microsoft.com/en-us/library/cc200469.aspx

3.1.1.3.1.5.1 unicodePwd

Active Directory stores the password on a user object or inetOrgPerson object in the unicodePwd attribute. This attribute is written by an LDAP modify under the following restricted conditions. Windows 2000 servers require that the client have a 128-bit (or better) SSL/TLS-encrypted connection to the DC in order to modify this attribute. On Windows Server 2003 and later, the DC also permits modification of the unicodePwd attribute on a connection protected by 128-bit (or better) Simple Authentication and Security Layer (SASL)-layer encryption instead of SSL/TLS. In Windows Server 2008 and later, if the fAllowPasswordOperationsOverNonSecureConnection flag of the dSHeuristics attribute (section 7.1.1.2.4.1.2) equals true and Active Directory is operating as AD LDS, then the DC permits modification of the unicodePwd attribute over a connection that is neither SSL/TLS-encrypted nor SASL-encrypted. The unicodePwd attribute is never returned by an LDAP search.

When a DC receives an LDAP modify request to modify this attribute, it follows the following procedure:

  • If the modify request contains a delete operation containing a value Vdel for unicodePwd followed by an add operation containing a value Vadd for unicodePwd, the server considers the request to be a request to change the password. The server decodes Vadd and Vdel using the password decoding procedure documented later in this section. Vdel is the old password, while Vadd is the new password.
  • If the modify request contains a single replace operation containing a value Vrep for unicodePwd, the server considers the request to be a administrative reset of the password, that is, a password modification without knowledge of the old password. The server decodes Vrep using the password decoding procedure documented later in this section and uses it as the new password.

2、userPassword

http://msdn.microsoft.com/en-us/library/cc200470.aspx

Active Directory supports modifying passwords on objects via the userPassword attribute, provided that (1) either the DC is running as AD LDS, or the DC is running as AD DS and the domain functional level is DS_BEHAVIOR_WIN2003 or greater, and (2) fUserPwdSupport is true in the dSHeuristics attribute (section 7.1.1.2.4.1.2). If fUserPwdSupport is false, the userPassword attribute is treated as an ordinary attribute and has no special semantics associated with it. If fUserPwdSupport is true but the DC is running as AD DS and the domain functional level is less than DS_BEHAVIOR_WIN2003, the DC fails the operation with the error constraintViolation.

As with the unicodePwd attribute, changing a password via the userPassword attribute is modeled as an LDAP Modify operation containing a Delete operation followed by an Add operation, and resetting a password is modeled as an LDAP Modify operation containing a single Replace operation. The control access rights required are the same as for the unicodePwd attribute, as is the requirement that when changing a password, Vdel must match the object's current password.

3、Windows 使用两种不同的密码表示方法（通常称为“哈希”）生成并存储用户帐户密码

http://msdn.microsoft.com/en-us/library/cc211781.aspx

Windows 使用两种不同的密码表示方法（通常称为“哈希”）生成并存储用户帐户密码，而不是以明文存储用户帐户密码。当您将用户帐户的密码设置或更改为包含少于 15 位字符的密码时，Windows 会为此密码同时生成 LAN Manager 哈希（LM 哈希）和 Windows NT 哈希（NT 哈希）。这些哈希存储在本地安全帐户管理器 (SAM) 数据库或 Active Directory 中。

与 NT 哈希相比，LM 哈希相对较弱，因此容易遭到强力攻击。因此，您可能希望阻止 Windows 存储密码的 LM 哈希。本文介绍如何进行操作，以便 Windows 仅存储密码较强的 NT 哈希。

基于 Windows 2000 的服务器和基于 Windows Server 2003 的服务器可对从运行所有早期版本 Windows 的计算机连接的用户进行身份验证。但是，早于 Windows 2000 的 Windows 版本不使用 Kerberos 进行身份验证。为了向后兼容，Windows 2000 和 Windows Server 2003 支持 LAN Manager (LM) 身份验证、Windows NT (NTLM) 身份验证和 NTLM 版本 2 (NTLMv2) 身份验证。NTLM、NTLMv2 和 Kerberos 都使用 NT 哈希，也称为 Unicode 哈希。LM 身份验证协议使用 LM 哈希。

 

Windows Support Tools for Win2003 (有AD相关的工具)

该工具集中有Windows AD相关的命令行工具，例如 adsiedit.msc（类似LDAP Browser），setspn.exe（设置SPN的工具）等等。
安装包下载地址：
http://www.microsoft.com/downloads/en/confirmation.aspx?familyId=6ec50b78-8be1-4e81-b3be-4e7ac4f0912d&displayLang=en

 

Single Sign-on Using Kerberos in Java

http://java.sun.com/j2se/1.4.2/docs/guide/security/jgss/single-signon.html

Single Sign-on Using Kerberos in Java

Mayank Upadhyay

Ram Marti
Sun Microsystems, Inc.

Unknown macro: {mayank.upadhyay, ram.marti}

@sun.com

ABSTRACT

A significant enhancement to the Java security architecture is the capability to achieve single sign-on using Kerberos Version 5 in the next release of JavaTM Standard Edition (J2SE). A single sign-on solution lets users authenticate themselves just once to access information on any of several systems. This is done using JAAS for authentication and authorization and Java GSS-API to establish a secure context for communication with a peer application. Our focus is on Kerberos V5 as the underlying security mechanism for single sign-on, although other security mechanisms may be added in the future.

INTRODUCTION

With the increasing use of distributed systems users need to access resources that are often remote. Traditionally users have had to sign-on to multiple systems, each of which may involve different usernames and authentication techniques. In contrast, with single sign-on, the user needs to authenticate only once and the authenticated identity is securely carried across the network to access resources on behalf of the user.

In this paper we discuss how to use single sign-on based on the Kerberos V5 protocol. We use the Java Authentication and Authorization Service (JAAS) to authenticate a principal to Kerberos and obtain credentials that prove its identity. We show how Sun's implementation of a Kerberos login module can be made to read credentials from an existing cache on platforms that contain native Kerberos support. We then use the Java Generic Security Service API (Java GSS-API) to authenticate to a remote peer using the previously obtained Kerberos credentials. We also show how to delegate Kerberos credentials for single sign-on in a multi-tier environment.

KERBEROS V5

Kerberos V5 is a trusted third party network authentication protocol designed to provide strong authentication using secret key cryptography. When using Kerberos V5, the user's password is never sent across the network, not even in encrypted form, except during Kerberos V5 administration. Kerberos was developed in the mid-1980's as part of MIT's Project Athena. A full description of the Kerberos V5 protocol is beyond the scope of this paper. For more information on the Kerberos V5 protocol please refer to [1] and [2]

Kerberos V5 is a mature protocol and has been widely deployed. It is available on Solaris as SEAM and on Windows 2000 and several other platforms. A free reference implementation in C is available from MIT. For these reasons we have selected Kerberos V5 as the underlying technology for single sign-on in J2SE.

JAVA AUTHENTICATION AND AUTHORIZATION SERVICE (JAAS)

Until recently the Java 2 security architecture solely determined privileges by the origin of the code and the public key certificates matching the code signers. However, in a multi-user environment it is desirable to further specify privileges based on the authenticated identity of the user running the code.

JAAS supplies such a capability. JAAS is a pluggable framework and programming interface specifically targeted for authentication and access control based on the authenticated identities.

Authentication and Authorization

The JAAS framework can be divided into two components: an authentication component and an authorization component.

The JAAS authentication component provides the ability to reliably and securely determine who is currently executing Java code, regardless of whether the code is running as an application, an applet, a bean, or a servlet.

The JAAS authorization component supplements the existing Java security framework by providing the means to restrict the executing Java code from performing sensitive tasks, depending on its codesource and depending on who is executing the code.

Pluggable and Stackable Framework

JAAS authentication framework is based on Pluggable Authentication Module (PAM)[3, 4]. JAAS authentication is performed in a pluggable fashion allowing system administrators to add appropriate authentication modules. This permits Java applications to remain independent of underlying authentication technologies, and new or updated authentication technologies can be seamlessly configured without requiring modifications to the application itself.

JAAS authentication framework also supports the stacking of authentication modules. Multiple modules can be specified and they are invoked by the JAAS framework in the order they were specified. The success of the overall authentication depends on the results of the individual authentication modules.

Subject

JAAS uses the term Subject to refer to any entity that is the source of a request to access resources. A Subject may be a user or a service. Since an entity may have many names or principals JAAS uses Subject as an extra layer of abstraction that handles multiple names per entity.Thus a Subject is comprised of a set of principals. There are no restrictions on principal names.

A Subject is only populated with authenticated principals. Authentication typically involves the user providing proof of identity, such as a password.

A Subject may also have security related attributes, which are referred to as credentials. The credentials can be public or private. Sensitive credentials such as private cryptographic keys are stored in the private credentials set of the Subject.

The Subject class has methods to retrieve the principals, public credentials and private credentials associated with it.

Please note that different permissions may be required for operations on these classes. For example AuthPermission("modifyPrincipals") may be required to modify the principal set of the Subject. Similar permissions are required to modify the public credentials, private credentials and to get the current Subject.

doAs and doAsPrivileged

Java 2 enforces runtime access controls via java.lang.SecurityManager. The SecurityManager is consulted anytime sensitive operations are attempted. The SecurityManager delegates this responsibility to java.security.AccessController. The AccessController obtains a current image of the AccessControlContext and verifies that it has sufficient permission to do the operation requested.

JAAS provides two methods doAs and doAsPrivileged that can be used to associate an authenticated Subject with the AccessControlContext dynamically.

The doAs method associates the Subject with the current thread's access control context and subsequent access control checks are made on the basis of the code being executed and the Subject executing it.public static Object doAs(final Subject subject,
final PrivilegedAction action)

public static Object doAs(final Subject subject,
final PrivilegedExceptionAction action)
throws PrivilegedActionException;

Both forms of the doAs method first associate the specified subject with the current Thread's AccessControlContext, and then execute the action. This achieves the effect of having the action run as the Subject. The first method can throw runtime exceptions but normal execution has it returning an Object from the run() method of its action argument. The second method behaves similarly except that it can throw a checked PrivilegedActionException from its run() method. An AuthPermission("doAs") is required to call the doAs methods.

The following methods also execute code as a particular Subject:public static Object doAsPrivileged(final Subject subject,
final PrivilegedAction action,
final AccessControlContext acc);

public static Object doAsPrivileged(final Subject subject,
final PrivilegedExceptionAction action,
final AccessControlContext acc)
throws PrivilegedActionException;

The doAsPrivileged method behaves exactly as doAs, except that it allows the caller to specify an access control context. Thus it effectively throws away the current AccessControlContext and authorization decisions will be based on the AccessControlContext passed in.

Since the AccessControlContext is set on a per thread basis, different threads within the JVM can assume different identities. The Subject associated with a specific AccessControlContext can be retrieved by using the following method:
public static Subject getSubject(final AccessControlContext acc);

LoginContext

The LoginContext class provides the basic methods used to authenticate Subjects. It also allows an application to be independent of the underlying authentication technologies. The LoginContext consults a configuration that determines the authentication services or LoginModules configured for a particular application. If the application does not have a specific entry, it defaults to the entry identified as "other".

To support the stackable nature of LoginModules, LoginContext performs authentication in two phases. In the first phase or login phase, it invokes each configured LoginModule to attempt the authentication. If all the necessary LoginModules succeed, then LoginContext enters the second phase where it invokes each LoginModule again to formally commit the authentication process. During this phase the Subject is populated with the authenticated principals and their credentials. If either of the phase fails, then the LoginContext invokes each configured module to abort the entire authentication attempt. Each LoginModule then cleans up any relevant state associated with the authentication attempt.

LoginContext has four constructors that can be used to instantiate it. All of them require the configuration entry name to be passed. In addition the Subject and/or a CallbackHandler can also be passed to the constructors.

Callbacks

The login modules invoked by JAAS must be able to garner information from the caller for authentication. For example the Kerberos login module may require users to enter their Kerberos password for authentication.

The LoginContext allows the application to specify a callbackhandler that the underlying login modules use to interact with users. There are two callback handlers available in Merlin (J2SE 1.4) - one based on the command line and another based on a GUI.

LoginModules

Sun provides an implementation of the UnixLoginModule, NTLoginModule, JNDILoginModule, KeyStoreLoginModule and Krb5LoginModule in Merlin. A smart card based JAAS login module is available from GemPlus [5].

The Kerberos Login Module

The class com.sun.security.auth.module.Krb5LoginModule is Sun's implementation of a login module for the Kerberos version 5 protocol. Upon successful authentication the Ticket Granting Ticket (TGT) is stored in the Subject's private credentials set and the Kerberos principal is stored in the Subject's principal set.

Based on certain configurable options, Krb5LoginModule can also use an existing credentials cache, such as a native cache in the operating system, to acquire the TGT and/or use a keytab file containing the secret key to implicitly authenticate a principal. Both the Solaris and Windows 2000 platforms contain a credentials cache that Krb5LoginModule can use for fetching the TGT. Solaris also contains a system wide keytab file that Krb5LoginModule can use for fetching the secret key. On all platforms, Krb5LoginModule supports options to set the file path to a ticket cache or keytab file of choice. This is useful when third-party Kerberos support is installed and Java integration is desired. Please consult the documentation for Krb5LoginModule to learn about these options. In the absence of a native cache or keytab, the user will be prompted for the password and the TGT obtained from the KDC.

Figure 1 provides a sample JAAS login configuration entry for a client application. In this example, Krb5LoginModule will use the native ticket cache to get the TGT available in it. The authenticated identity will be the identity of the Kerberos principal that the TGT belongs to.SampleClient {
com.sun.security.auth.module.Krb5LoginModule required useTicketCache=true
};
Figure 1. Sample client configuration entry

Figure 2 provides a sample login configuration entry for a server application. With this configuration, the secret key from the keytab is used to authenticate the principal "nfs/bar.foo.com" and both the TGT obtained from the Kerberos KDC and the secret key are stored in the Subject's private credentials set. The stored key may be used later to validate a service ticket sent by a client (See the section on Java GSS-API.)SampleServer {
com.sun.security.auth.module.Krb5LoginModule
required useKeyTab=true storeKey=true principal="nfs/bar.foo.com"
};

Figure 2. Sample server configuration entry

In the client code example shown in Figure 3, the configuration entry "SampleClient" will be used by the LoginContext. The TextCallbackHandler class will be used to prompt the user for the Kerberos password. Once the user has logged in, the Subject will be populated with the Kerberos Principal name and the TGT. Thereafter the user can execute code using Subject.doAs passing in the Subject obtained from the LoginContext.LoginContext lc = null;

try {
lc = new LoginContext("SampleClient", new TextCallbackHandler());
// attempt authentication
lc.login();
} catch (LoginException le) {
...
}

// Now try to execute ClientAction as the authenticated Subject

Subject mySubject = lc.getSubject();
PrivilegedAction action = new ClientAction();
Subject.doAs(mySubject, action);

Figure 3. Sample client code

ClientAction could be an action that is allowed only for authenticated Kerberos client Principals with a specific value.

Figure 4 shows server side sample code. It is similar to the client code shown in Figure 4 except for the application entry name and the PrivilegedAction.LoginContext lc = null;

try {
lc = new LoginContext("SampleServer", new TextCallbackHandler());
// attempt authentication
lc.login();
} catch (LoginException le) {
...
}

// Now try to execute ServerAction as the authenticated Subject

Subject mySubject = lc.getSubject();
PrivilegedAction action = new ServerAction();
Subject.doAs(mySubject, action);

Figure 4. Sample server code

Kerberos Classes

To enable other vendors to provide their own Kerberos login module implementation that can be used with Java GSS-API, three standard Kerberos classes have been introduced in the javax.security.auth.kerberos package. These are KerberosPrincipal for Kerberos principals, KerberosKey for the long-term Kerberos secret key and KerberosTicket for Kerberos tickets. All implementations of the Kerberos login module must use these classes to store principals, keys and tickets in the Subject.

Authorization

Upon successful authentication of a Subject, access controls can be enforced based upon the principals associated with the authenticated Subject. The JAAS principal based access controls augment the CodeSource access controls of Java 2. Permissions granted to a Subject are configured in Policy, which is an abstract class for representing the system wide access control policy. Sun provides a file based implementation of the Policy class. The Policy class is provider based so that others can provide their own policy implementation.

JAVA GENERIC SECURITY SERVICE APPLICATION PROGRAM INTERFACE (Java GSS-API)

Generic Security Service API (GSS-API)

Enterprise applications often have varying security requirements and deploy a range of underlying technologies to achieve this. In such a scenario how do we develop a client-server application so that it can easily migrate from one technology to another? The GSS-API was designed in the Common Authentication Technology working group of the IETF to solve this problem by providing a uniform application programming interface for peer to peer authentication and secure communication that insulates the caller from the details of the underlying technology.

The API, described in a language independent form in RFC 2743 [6], accommodates the following security services: authentication, message confidentiality and integrity, sequencing of protected messages, replay detection, and credential delegation. The underlying security technology or "security mechanism" being used, has a choice of supporting one or more of these features beyond the essential one way authentication 1. There are mainly two standard security mechanisms that the IETF has defined: Kerberos V5 [6] and the Simple Public Key Mechanism (SPKM) [8].

The API is designed such that an implementation may support multiple mechanisms simultaneously, giving the application the ability to choose one at runtime. Mechanisms are identified by means of unique object identifier's (OID's) that are registered with the IANA. For instance, the Kerberos V5 mechanism is identified by the OID

Unknown macro: {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5(2)}

.

Another important feature of the API is that it is token based. i.e., Calls to the API generate opaque octets that the application must transport to its peer. This enables the API to be transport independent.Figure 5. A multi-mechanism GSS-API implementation

Java GSS-API

The Java API for the Generic Security Service was also defined at the IETF and is documented in RFC 2853 [10]. Sun is pursuing the standardization of this API under the Java Community Process (JCP) [11] and plans to deliver a reference implementation with Merlin. Because the JCP is merely endorsing this externally defined API, the IETF assigned package namespace "org.ietf.jgss" will be retained in Merlin.

Sun's implementation of Java GSS-API, will initially ship with support for the Kerberos V5 mechanism only. Kerberos V5 mechanism support is mandatory for all Java GSS-API implementations in J2SE, although they are free to support additional mechanisms. In a future release, a Service Provider Interface (SPI) will be added so that new mechanisms can be configured statically or even at runtime. Even now the reference implementation in Merlin will be modular and support a private provider SPI that will be converted to public when standardized.

The Java GSS-API framework itself is quite thin, and all security related functionality is delegated to components obtained from the underlying mechanisms. The GSSManager class is aware of all mechanism providers installed and is responsible for invoking them to obtain these components.

The implementation of the default GSSManager that will ship with J2SE is obtained as follows:GSSManager manager = GSSManager.getInstance();

The GSSManager can be used to configure new providers and to list all mechanisms already present. The GSSManager also serves as a factory class for three important interfaces: GSSName, GSSCredential, and GSSContext. These interfaces are described below with the methods to instantiate their implementations. For a complete API specification, readers are referred to [9] and [11].

Most calls to Java GSS-API throw a GSSException that encapsulate problems that occur both within the GSS-API framework, and within the mechanism providers.

The GSSName Interface

This interface represents an entity for the purposes of Java GSS-API. An implementation of this interface is instantiated as follows:GSSName GSSManager.createName(String name, Oid nameType)
throws GSSException

For Example:GSSName clientName = manager.createName("duke", GSSName.NT_USER_NAME);

This call returns a GSSName that represents the user principal "duke" at a mechanism independent level. Internally, it is assumed that each supported mechanism will map the generic representation of the user to a more mechanism specific form. For instance a Kerberos V5 mechanism provider might map this name to duke@FOO.COM where FOO.COM is the local Kerberos realm. Similarly, a public key based mechanism provider might map this name to an X.509 Distinguished Name.

If we were referring to a principal that was not a user, but some sort of service, we would indicate that to the Java GSS-API call so that the mechanism knows to interpret it differently.

Example:GSSName serverName = manager.createName("nfs@bar.foo.com",
GSSName.NT_HOSTBASED_SERVICE);

The Kerberos V5 mechanism would map this name to the Kerberos specific form nfs/bar.foo.com@FOO.COM where FOO.COM is the realm of the principal. This principal represents the service nfs running on the host machine bar.foo.com.

Sun's implementation of the GSSName interface is a container class. The container class lazily asks the individual providers to perform their mapping when their mechanism is used and then stores each mapped element in a set of principals. In this respect an implementation of GSSName is similar to the principal set stored in a Subject. It may even contain the same elements that are in a Subject's principal set, but its use is restricted to the context of Java GSS-API.

The name element stored by the Sun Kerberos V5 provider is an instance of a subclass of javax.security.auth.kerberos.KerberosPrincipal.

The GSSCredential Interface

This interface encapsulates the credentials owned by one entity. Like the GSSName, this interface too is a multi-mechanism container.

Its implementation is instantiated as follows:GSSCredential createCredential(GSSName name,
int lifetime,
Oid[] desiredMechs,
int usage)

throws GSSException

Here is an example of this call on the client side:GSSCredential clientCreds =
manager.createCredential(clientName,
8*3600,
desiredMechs,
GSSCredential.INITIATE_ONLY);

The GSSManager invokes the providers of the mechanisms listed in the desiredMechs for credentials that belong to the GSSName clientName. Additionally, it imposes the restriction that the credential must be the kind that can initiate outbound requests (i.e., a client credential), and requests a lifetime of 8 hours for it. The returned object contains elements from a subset of desiredMechs that had some credential available to satisfy this criteria. The element stored by the Kerberos V5 mechanism is an instance of a subclass of javax.security.auth.kerberos.KerberosTicket containing a TGT that belongs to the user.

Credential acquisition on the server side occurs as follows:GSSCredential serverCreds =
manager.createCredential(serverName,
GSSCredential.INDEFINITE_LIFETIME,
desiredMechs,
GSSCredential.ACCEPT_ONLY);

The behavior is similar to the client case, except that the kind of credential requested is one that can accept incoming requests (i.e., a server credential). Moreover, servers are typically long lived and like to request a longer lifetime for the credentials such as the INDEFINITE_LIFETIME shown here. The Kerberos V5 mechanism element stored is an instance of a subclass of javax.security.auth.kerberos.KerberosKey containing the secret key of the server.

This step can be an expensive one, and applications generally acquire a reference at initialization time to all the credentials they expect to use during their lifetime.

The GSSContext Interface

The GSSContext is an interface whose implementation provides security services to the two peers.

On the client side a GSSContext implementation is obtained with the following API call:GSSContext GSSManager.createContext(GSSName peer,
Oid mech,
GSSCredential clientCreds,
int lifetime)
throws GSSException

This returns an initialized security context that is aware of the peer that it must communicate with and the mechanism that it must use to do so. The client's credentials are necessary to authenticate to the peer.

On the server side the GSSContext is obtained as follows:GSSContext GSSManager.createContext(GSSCredential serverCreds)
throws GSSException

This returns an initialized security context on the acceptor's side. At this point it does not know the name of the peer (client) that will send a context establishment request or even the underlying mechanism that will be used. However, if the incoming request is not for service principal represented by the credentials serverCreds, or the underlying mechanism requested by the client side does not have a credential element in serverCreds, then the request will fail.

Before the GSSContext can be used for its security services it has to be established with an exchange of tokens between the two peers. Each call to the context establishment methods will generate an opaque token that the application must somehow send to its peer using a communication channel of its choice.

The client uses the following API call to establish the context: byte[] GSSContext.initSecContext(byte[] inToken,
int offset,
int len)

throws GSSException

The server uses the following call:byte[] acceptSecContext(byte[] inToken,
int offset,
int len)

throws GSSException

These two methods are complementary and the input accepted by one is the output generated by the other. The first token is generated when the client calls initSecContext for the first time. The arguments to this method are ignored during that call. The last token generated depends on the particulars of the security mechanism being used and the properties of the context being established.

The number of round trips of GSS-API tokens required to authenticate the peers varies from mechanism to mechanism and also varies with characteristics such as whether mutual authentication or one-way authentication is desired. Thus each side of the application must continue to call the context establishment methods in a loop until the process is complete.

In the case of the Kerberos V5 mechanism, there is no more than one round trip of tokens during context establishment. The client first sends a token generated by its initSecContext() containing the Kerberos AP-REQ message [2]. In order to generate the AP-REQ message, the Kerberos provider obtains a service ticket for the target server using the client's TGT. The service ticket is encrypted with the server's long-term secret key and is encapsulated as part of the AP-REQ message. After the server receives this token, it is passed to the acceptSecContext() method which decrypts the service ticket and authenticates the client. If mutual authentication was not requested, both the client and server side contexts would be established, and the server side acceptSecContext() would generate no output.

However, if mutual authentication were enabled, then the server's acceptSecContext() would generate an output token containing the Kerberos AP-REP [2] message. This token would need to be sent back to the client for processing by its initSecContext(), before the client side context is established.

Note that when a GSSContext is initialized on the client side, it is clear what underlying mechanism needs to be used. The Java GSS-API framework can obtain a context implementation from the appropriate mechanism provider. Thereafter, all calls made to the GSSContext object are delegated to the mechanism's context implementation. On the server side, the mechanism to use is not decided until the first token from the client side arrives.

Here is a class showing how the client side of an application would be coded. This is the ClientAction class that was executed using the doAs method in Figure 3:class ClientAction implements PrivilegedAction {

public Object run() {
...
...
try {
GSSManager manager = GSSManager.getInstance();
GSSName clientName =
manager.createName("duke", GSSName.NT_USER_NAME);
GSSCredential clientCreds =
manager.createCredential(clientName,
8*3600,
desiredMechs,
GSSCredential.INITIATE_ONLY);
GSSName peerName =
manager.createName("nfs@bar.foo.com",
GSSName.NT_HOSTBASED_SERVICE);
GSSContext secContext =
manager.createContext(peerName,
krb5Oid,
clientCreds,
GSSContext.DEFAULT_LIFETIME);
secContext.requestMutualAuth(true);

// The first input token is ignored
byte[] inToken = new byte0;

byte[] outToken = null;

boolean established = false;

// Loop while the context is still not established
while (!established) {
outToken =
secContext.initSecContext(inToken, 0, inToken.length);

// Send a token to the peer if one was generated
if (outToken != null)
sendToken(outToken);

if (!secContext.isEstablished())

Unknown macro: { inToken = readToken(); else established = true; }

} catch (GSSException e)

Unknown macro: { .... }

...
...
}
}

Figure 6. Sample client using Java GSS-API

The corresponding section of code on the server side running the ServerAction class from Figure 5 is as follows:class ServerAction implelemts PrivilegedAction {

public Object run() {
...
...
try {
GSSManager manager = GSSManager.getInstance();
GSSName serverName =
manager.createName("nfs@bar.foo.com",
GSSName.NT_HOSTBASED_SERVICE);
GSSCredential serverCreds =
manager.createCredential(serverName,
GSSCredential.INDEFINITE_LIFETIME,
desiredMechs,
GSSCredential.ACCEPT_ONLY);
GSSContext secContext = manager.createContext(serverCreds);

byte[] inToken = null;
byte[] outToken = null;

// Loop while the context is still not established
while (!secContext.isEstablished())

Unknown macro: { inToken = readToken(); outToken = secContext.acceptSecContext(inToken, 0, inToken.length); // Send a token to the peer if one was generated if (outToken != null) sendToken(outToken); }

} catch (GSSException e)

Unknown macro: { ... }

...
...
}
}

Figure 7. Sample server using Java GSS-API

Message Protection

Once the security context is established, it can be used for message protection. Java GSS-API provides both message integrity and message confidentiality. The two calls that enable this are as follows:byte[] GSSContext.wrap(byte[] clearText,
int offset,
int len,
MessageProp properties)
throws GSSException

and byte[] unwrap(byte[] inToken,
int offset,
int len,
MessageProp properties)
throws GSSException

The wrap method is used to encapsulate a cleartext message in a token such that it is integrity protected. Optionally, the message can also be encrypted by requesting this through a properties object. The wrap method returns an opaque token that the caller sends to its peer. The original cleartext is returned by the peer's unwrap method when the token is passed to it. The properties object on the unwrap side returns information about whether the message was simply integrity protected or whether it was encrypted as well. It also contains sequencing and duplicate token warnings.

Credential Delegation

Java GSS-API allows the client to securely delegate its credentials to the server, such that the server can initiate other security contexts on behalf of the client. This feature is useful for single sign-on in a multi-tier environment.Figure 8. Credential DelegationThe client requests credential delegation prior to making the first call to initSecContext():void GSSContext.requestCredDeleg(boolean state)
throws GSSException

by setting state to true.

The server receives the delegated credential after context establishment:GSSCredential GSSContext.getDelegCred() throws GSSException

The server can then pass this GSSCredential to GSSManager.createContext() pretending to be the client.

In the case of the Kerberos V5 mechanism, the delegated credential is a forwarded TGT that is encapsulated as part of the first token sent from the client to the server. Using this TGT, the server can obtain a service ticket on behalf of the client for any other service.

DEFAULT CREDENTIAL ACQUISITION MODEL

Previously we discussed how an application uses the GSSManager.createCredential() method to populate a GSSCredential object with mechanism specific credentials.The next two sub-sections will focus on how Java GSS-API mechanisms obtain these credentials. The mechanisms do not themselves perform a user login. Instead, the login is performed prior to using Java GSS-API and the credentials are assumed to be stored in some cache that the mechanism provider is aware of. The GSSManager.createCredential() method merely obtains references to those credentials and returns them in a GSS-centric container, the GSSCredential.

In the Java 2 platform we impose the restriction that the credentials cache that Java GSS-API mechanism providers use to obtain these elements must exclusively be the public and private credential sets in the Subject that is on the current access control context.

This model has the advantage that credential management is simple and predictable from the application's point of view. An application, given the right permissions, can purge the credentials in the Subject or renew them using standard Java API's. If it purged the credentials, it would be sure that the Java GSS-API mechanism would fail, or if it renewed a time based credential it would be sure that the mechanism would succeed.

Here is the sequence of events relevant to credential acquisition when the Kerberos V5 mechanism is used by the client application in Figures 3 and 6: 
# The application invokes a JAAS login, which in turn invokes the configured Krb5LoginModule 

  1. Krb5LoginModule obtains a TGT (KerberosTicket) for the user either from the KDC or from an existing ticket cache, and stores this TGT in the private credentials set of a Subject 

  2. The application retrieves the populated Subject, then calls Subject.doAs/doAsPrivileged which places this Subject on the access control context of the thread executing ClientAction 

  3. ClientAction calls the GSSManager.createCredential method, passing it the Kerberos V5 OID in desiredMechs. 

  4. GSSManager.createCredential invokes the Kerberos V5 GSS-API provider, asking for a Kerberos credential for initiating security contexts. 

  5. The Kerberos provider obtains the Subject from the current access control context, and searches through its private credential set for a valid KerberosTicket that represents the TGT for the user. 

  6. The KerberosTicket is returned to the GSSManager which stores it in a GSSCredential container instance to be returned to the caller. 

    On the server side, when the Kerberos login is successful in step 2, Krb5LoginModule stores the KerberosKey for the server in the Subject in addition to the KerberosTicket. Later on the KerberosKey is retrieved in steps 5 through 7 and used to decrypt the service ticket that the client sends.

    EXCEPTIONS TO THE MODEL

The default credential acquisition model for Java GSS-API requires credentials to be present in the current Subject. Typically, the credentials are placed there after a JAAS login by the application.
There might be cases where an application wishes to use Kerberos credentials from outside the Subject. It is recommended that such credentials be read as part of the initial JAAS login, either by configuring Krb5LoginModule to read them, or by writing a custom login module that reads them. However, some applications might have constrains that either prevent them from using JAAS prior to calling Java GSS-API, or force them to use some Kerberos mechanism provider that does not retrieve credentials from the current Subject.
In order to accommodate such cases while still retaining the standard model for others, the system property javax.security.auth.useSubjectCredsOnly was added. This system property serves as a boolean where a value of true requires that the standard credential acquisition model be followed, and a value of false permits the provider to use any cache of it choice. The default value of this property (when it is not set) will be assumed to be true.
If there is no valid Kerberos credential in the current Subject, and this property is true, then the Kerberos mechanism throws a GSSException. Setting this property to false does not necessarily mean that the provider has to use a cache other than the current Subject, it only gives the provider the latitude to do so if it wishes.
The Sun provider for the Kerberos V5 GSS-API mechanism always obtains credentials from a Subject. If there are no valid credentials in the current Subject, and this property is set to false, then the provider attempts to obtain new credentials from a temporary Subject by invoking a JAAS login itself. It uses the text callback handler for input/output with the user, and the JAAS configuration entry identified by"other" for the the list of modules and options to use 2. It assumes that one of these modules will be a Kerberos login module. It is possible to configure the modules listed under "other" to read a pre-existing cache so that the user is not unexpectedly prompted for a password in the middle of a Java GSS-API call. The new Subject that is populated by this login is discarded by the Kerberos GSS-API mechanism just as soon as the required credentials are retrieved from it.

WEB-BROWSER INTEGRATION

An important class of applications that should be able to capitalize on Java single sign-on are applets. For this discussion we assume that the browser JRE has all the required packages or the Java plugin is used with a Merlin JRE installed by the user.
One complication in using applets arises mostly out of the fact that before an applet can use Java GSS-API, it must perform a JAAS login. The main problems with this are (a) an increase in the effort required on the part of the applet developer (b)unnecessary repeated login by the same user each time he or she starts an applet.
A good model to solve this problem would be to have the browser (or the Java plugin) perform a JAAS login once at startup. This would provide a Subject that could always be associated with the access control context whenever any Java code was run. As a result, the applet code would not need to perform a JAAS login prior to using Java GSS-API, and the user login would occur just once.
In the absence of this login functionality in the browser (or Java plugin), applets can still avoid having to perform a JAAS login themselves. To do so, the applets would have to set thejavax.security.auth.useSubjectCredsOnly system property to false and use a GSS-API mechanism provider that is capable of obtaining credentials from sources other than current Subject. When using a Sun JRE with a Sun Kerberos GSS-API provider, expect the mechanism to perform a JAAS login to obtain new credentials as explained in the previous section. The applet deployer would only need to ensure that the appropriate modules and options are listed in the entry "other" in the JAAS configuration used by the JRE. This saves the applet developer from calling into JAAS API's directly, but it does not stop the repeated JAAS login that might happen with each applet the user runs. However, by configuring the login modules to read a pre-existing native cache, the deployer can both hide the login from the user, and minimize the overhead in the multiple logins. (See how this is done for the the JAAS configuration entry "SampleClient" in Figure 1.)

SECURITY RISKS

The convenience of single sign-on also introduces new risks. What happens if a malicious user gains access to your unattended desktop from where he or she can start applets as you? What happens if malicious applets sign on as you to services that they are not supposed to?
For the former, we have no solution but to caution you against leaving your workstation unlocked! For the latter, we have many authorizations checks in place.
To illustrate some details of the permissions model consider an example where your browser has performed a JAAS login at startup time and associated a Subject with all applets that run in it.
The Subject is protected from rogue applets by means of the javax.security.auth.AuthPermission class. This permission is checked whenever code tries to obtain a reference to the Subject associated with any access control context.
Even if an applet were given access to a Subject, it needs a javax.security.auth.PrivateCredentialPermission to actually read the sensitive private credentials stored in it.
Other kinds of checks are to be done by Java GSS-API mechanism providers as they read credentials and establish security contexts on behalf of the credential's owner. In order to support the Kerberos V5 mechanism, two new permission classes have been added with the package javax.security.auth.kerberos:ServicePermission(String servicePrinicipal, String action)
DelegationPermission(String principals)

As new GSS-API mechanisms are standardized for J2SE, more packages will be added that contain relevant permission classes for providers of those mechanisms.
The Kerberos GSS-API mechanism permission checks take place at the following points in the program's execution:

Credential Acquisition

The GSSManager.createCredential() method obtains mechanism specific credential elements from a cache such as the current Subject and stores them in a GSSCredential container. Allowing applets to acquire GSSCredential freely, even if they cannot use them to do much, is undesirable. Doing so leaks information about the existence of user and service principals. Thus, before an application can acquire a GSSCredential with any Kerberos credential elements in it, a ServicePermission check is made.
On the client side, a successful GSSCredential acquisition implies that a TGT has been accessed from a cache. Thus the following ServicePermission is checked:ServicePermission("krbtgt/FOO.COM@FOO.COM", "initiate");

The service principal krbtgt/FOO.COM@FOO.COM represents the ticket granting service (TGS) in the Kerberos realm FOO.COM, and the action "initiate" suggests that a ticket to this service is being accessed. The TGS service principal will always be used in this permission check at the time of client side credential acquisition.
On the server side, a successful GSSCredential acquisition implies that a secret key has been accessed from a cache. Thus the following ServicePermission is checked:ServicePermission("nfs/bar.foo.com@FOO.COM", "accept");

Here the service principal nfs/bar.foo.com represents the Kerberos service principal and the action "accept" suggests that the secret key for this service is being requested.

Context Establishment

An applet that has permissions to contact a particular server, say the LDAP server, must not instead contact a different server such as the FTP server. Of course, the applet might be restricted from doing so with the help of SocketPermission. However, it is possible to use ServicePermission to restrict it from authenticating using your identity, even if the network connection was permitted.
When the Kerberos mechanism provider is about to initiate context establishment it checks the ServicePermission:ServicePermission("ftp@FOO.COM", "initiate");

This check prevents unauthorized code from obtaining and using a Kerberos service ticket for the principal ftp@FOO.COM.
Providing limited access to specific service principals using this permission is still dangerous. Downloaded code is allowed to communicate back with the host it originated from. A malicious applet could send back the initial GSS-API output token that contains a KerberosTicket encrypted in the target service principal's long-term secret key, thus exposing it to an offline dictionary attack. For this reason it is not advisable to grant any "initiate" ServicePermission to code downloaded from untrusted sites.
On the server side, the permission to use the secret key to accept incoming security context establishment requests is already checked during credential acquisition. Hence, no checks are made in the context establishment stage.

Credential Delegation

An applet that has permission to establish a security context with a server on your behalf also has the ability to request that your credentials be delegated to that server. But not all servers are trusted to the extent that your credentials can be delegated to them. Thus, before a Kerberos provider obtains a delegated credential to send to the peer, it checks the following permission:DelegationPermission(" \"ftp@FOO.COM\" \"krbtgt/FOO.COM@FOO.COM\" ");

This permission allows the Kerberos service principal ftp@FOO.COM to receive a forwarded TGT (represented by the ticket granting service krbtgt/FOO.COM@FOO.COM)3.

CONCLUSIONS

In this paper we have presented a framework to enable single sign-on in Java. This requires sharing of credentials between JAAS which does the initial authentication to obtain credentials, and Java GSS-API which uses those credentials to communicate securely over the wire. We have focused on Kerberos V5 as the underlying security mechanism, but JAAS's stackable architecture and Java GSS-API's multi-mechanism nature allow us to use any number of different mechanisms simultaneously.
The Kerberos login module for JAAS is capable of reading native caches so that users do not have to authenticate themselves beyond desktop login on platforms that support Kerberos. Moreover, the Kerberos V5 mechanism for Java GSS-API allows credentials to be delegated which enables single sign-on in multi-tier environments.
Finally, a number of permissions checks are shown to prevent the unauthorized use of the single-sign on features provided by Kerberos.

ACKNOWLEDGMENTS

We thank Gary Ellison, Charlie Lai, and Jeff Nisewanger for their contribution at each stage of the Kerberos single sign-on project. JAAS 1.0 was implemented by Charlie as an optional package for Kestrel (J2SE 1.3). Gary has been instrumental in designing the permissions model for the Kerberos Java GSS-API mechanism. We are grateful to Bob Scheifler for his feedback on integrating JAAS 1.0 into Merlin and to Tim Blackman for the KeyStoreLoginModule and CallbackHandler implementations. We also thank Bruce Rich, Tony Nadalin, Thomas Owusu and Yanni Zhang for their comments and suggestions. We thank Mary Dageforde for the documentation and tutorials. Sriramulu Lakkaraju, Stuart Ke and Shital Shisode contributed tests for the projects. Maxine Erlund provided management support for the project.

REFERENCES


## Neuman, Clifford and Tso, Theodore (1994). Kerberos: An Authentication Service for Computer Networks, IEEE Communications, volume 39 pages 33-38 

      1. J.Kohl and C.Neuman. The Kerberos Network Authentication Service (V5) Internet Engineering Task Force, September 1993 Request for Comments 1510 
      2. V. Samar and C. Lai. Making Login Services Independent from Authentication Technologies. In Proceedings of the SunSoft Developer's Conference, March 1996. 
      3. X/Open Single Sign-On Service (XSSO) - Pluggable Authentication. Preliminary Specification P702, The Open Group, June 1997. http://www.opengroup.org 
      4. A Smart Card Login Module for Java Authentication and Authorization Service. http://www.gemplus.fr/developers/technologies/smartjaas 
      5. J. Linn. Generic Security Service Application Program Interface,Version 2. Internet Engineering Task Force, January 2000 Request for Comments 2743 
      6. J. Linn. The Kerberos Version 5 GSS-API Mechanism. Internet Engineering Task Force, June 1996 Request for Comments 1964 
      7. C.Adams. The Simple Public-Key GSS-API Mechanism (SPKM). Internet Engineering Task Force, October 1996 Request for Comments 2025 
      8. J. Kabat and M.Upadhyay. Generic Security Service API Version 2: Java Bindings. Internet Engineering Task Force, January 1997 Request for Comments 2853 
      9. JSR 000072 Generic Security Services API http://java.sun.com/aboutJava/communityprocess/final-draft/jsr072/index.html 
      10. JavaTM 2 Platform, Standard Edition, v 1.4 API Specification. http://java.sun.com/j2se/1.4/docs/api/overview-summary.html

 

以下内容转载自：维基百科，自由的百科全书：http://zh.wikipedia.org/wiki/Active_Directory

活动目录（中国大陆译名为“活动目录”，台湾则是维持英文不译）是微软Windows Server中，负责架构中大型网络环境的集中式目录管理服务（Directory Services），在Windows 2000 Server开始内置于Windows Server产品中，它处理了在组织中的网络对象，对象可以是用户，组群，电脑，网域控制站，邮件，设置档，组织单元，树系等等，只要是在活动目录结构定义档（schema）中定义的对象，就可以存储在活动目录数据档中，并利用活动目录 Service Interface 来访问，实际上，许多活动目录的管理工具都是利用这个接口来调用并使用活动目录的数据。

活动目录也被做为微软部分服务器软件与网域构连的数据结构，例如Microsoft Exchange Server 2003-2007，均使用 AD 来存储其个人邮箱数据（通过创建新的活动目录 Schema），并将 AD 列为建置Exchange Server的必要条件。

活动目录最早在1996年出现，并在Windows 2000中首次问世，研发代号为Cascade，并历经Windows 2000, Windows Server 2003的演化，目前 AD 已成为成熟的目录服务组件，在 Windows Server 2008中，AD 更扩充其角色至五种服务（包含凭证、联邦、权限控管与轻量级服务等）。

 

 

目录结构[编辑]

活动目录（AD）以树状的数据结构来组成网络服务的信息，在简单的网络环境中（例如小公司），通常网域都只有一个，在中型或大型的网络中，网域可能会有很多个，或是和其他公司或组织的 AD 相互链接（此链接称为信任关系，于后面帮助）。

对象[编辑]

活动目录的最小存储单元为对象（object），每个对象均有自己的 schema 属性，可以存储不同的数据，像是用户、组群、电脑、邮箱或其他的基本对象等。

一个 AD 网域底下的基本对象，有：

  • Domain Controllers，存储网域所属的网域控制站（简称 设备上下文、域控）。
  • Computers，存储加入网域的电脑对象。
  • Builtin，存储内置的账户组群。
  • Users，存储 AD 中的用户对象。

若公司需要以不同的组织结构来管理公司的账户，则可以在 AD 中创建一个或多个组织单元（Organization Unit，简称 OU），组织单元是一个具有收纳能力的活动目录对象（其在 ADSI 中是 IADsContainer 接口），可以在 OU 之中存放 AD 的对象，包括用户，组群，电脑等，让组织结构在 AD 中可以被真实的反映出来，而且也方便 AD 中的另一个功能——组群原则（Group Policy）的套用与集中管理。

树系与多网域[编辑]

一个活动目录网域树的结构
一个内含子网域的活动目录网域树的结构

若组织的网络环境相当庞大与复杂时，网域可能会有许多个，在 AD 之中，网域可以有一个或多个，而一个大型公司可能会利用分公司或是办公室的方式来组织网域对象，如此一来，在 AD 中会有数个网域，若需要在网域中共享数据或是做委派管理与组态设置时，便需要创建彼此间的组织关系，微软将 AD 中多网域相互的关系层次结构化，称为网域树（domain tree），网域树结构以 DNS 识别方式来区分，例如一间公司可能有业务部门，工程部门与管理部门，那么若要以部门来创建网域时，则可以如此创建（如右图）：

  • acme.com.tw：根网域。
  • sales.acme.com.tw：业务部门。
  • engineering.acme.com.tw：工程部门。
  • admin.acme.com.tw：管理部门。

如此便可在 AD 中反映出组织的结构，同样的，网域内还是可以再创建不同的网域，例如在工程部门中若需要分为软件部门与硬件部门时，还可以在工程部门的网域中创建：

  • software.engineering.acme.com.tw：软件部门的网域。
  • hardware.engineering.acme.com.tw：硬件部门的网域。

而在工程部门网域中的组群原则设置，会自动的继承至软件部门和硬件部门的设置，而在软件部门的组态，则不会影响到硬件部门（可经过设置来套用）。

森林[编辑]

一个活动目录森林结构

在多个网域的环境下，可能在不同的网域之间会需要交换与共享数据，像是组态设置、用户账户与组群原则设置等，在这个时候需要有一个角色来做为不同网域间的信息交换角色，同时又必须要符合 AD 树状结构的规范，因此微软在多网域之间创建了一个中介用的角色，称为森林（Forest），一个组织中最多只能有一个 Forest，在 Forest 下则是各自的网域树系，而在 Forest 下的网域或网域树系间，可以共享信息。

实体结构[编辑]

活动目录背后，则是一个植基于 Windows Server 网络基础结构（infrastructure）的网络服务与通信方式所组成，这些网络服务和通信方式让活动目录具有高度的扩充性与向后兼容性等，网络管理人员必须要妥适的设置与监控这些网络服务与通信方式，以让活动目录能够正常且顺利的运作。

在以往的Windows NT网域环境中，网域的实体结构分为三种角色，即主要网域控制站（Primary Domain Controller, P设备上下文）、备份网域控制站（Backup Domain Controller, B设备上下文）以及成员服务器（Member Server）三种，网域的数据都存储在P设备上下文和B设备上下文中，并且在P设备上下文和B设备上下文间交换数据，但P设备上下文和B设备上下文的部署方式并不方便（一个网域只能有一个 P设备上下文），在不同的地理环境中也不能设置P设备上下文，而且所有网域的查询都会被导向 P设备上下文，如此很容易造成网域登录和访问的塞车情况，这个问题在活动目录中已获得改善，即不再有 B设备上下文（只有 设备上下文 和 Member Server 两种角色），在网域中的任何一台网域控制站都可以负责处理来自客户端的网域查询，如此在分散部署上会具有相当的弹性。

Global Catalog[编辑]

在 AD 的实体结构中，最重要的角色非Global Catalog[1]（全局目录，简称 GC）莫属，它存储了最完整的活动目录的结构数据，也是以目录为主（directory-enabled）的应用程序对 AD 的查询的主要目标，而通常在不同的地理位置（例如在中国大陆、台湾、美国和英国各有分公司，且各有网域）时，GC 扮演了重要的高速缓存结构角色，若台湾的员工出差到英国分公司，并试图登录网域时，Windows会先搜索最近的Global Catalog Server（由 DNS 设置提供），若找不到时，才会链接到其他地区的 GC，但若分公司的网络很慢时，这种跨地理位置的 AD 数据访问会直接影响到登录的时间，因此谨慎的 GC 的布署对 AD 的推行是很重要的。

Operation Masters[编辑]

营运主机（Operation Masters，又称为Flexible Single Master Operation，即FSMO）[2] 是被设置为担任提供特定角色信息的网域控制站，在每一个活动目录网域中，至少会存在三种营运主机的角色。

  • Primary Domain Controller Emulator Master：设置作为这个角色的网域控制站，可以被目前仍存在网域中的Windows NT Backup Domain Controller (备份网域控制站) 当做 Primary Domain Controller (主要网域控制站) 来调用使用，同时它也是树系中提供Windows Time Service时间同步的主机。
  • RID Master：在网域控制站中会存储 AD 对象的 relative ID（关系识别码），可分散以 RID 为主的查询的流量。
  • Infrastructure Master：负责处理对目前网域的对象参考，以及对应其他网域的对象参考，并可负责处理针对 AD 对象的变更（例如删除与更名）。

另外还有两种角色，是具有额外功能，但不强制部署在网域的：

  • Schema Master：负责处理网域中所有针对对象结构的变更。
  • Domain Naming Master：负责处理网域中的目录分区以及应用目录分区的工作。

Site[编辑]

活动目录站台（site），是指一个实体的网络位置，在一个站台中可能会有很多个网域控制站，AD 网域数据的复制，就是以站台为主，实际处理复制作业的工具称为 KCC（Knowledge Consistency Checker，知识一致性检查器），它会在特定时间对站台设置中的网域进行数据的同步化，复制活动则分为对内复制（intra-site replication）与对外复制（或站间复制，inter-site replication），对内复制是同一个网域间的控制站交换信息，对外复制则是在网络管理人员的设置下，通过指定的通信方法（IP 或 SMTP）以及拓朴进行复制。

默认情况下，站台的通信方式是使用 IP（即 RPC over IP）来通信，这个方式是最快的，且可以利用 TCP/IP 来运行远程调用以及处理，但若是非网域数据（架构、设置和通用类型目录更新，亦即没有 AD 对象）的复制，则可以利用 SMTP 通信方法，但这个方法需要另外创建企业级的凭证服务才可以使用，目的是确保 SMTP 的数据可以被确认与保全。

在中大型的网络环境中，适当的分散网络流量以及设计网络拓朴是很重要的事，KCC 会利用设置好的网络通信成本（cost）来选择要用哪一条网络来进行复制，例如可能公司和办公室间有一条 T1 和 ISDN 64Kbps 的线路，而 T1 的成本设为 500（因为会有很大流量），而 ISDN 只有 100 时，KCC 会选择 ISDN 做复制，这样代表网络管理员可以自己决定要使用哪一条网络来进行复制，KCC 的复制算法会判断哪一个网络最适合复制 AD 的数据。除了成本以外，AD 也支持了桥接站台（site bridge）的结构，站台桥接能力让复制的成本得以分散，并可让同一台 GC 的复制流量分散，也适合在不同地理区域之间的 AD 信息复制与散发工作。

DNS[编辑]

活动目录极度依赖DNS，因为 DNS 可以让 AD 表现出层次结构化的树状结构，同时也可以和开放的目录标准接轨，因此在建置网域时，DNS 服务（或另有架设 DNS Server）一定要存在于网络或该网域控制站中，AD 以 SRV 记录（SRV Record）来识别网域控制站，以提供网域处理的服务，而和Windows NT网域不同的是，Windows NT使用的是 NetBIOS 通信协议，但 AD 使用的则是TCP/IP，但 AD 仍然提供可以在 Windows NT 账户格式（DOMAIN\User）和 AD 账户格式（user@domain）的格式互转。

实体存储[编辑]

活动目录使用强化过的Microsoft Jet Database Engine（基于 Microsoft Jet Blue 计划），即Extensible Storage Engine（ESE98），可存储 16TB 的数据量，理论上可容纳十亿个网域对象，文件名称为 NTDS.dit，它存储在 %system_root%\NTDS 目录中（这个目录所在的磁盘也必须要是NTFS格式），内含了对象数据表以及链接数据表，在Windows Server 2003中加入了一个描述安全信息的新数据表。

而在 AD 更新数据时的记录，都被存储在 edb*.log，默认的名称为 edb.log，其他的文件使用 "edb" + 数字 + ".log" 来记录，另搭配了 edb.chk 作为检查点记录档，以及 Res1.log 和 Res2.log 作为系统的保留文件。

AD 实体存储的组件有[3]：

  • 上层接口（interface）：作为目录服务客户端或目录服务中的其他服务器的连接接口，像是 LDAP、REPL、MAPI 与 SAM 等。
  • 目录服务代理人（Directory Service Agent）：实现于 NTDSA.DLL，负责接收与处理来自客户端的要求或其他服务器的要求（例如 KCC 的要求）。
  • 数据库访问层：内含于 ntdsa.dll 中，负责直接访问数据库。
  • 延伸存储引擎（Extensible Storage Engine）：负责处理数据库与其名称（DN）的记录对应。
  • 数据库文件：即 NTDS.dit，以及负责处理未认可交易的记录档。

网域控制站会定时（默认为 12 小时）对 NTDS.dit 做重组（defragment），并清除数据档中的垃圾，在重组前会检查磁盘空间是否有大于数据库文件 1.5 倍的空间可用。若数据库所在的目录没有足够的可用空间，就要把数据库移往其他地方去。然而，由于Windows 2000与Windows Server 2003在卷影复制服务（VSS）的机制有所不同，使这移动过程有可能失败。对于Windows 2000，log files与数据库可以分别存放在不同的磁盘上，但Windows Server 2003则必须放在同一个磁盘上。要移动数据库，必须重新启动服务器，并进入活动目录 Restore Mode里，利用ntdsutil工具进行移动。

只读网域控制站[编辑]

在Windows Server 2008中，加入了一个新的网域控制站角色，称为只读型网域控制站（Read-Only Domain Controller，简称 RO设备上下文），RO设备上下文 可以作为组织的分部、分公司、办公室或是临时单位等，将网域控制站放在该处时会有安全性疑虑或风险时使用，顾名思义，RO设备上下文 不会写入任何数据到活动目录，与其他网域的复写也是有限度的，并且只会以系统管理员定义的 Password Replication Policy（密码复制原则）控制下的账户才会高速缓存密码等功能。

若要在 AD 中加入只读网域控制站，则网域的功能层级必须要在 Windows Server 2003 以上。

安全性[编辑]

活动目录的安全性可分为对象的安全性识别、层次结构的安全性以及森林之间的信任关系等。

安全性识别[编辑]

主条目：Windows 安全性识别码

AD 以Kerberos V5作为其安全验证的主要架构，并且每个 AD 对象都拥有一个独一无二的安全性识别码（Security Identifier，SID），其格式示例为 S-1-5-21-7623811015-3361044348-030300820-1013，每组代码均有其意义，这组识别码存储在 AD 的 objectSid 属性中。

层次结构的安全性[编辑]

在 AD 中，不同层次结构的 OU 可以定义不同的安全性信息，以及不同的用户权限，而不同的网域层次结构之间也可以定义不同的用户权限，管理员也可以利用安全性管理范本（Secutiy Template）来定义不同的安全性信息，或者使用组群原则（Group Policy）来定义，在大型网络之中，使用组群原则会比安全性范本要来的方便，将两者合并使用更可达到事半功倍之效（例如和 Microsoft Base Security Analyzer 的集成）。

在父层次结构定义的安全性，可以被继承至子层次结构。

信任关系[编辑]

在大型的网络环境中，可能组织间有伙伴关系，或者是项目间的合作，而需要在两个 Forest 间共享或授权访问时，可以利用信任关系（trust relationship）来创建 Forest 间的信任，以授权在彼此树系间的访问权，在Windows Server 2003以后版本的 AD 环境可支持四种信任关系：

  • 快捷方式式信任（shortcut trust），此为加速验证流程所设计的信任法，在多层次的网域中，用户只要连接到最近的网域即可登录，无需要将信息转到授权的根服器。
  • 外部式信任（external trust），此为跨森林的授权方法。
  • 领域式信任（realm trust），作为与非 Kerberos 验证的 LDAP 目录服务与 Windows 网域的信任模式。
  • 森林式信任（forest trust），此为强化型的外部式信任法，可以经由一个中介的森林信任来取得信任关系，例如 acme.com.tw 信任 aspvendor.com，而 contoso.com.tw 也信任 aspvendor.com，则 acme.com.tw 可以取得和 contoso.com.tw 的信任关系。

信任关系的设置可以分为单向（one-way）和双向（two-way）两种，单向信任表示被信任的一方可以访问信任的一方的资源，而双向信任则是可以访问各自的资源。

信任关系的传递可分为可递移（transitive）与不可递移（non-transitive）两种，可递移表示创建信任关系的网域在同一树系内的其他网域也可以使用在创建信任关系网域中的信任信息，不可递移则表示只有创建信任关系的网域（不论是否有层次结构）才可以使用信任信息。

名称系统[编辑]

活动目录的命名默认是以LDAP（轻量级目录访问协议）版本的X.500协议为主（由 ADSI LDAP Directory Service Provider），对于 AD 这种如此规模的目录服务而言，LDAP 这种具有层次结构识别能力的协议，非常适合作为目录服务的访问协议，但 AD 亦可以支持 NT 时代的 UNC 格式（由 ADSI Windows NT Directory Service Provider 提供），在 UNC 与 LDAP 名称间的转换则由 ADSI 的IADsNameTranslate接口来提供。

识别名[编辑]

每个 AD 对象均有一个以 LDAP 组成的名称，称为识别名（Distinguished name，简称DN），这个识别名是作为使用 LDAP 查询 AD 目录中识别对象的名称，其格式类似下列：

LDAP://cn=John Smith, ou=Software Engineering, dc=engineering, dc=acme, dc=com, dc=tw
LDAP://cn=COMP1024, ou=Computers, dc=acme, dc=com, dc=tw

在 LDAP 字符串中经常使用的代字有：

  • 设备上下文：domainComponent
  • CN：commonName
  • OU：organizationalUnitName
  • O：organizationName
  • STREET：streetAddress
  • L：localityName
  • ST：stateOrProvinceName
  • C：countryName
  • UID：userid

当客户端在下达 LDAP 查询字符串时，若无法符合 AD 对象的 LDAP DN，则会找不到数据，LDAP 代字亦可使用于搜索（IADsDSObject与ADsDSObject()，参见活动目录 Service Interface条目）。

一般名称[编辑]

每个 AD 中的对象都会有一个一般的名称，又称为别名（Canonical Name），在 Schema 中的属性为 cn（Common Name），但组织单元（OU）基本上是例外，它自己有一个代字 ou 作为识别符。

关系识别名称[编辑]

为了要在容器与对象间作识别，在 Schema 中设置了一个 Relative Distinguished name（简称 RDN），存储在 rDnAttId 属性中，可在搜索 AD 时可以快速的对应容器内的对象。

GUID[编辑]

每一个对象都有一个唯一的 GUID 对象识别码，存储在 objectGUID 属性中，其编码方式与GUID相同。

其他名称[编辑]

  • Windows NT用户名称系统：即 SAM（Security Account Manager）的名称系统，存储在用户的sAMAccountName属性中。
  • 用户主体名称：即User Principal Name，在 AD 中用户是以user@domain的方式呈现，这个值存储在userPrincipalName属性。

功能层次[编辑]

活动目录于是一个开放式的目录服务，而且为了要能够容纳不同版本的 Windows 操作系统以及其网域，因此特别在 AD 中使用了一种版本控制的机制，称为功能层次（functional level），功能层次定义了目前在网域环境中可以使用的最大版本层次，同时这个修改是单向无法撤消的修改。若网域中有不同版本操作系统的网域控制站，则为了最大的兼容性，功能层次的设置应要以最低版本为主，例如一个网域中有 Windows Server 2003 和 Windows 2000 时，则网域的功能层次应该设为 Windows 2000 混合模式（Mixed Mode），若设为 Windows Server 2003 原生模式（Native Mode）时，Windows 2000 的网域控制站会失效。但由于新版本的 AD 设置通常都会比前版的要强（尤其是安全性的改进），因此若网域中没有前版本的操作系统，则应将功能层次设置到最新版本，以开放 AD 的所有功能。

另外，若要在网域中安装新版本的操作系统（例如在 Windows Server 2003 网域中要安装 Windows Server 2008）作为网域控制站时，必须要先将 活动目录 中的 Schema 信息做扩充以兼容于较新版本的操作系统，因此微软在安装光盘中都会提供一个 活动目录 准备工具 (adprep.exe)，它可以让系统管理员以简单的方式升级 活动目录 中的数据结构，包含树系以及网域的数据结构（使用首选项），以兼容于新版本操作系统。

  • adprep /forestprep：升级树系的数据结构。
  • adprep /domainprep：升级网域的数据结构。
  • adprep /rodcprep：准备网域以提供 RO设备上下文（只读网域控制站）的功能（Windows Server 2008 以后版本才支持）。

对于 Windows NT 的 B设备上下文，则不是通过功能层次的设置，而是用 Operation Master 的 P设备上下文 Emulator 来保持兼容性。

对象结构[编辑]

由于微软在设计活动目录是使用开放型的目录服务为方针，且目录服务的最基本特性之一就是要能“广纳百川”，除了基本的网络服务数据外，还需要能够和其他异质型服务连接与集成，因此微软在 AD 之中实现了一个对象的存储单位，称为“对象结构”（schema），对象结构可以视为 AD 对象的元数据（metadata）。每一个对象（不论是单元或是容器对象）都有各自的 schema，用以存储识别该对象的不同数据，schema 是由 class 和 attribute 所组成，attribute 是最小的存储单元，class 则是包含 attribute 的集合体。

存储在 attribute 中的数据有很多种格式，微软将这些格式定义成 27 种 Schema 数据型态，像是指示账户过期日的Account-Expires属性，其值是 interval 数据型态（代表时间周期，为一个64位整数值），又如指示账户 SAM 名称的sAMAccountName 属性，其值是 String(Unicode)值（支持 Unicode 的字符串值），又如存储用户的照片的Picture属性，其值是 Object(Repl-Link)（代表是字节数据，且可以复制到其他网域控制站）。

微软也开放了可扩展 schema 的方法[4]，开发人员可以利用这一套方法来延伸活动目录 Schema中的数据，但一旦写入 AD 后，即不可删除（因为对象识别码不可更动），但是可以停用，延伸 AD Schema 最好的例子就是Microsoft Exchange Server。

服务[编辑]

活动目录本身除基本的网络目录服务外，微软也应用这个基础架构设计了不同的服务，并且在Windows Server 2003不同的版次中加入，以提升活动目录的应用范围。

联邦服务[编辑]

由于 AD 本身具有可分散式的身份验证与授权能力，且在 2003 年时 Web 正吹起了单一签入（single-sign on）的架构研究风，微软也开始利用 AD 来设计一个可支持多个网站（或应用程序）的单一签入功能，其实现品即为活动目录 Federation Services（AD 联邦服务，简称 ADFS），它显露了几个主要成员[5]：

  • Federation Service：负责在 ADFS 的 SSO 架构中处理验证的服务器。
  • Federation Service Proxy：在外部网络或是 WS-I 服务中，扮演Federation Service的代理角色，并支持WS-Federation规格的验证设置。
  • Claim-aware client：由 ADFS 开放的Claim-aware（声明感知）组件的 Web 客户端，或是 ASP.NET 应用程序，可直接支持 ADFS 的 SSO 架构。
  • Windows Token-based Agent：以Windows验证为主的 Web 应用程序，ADFS 可支持 AD 权仗与Windows NT权仗的模拟与交换。

此服务在Windows Server 2003 R2版本中首次出现，并在Windows Server 2008中升级为活动目录 Federation Service角色。

轻量级服务[编辑]

轻量级服务（Lightweight Directory Service）[6] 在Windows Server 2003中被称为活动目录 Application Mode（ADAM），它是一个不需要与 AD 基础架构集成就可以独立运作的目录服务，适合用来表现企业的层次结构化概念与对象的管理，而且开发人员只要把使用 ADSI 的经验搬过来即可使用，不必另外学习 ADAM 的操作方法，它也可以做为 ADFS 的外部验证提供者。轻量级目录可以在同一台电脑中安装多个运行个体，因此也很适合用 ADAM 来实现 Directory-Enabled 的应用程序，尤其是与组织结构相关的（例如人事或人力资源系统），ADAM 本身也可以延伸schema，开发人员可以将 ADAM 视为另一种型式的数据库，也可以由 AD 中复制数据到 ADAM，不过 ADAM 不会对 AD 进行站台复制，开发人员需要自行撰写程序来复制数据。

轻量级服务在 Windows Server 2008 中改名为活动目录 Lightweight Directory Service（简称 AD LDS），并提升为 AD 的应用角色之一。

凭证服务[编辑]

凭证服务（Certificate Service）[7] 是在Windows Server 2008中首次纳入活动目录体系的服务，它原本是在Windows 2000与Windows Server 2003的凭证服务器（Certificate Server），用来创建企业中的公开密钥基础建设，在Windows Server 2008中，凭证和 AD 对象有了更强更紧密的集成，所以有了活动目录 Certificate Service（AD CS）的角色，这个角色还可以和权限管理的Right Management Service（RMS）集成在一起，提供对文档或应用程序层次的权利管理。

权利管理服务[编辑]

权利管理服务（Right Management Service）[8] 也是在Windows Server 2008中首次纳入活动目录体系的服务，最早的时候，它是在Microsoft Office 2003 开始提出的信息权利管理（Information Right Management）功能，可利用它来控制 Office 文档散布时的权限，例如打印以及存储文件等，接着微软发表了Right Management Server以及RMS SDK，供Windows Server 2003平台使用，而在Windows Server 2008中即将它集成到活动目录中，变成 AD 服务的一部分。

集成Unix到活动目录中[编辑]

活动目录互通的多样性层次得以通过符合标准的 LDAP 客户端在大多数的类Unix操作系统记录，但这些系统通常缺乏与 Windows 组件像是组群原则与单向信任关系的许多属性的自动直译，目前也有许多第三方软件厂商提供了将 Unix 平台（包含 UNIX、Linux、Mac OS X 与数个 Java 与 Unix-based 应用程序）集成活动目录方法，这些供应商的一部分，包含 Thursby Software System（ADmitMac）, Quest Software（Vintela Authentication Services）, Centrify（DirectControl），与 Likewise Software（Likewise Open and Likewise Enterprise）。Microsoft 也在这个市场中拥有为 UNIX 产品所设计的免费Microsoft Windows服务（即 Windows Service for Unix）。

这些额外的对象结构在 Windows Server 2003 R2 版本中被发布，包含完全对应到 RFC 2307 的一般用途的属性。这些 RFC 2307、nss_ldap 与 pam_ldap 的参考实现均提供自 PADL.com，包含直接使用这属性以及填充信息的支持。默认组群成员（group membership）的活动目录 Schema与被提议的 RFC 2307bis 延伸功能一起编译。RFC 2307bis 使用 LDAP 成员属性存储 Unix 的组群成员数据，与基础 RFC 2307，以存储组群成员为以逗号分隔的用户识别码菜单有所不同。Windows Server 2003 R2 包含了一个MMC snap-in 以创建与编辑这些属性。

一个替代选项是使用其他的目录服务，像是 Fedora Directory Server（之前的 Netscape Directory Server）或是Sun的 Java System Directory Server，它可以运行与活动目录双向同步化，进而在需要使用 FDS 验证的 Unix 与 Linux 平台与需要使用 Windows 验证的 Windows 客户端之间，提供一个与活动目录之间转向（deflected）的集成。另一个选项是使用OpenLDAP以及它的透通覆盖（translucent overlay）功能得以延伸项目于使用额外属性存储在本地数据库的任何远程 LDAP 服务器上。在本地数据库中指示的客户端将会看到包含在远程和地的属性，当远程数据库仍保持完整不变的情况下。

Samba 4，截至2008年8月8日止仍在测试，并计划包含一个活动目录兼容服务器。

参考文献[编辑]

  1. ^ Global Catalogs
  2. ^ Operation Masters
  3. ^ Directory Data Store
  4. ^ Extending the schema
  5. ^ Directory Federation Services 概观
  6. ^ Directory 轻量型目录服务概观
  7. ^ Directory 凭证服务概观
  8. ^ Directory Rights Management Services 概观

外部链接[编辑]

  1. （英文） Windows Server 2003 Technical Library:活动目录 Collection
  2. （英文） Infrastructure Planning and Design:活动目录 Domain Services
  3. （正体中文） Windows Server 2008 活动目录
  4. 微软活动目录产品官方网页
  5. WINS（Windows Internet Naming Service）
  6. 分布式管理任务课题组
  7. Linux 系统上的活动目录
posted @ 2014-01-17 22:44  sxjd  阅读(6688)  评论(0)    收藏  举报