Creating and Deleting Objects in Active Directory Domain Services
The procedure used to programmatically create and delete objects in Active Directory Domain Services is dependent upon the programming technology used. For more information about creating and deleting objects in Active Directory Domain Services with a specific programming technology, see the topics listed in the following table.
Programming technology | For more information |
---|---|
Active Directory Service Interfaces | Creating and Deleting Objects |
Lightweight Directory Access Protocol | Modifying a Directory Entry |
System.DirectoryServices | Create, Delete, Rename and Move Objects |
Creating an Object
In general, the only attributes required for an object to be created are the cn and objectClass attributes. Just creating an object does not necessarily make it a functional object however. Certain types of objects, such as users and groups, have additional required attributes to make them functional. For more information about creating specific types of objects, see Creating a User and Creating Groups in a Domain.
Windows Server 2003: When an object of the user, group, or computer class is created on a domain controller that is running on WWindows Server 2003 or later, the domain controller automatically sets the sAMAccountName attribute for the object to a unique string, if one is not specified.
Deleting an Object
The Active Directory server performs the following actions when an object is deleted:
The isDeleted attribute of the deleted object is set to TRUE. Objects with an isDeleted attribute value set to TRUE are called tombstones.
The deleted object is moved to the Deleted Objects container for its naming context. If the object systemFlags property contains the 0x02000000 flag, the object is not moved to the Deleted Objects container. For more information about binding to and enumerating the contents of the Deleted Objects container, see Retrieving Deleted Objects.
The Deleted Objects container is flat, so all objects reside at the same level within the Deleted Objects container. Thus, the relative distinguished name of the deleted object is changed to ensure that the name is unique within the Deleted Objects container. If the original name is longer than 75 characters, it is truncated to 75 characters. The following are then appended to the new name:
- A 0x0A character
- The string "DEL:"
- The string form of a unique GUID, such as "947e3228-70c9-4311-8b7a-e5c9b5bd4432"
An example of a deleted object name is:
Jeff Smith\0ADEL:947e3228-70c9-4311-8b7a-e5c9b5bd4432
Most attribute values for the deleted object are removed. The following attributes are automatically retained:
- attributeID
- attributeSyntax
- distinguishedName
- dNReferenceUpdate
- flatName
- governsID
- groupType
- instanceType
- lDAPDisplayName
- legacyExchangeDN
- mS-DS-CreatorSID
- mSMQOwnerID
- name
- nCName
- objectClass
- objectGUID
- objectSid
- oMSyntax
- proxiedObjectName
- replPropertyMetaData
- sAMAccountName
- securityIdentifier
- subClassOf
- systemFlags
- trustAttributes
- trustDirection
- trustPartner
- trustType
- userAccountControl
- uSNChanged
- uSNCreated
- whenCreated
Other attributes that have a searchFlags attribute value that contains 0x00000008 are also retained.
The following attribute values are always removed from a deleted object:
- objectCategory
- samAccountType
The security descriptor of the deleted object is retained and inheritable access control entries are not propagated. The security descriptor is retained as-is at the time the object is deleted.
Links to and from the deleted object are cleared. This is performed in the background after the object is deleted. If the deleted object is restored before all of the links are cleared, an error will be received.
If the object is deleted on a Windows Server 2003 domain controller, the lastKnownParent attribute of the deleted object is set to the distinguished name of the container where the object was contained when it was deleted.
The deleted object remains in the Deleted Objects container for a period of time known as the tombstone lifetime. By default, the tombstone lifetime is 60 days, but this value can be changed by the system administrator. After the tombstone lifetime expires, the object is permanently removed from the Directory Service. To avoid missing a delete operation, an application must perform incremental synchronizations more frequently than the tombstone lifetime.
Windows Server 2003 adds the ability to restore deleted objects. For more information about deleted object restoration, see Restoring Deleted Objects.
When an item is deleted, none of the attributes of the object can be modified. In Windows Server 2003, it is possible to modify the security descriptor (the ntSecurityDescriptor attribute) on a deleted object. This is to allow restoration of objects when the person restoring the object does not have write permissions to mandatory attributes. To update the security descriptor on a deleted object, the caller must have the "Reanimate Tombstone" control access right on the naming context, in addition to regular WRITE_DAC and WRITE_OWNER access. Even if the security descriptor is restrictive, the administrator can first take ownership of the object, assuming the administrator has the SE_TAKE_OWNERSHIP_NAME privilege, and then modify the security descriptor. To do this, use the ldap_modify_ext_s function with the LDAP_SERVER_SHOW_DELETED_OID control. The modification list must contain a single attribute replacement for the ntSecurityDescriptor attribute.