188.8.131.52.1 distinguishedName Generation
This section contains constraints pertaining to the generation of a distinguishedName attribute value for objects created through this protocol. This section is referenced by the "create" pattern of methods, section 184.108.40.206. The constraints refer to an AccountType parameter from the referring section; if the object being created has the objectClass of a group, there is no AccountType parameter in the message. In this case, use an Account Type value of USER_NORMAL_ACCOUNT.
If the wellKnownObjects attribute on the account domain object exists and contains a value that matches the GUID associated with Account Type, where Account Type is the AccountType parameter from the message referencing this section, the distinguishedName MUST be suffixed with the associated value from the wellKnownObject attribute. Information about the syntax of the wellKnownObject attribute is specified in [MS-ADTS] section 220.127.116.11. Unless otherwise specified, GUIDs in this document are represented using the string form of a universally unique identifier (UUID), as specified in [RFC4122] section 3.
If the wellKnownObjects attribute does not exist or if there is no match according to constraint 1, the distinguishedName MUST be suffixed with the associated value according to the following table.
CN=Users,<DN of account domain object>
CN=Computers,<DN of account domain object>
CN=Domain Controllers,<DN of account domain object>
The server MUST prefix the RDN directly in front of the suffix determined from steps 1 and 2. Implementations SHOULD<68> use the sAMAccountName as the value for the RDN, with the component type of "CN", if this choice matches the constraints of the distinguishedName attribute.