Share via

Introduction to Administering Authentication and Access Control

  • Article

Applies To: Windows Server 2008

Users and groups

Active Directory Lightweight Directory Services (AD LDS) relies on users and groups to provide and control access to directory data. AD LDS supports the simultaneous use of both Windows users and AD LDS users. AD LDS provides four default, role-based groups. You can create additional AD LDS groups as necessary. Both Windows users and AD LDS users can be members of AD LDS groups. To create AD LDS users in AD LDS, you must either import the user object class definitions that are provided with AD LDS, or supply your own user object definitions.

Default groups

AD LDS provides four default, role-based groups: Administrators, Instances, Readers, and Users. These groups reside in the configuration partition and in each application partition, but not in the schema partition. Within a configuration set, AD LDS replicates these groups, along with all other directory data.

The following three groups reside in the CN=Roles container of each directory partition:

  • Administrators (CN=Administrators, CN=Roles)

  • Readers (CN=Readers, CN=Roles)

  • Users (CN=Users, CN=Roles)

The following group resides only in the CN=Roles container of the configuration directory partition:

  • Instances (CN=Instances, CN=Roles)

The following table lists the default AD LDS groups, along with the default members and default access assigned to each group.

Group Default members Default access

Administrators

(CN=Administrators, CN=Roles)

Configuration partition:

AD LDS administrators assigned during AD LDS setup

Application partitions:

Administrators group from the configuration partition

Full access to all partitions

Instances

(CN=Instances, CN=Roles)

Service accounts of all instances

  

Readers

(CN=Readers, CN=Roles)

None

Read access to the partition

Users

(CN=Users, CN=Roles)

Configuration partition:

Transitively, all AD LDS users

Application partitions:

Transitively, all AD LDS users that are created in the partition

None

Groups from the configuration partition can be assigned permissions in any partition of an AD LDS instance or configuration set. Groups from an application partition can be assigned permissions only in that application partition. Windows security principals can be assigned permissions in any partition.

Security principals

The term security principal refers to any object that has a security identifier (SID) and that can be assigned permissions to directory objects. In AD LDS, security principals can reside in AD LDS, on a local computer, or in an Active Directory domain.

Note

You can retrieve an active user's individual and group SIDs by explicitly querying the tokenGroups attribute on the rootDSE. The value returned includes the SIDs of all the groups of which the user is a member.

AD LDS security principals

AD LDS does not include any default security principals. However, AD LDS does provide importable schema extensions that you can use to create users in AD LDS. Users created from these user classes can be used as security principals. In addition, you can make any object class in the AD LDS schema a security principal by adding the msDS-bindableobject auxiliary class to the schema definition of an object class. Each AD LDS security principal must be assigned an account and password, which AD LDS uses for authentication.

Windows security principals

AD LDS allows the use of Windows security principals for authentication and access control. Local Windows users and groups, as well as domain users and groups, can be used with AD LDS. In addition, you can add Windows security principals membership to AD LDS groups as members. By default, the security principal that you specify as the AD LDS administrator during AD LDS setup becomes a member of the Administrators group in the configuration partition. For Windows security principals, AD LDS relies on the Local Security Authority (LSA) on the local computer (for local accounts) or the LSA on a domain controller (for domain accounts) for authentication.

AD LDS bind redirection

AD LDS bind redirection is designed for use primarily with legacy applications that cannot authenticate directly against Active Directory Domain Services (AD DS) but still have to use AD LDS as the application data store. Through bind redirection, AD LDS can accept a bind request from an application and redirect this bind request to AD DS, based on the contents of a proxy object. A proxy object in AD LDS represents a local Windows or an Active Directory security principal, and it can be augmented to store additional data related to that security principal that is specific to the application. Through bind redirection, applications can take advantage of the identity store of AD DS without any additional overhead. For example, if an administrator disables an account in AD DS, that account can no longer be used to bind to AD LDS. In addition, applications retain the flexibility of using AD LDS as an application data store.

Proxy objects for bind redirection

Bind redirection relies on the existence of stub, or proxy, objects in AD LDS, each of which represents a Windows security principal. To implement bind redirection, first create a proxy object schema definition to store data that is specific to your application. In this definition, include the msDS-bindProxy auxiliary class. The msds-BindProxy class possesses a single "must contain" attribute, ObjectSid, which holds the security ID (SID) of the associated Windows security principal. For more information, see Bind to an AD LDS Instance Through a Proxy Object.

Processing bind requests

When a user sends a bind request to AD LDS, AD LDS does the following based on the type of request:

For simple bind requests:

  • If the object class to which the user requests a bind possesses msDS-bindableObject as a static auxiliary class, AD LDS processes the bind request directly, generating a security context that is based on the AD LDS user's SID.

  • If, instead, the object class to which the user requests a bind possesses the msDS-bindProxy as an auxiliary class, AD LDS redirects the bind request to the host operating system. AD LDS then generates a security context that includes the token that is returned by the host operating system for the Windows security principal in response to the redirection, along with the AD LDS groups in which the principal is a member.

For simple authentication and security layer (SASL) bind requests:

  • The bind request goes directly to the AcceptSecurityContext application programming interface (API) call. AD LDS generates a security context that is based on the token that is returned from AcceptSecurityContext.

Designing applications for bind redirection

Although bind redirection is intended for preexisting, legacy applications, it can also be used with new applications. However, for new and modifiable applications, it is recommended that you write the application to use Windows security principals, rather than proxy objects, for authentication. With this type of design, you can maintain a single sign-on (SSO) solution and prevent the duplication of accounts.

New and modifiable applications

For applications that are currently in development, and for applications that can be updated, it is recommended that you write your applications to authenticate directly against AD DS by using Windows security principals. This type of design provides the highest degree of security, because passwords flow directly from the client to AD DS, rather than through AD LDS. AD LDS can then be used simply as an application-specific data store. Proxy objects in AD LDS can hold application data that is specific to each Windows security principal, and an attribute on the AD LDS proxy object can be used to uniquely link each proxy object to a particular Windows security principal. A unique identifier on a Windows security principal, such as a security ID (SID) or a globally unique identifier (GUID), can be used for this linking. If your application cannot authenticate against AD DS, and you need to synchronize directory contents between AD LDS and Active Directory, you can use a synchronization service, such as Microsoft Identity Integration Server (MIIS). However, this option introduces a delay between the originating update and the synchronization of the update.

Legacy applications

In some cases, you may be running already deployed, directory-enabled applications that cannot be modified. In these cases, your application may send a flat string to the directory, expecting the return of a distinguished name string with which to bind. For this scenario, the AD LDS proxy object can support a unique distinguished name when a user attempts to bind to the proxy object, AD LDS redirects the bind request to the host operating system, rather than processing the request locally.

Password security

Because bind redirection can only be used in conjunction with simple bind requests, any password that is sent to AD LDS as part of a bind redirection is sent in a plaintext, unencrypted format. Therefore, it is strongly recommended that you implement bind redirection only when using an encrypted connection, for example, Secure Sockets Layer (SSL), which is the default setting in AD LDS. For more information, see Appendix A: Configuring LDAP over SSL Requirements for AD LDS.

Additional Considerations

  • Only simple bind requests can be redirected.

  • Bind redirection supports any security principals that are supported by the host operating system of the machine on which AD LDS is running.

  • If both msDS-bindProxy and msDS-bindableObject are specified as auxiliary classes on a single object, msDS-bindableObject takes precedence.