5.1.1.5 Supported Types of Security Principals

  • Artikel

For AD DS, the concept of "security principal" is straightforward: a security principal is an object in the directory that possesses an objectSid attribute. But for AD LDS, the notion of security principal is more complex, because AD LDS recognizes three distinct types of security principals, any of which can authenticate via an LDAP Bind request:

  • AD LDS security principals that are created in an AD LDS NC.

  • Principals that are defined by the operating system of the computer on which AD LDS is running.

  • Principals that are defined in an Active Directory domain to which the computer on which AD LDS is running is joined, or principals that are in domains that are trusted by the joined domain.

In addition to these three types of security principals, AD LDS also supports bind proxies, which are not security principals but which can be authenticated via an LDAP Bind request. This section will discuss each of the three types of security principals in turn, and follow that with a discussion of bind proxies. Finally, it will conclude with an explanation of which types of LDAP Binds an AD LDS server MUST support for each type of principal and bind proxy.

The first type of security principal in AD LDS is unchanged from AD DS: an object in the directory that possesses an objectSid attribute. However, while AD DS restricts security principals to the domain NC, AD LDS (which has no domain NCs) permits security principals to be stored in an application NC. Additionally, if the ADAMAllowADAMSecurityPrincipalsInConfigPartition configuration setting is supported and equals 1 (section 3.1.1.3.4.7), AD LDS permits security principals to be created in the config NC.

In AD DS, the set of security principal object classes is fixed. In AD LDS, any object class that statically links (section 3.1.1.2.4.6) to the msDS-BindableObject auxiliary class is a security principal object class. Dynamically instantiating the msDS-BindableObject auxiliary class does not have the same effect.

The second and third types of principals are similar to each other in that both are means for AD LDS to "pass through" the Authentication to the underlying operating system on which it is running. AD LDS recognizes as a security principal those security principals (users and groups) that are stored locally on the computer on which AD LDS is running. Additionally, if the computer is a member of a domain, then AD LDS recognizes as security principals any security principals that are in that domain or which are in a domain trusted by that domain. Such security principals can be included in the security descriptors of objects in the AD LDS directory in the same fashion as security principals of the first type. Additionally, such security principals can be included in the membership of group objects in AD LDS, and in the msDS-ServiceAccount attribute of nTDSDSA objects in AD LDS, via the automatic creation of foreignSecurityPrincipal objects (sections 3.1.1.5.2.4 and 3.1.1.5.3.3).

Note that, except for the creation of foreignSecurityPrincipal objects as needed to represent group members or service accounts, the second and third types of principals are not represented as objects in AD LDS. Instead, upon receipt of an LDAP Bind request for such a principal, AD LDS provides the credentials it receives in the Bind request to the host operating system and relies on the host operating system to validate those credentials. The means of passing the received credentials to the host operating system, as well as the method that the host operating system uses to validate those credentials, is implementation-specific.

Bind proxies are objects in AD LDS that contain the msDS-BindProxy auxiliary class. A bind proxy contains an objectSid attribute but is not a security principal. Rather, it is a means of associating an object in AD LDS with a security principal of the underlying operating system (that is, the second or third type of security principal). The objectSid attribute contains the SID of a security principal of the second or third type. When an LDAP Bind request is received in which the object identified in the name field of the BindRequest is an msDS-BindProxy object, the server performs the following actions:

  • Retrieve the value V of the objectSid attribute from the named object.

  • Pass through the Authentication request to the host operating system as a request to authenticate a principal whose SID is V and whose password is as supplied in the LDAP Bind request.

An LDAP Bind request that targets an msDS-BindProxy object O has nearly the same effect as an LDAP Bind request for a security principal S of the second or third type. Instead of directly naming S in the LDAP Bind request, the client names an object O such that O!objectSid equals the SID of S. The security context generated by the two requests is slightly different, as specified in section 5.1.3.4.

In order for an object class to be usable in an LDAP Bind request in AD LDS, that object class MUST either contain the msDS-BindableObject class or the msDS-BindProxy class.

AD LDS servers restrict the authentication mechanisms and protocols that can be used to authenticate different types of security principal and bind proxies. The authentication mechanisms and protocols supported by AD LDS for each type of principal or proxy are specified in the following table.

Type of principal/proxy

Supported authentication mechanism

Supported authentication protocol

First type (AD LDS principal)

Simple

SASL

-

DIGEST-MD5*

Second or third type (computer or domain principal)

SASL

SASL

SASL

SASL

Sicily

GSSAPI

GSS-SPNEGO

DIGEST-MD5

EXTERNAL

NTLM

Bind proxy

Simple

-

* DIGEST-MD5 authentication for AD LDS security principals is supported only when the ADAMDisableSSI configurable setting (section 3.1.1.3.4.7) is supported and is equal to 0. If the ADAMDisableSSI configurable setting is not supported, then DIGEST-MD5 authentication for AD LDS security principals is not supported.

In particular, note that simple bind is not supported for principals of the second or third type, and that DIGEST-MD5 is the only SASL protocol supported for all types of security principals in AD LDS.