Understanding AD LDS Users and Groups
Applies To: Windows Server 2008
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 first import the user object class definitions that are provided with AD LDS, or you can 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 that are assigned during AD LDS setup Application partitions: The 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 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 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 AD LDS, security principals can reside in AD LDS, on a local computer, or in an Active Directory Domain Services (AD DS) domain.
Note
You can retrieve an active user's individual and group SIDs by explicitly querying the tokenGroups attribute on the rootDSE.
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 that are 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 and the unicodePwd attribute 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.