Export (0) Print
Expand All
3 out of 3 rated this helpful - Rate this topic

Understanding ADAM users and groups

Updated: August 22, 2005

Applies To: Windows Server 2003 R2

Users and groups

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

Default groups

ADAM 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, ADAM 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 ADAM 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:

ADAM administrators assigned during ADAM setup

Application partitions:

Administrators group from the configuration partition

Full access to all partitions

Instances

(CN=Instances, CN=Roles)

All instances

 

Readers

(CN=Readers, CN=Roles)

None

Read access to the partition

Users

(CN=Users, CN=Roles)

Configuration partition:

Transitively, all ADAM users

Application partitions:

Transitively, all ADAM users created in the partition

None

Groups from the configuration partition can be assigned permissions in any partition of an ADAM 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 application 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 ADAM, security principals can reside in ADAM, on a local computer, or in an Active Directory domain.

noteNote
You can retrieve an active user's individual and group SIDs by explicitly querying the tokenGroups attribute on the rootDSE.

ADAM security principals

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

For more information about authentication in ADAM, see Understanding ADAM access control. For information about the optional user classes provided with ADAM, see Administering users and groups.

Windows security principals

ADAM 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 ADAM. In addition, you can add Windows security principals membership to ADAM groups as members. By default, the security principal that you specify as the ADAM administrator during ADAM setup becomes a member of the Administrators group in the configuration partition. For Windows security principals, ADAM 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.

For more information about authentication in ADAM, see Understanding ADAM access control.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

ADD
Show:
© 2014 Microsoft. All rights reserved.