Creating dynamic objects with Active Directory

You might have heard of the concept of dynamic objects in Active Directory before. You might not – I don’t care at this point, as I will try wrap the topic up and give you a nice example of how you could use them.
First off, dynamic objects exist in Active Directory since Windows Server 2003. So if your Domain Functional Level is Server 2003, you are able to use dynamic objects. Dynamic objects have, other than normal objects in Active Directory, a specific lifetime – a lifetime that you set on object creation. Once the lifetime is over, the object dies. I mean – it literally dies. We’ll look at this using a user object (so that the “the object dies” phrase creates a nice picture in your head). By “dies”, I mean that the object is, after the lifetime is over, purged from the directory database. That’s not done by normal deletion means, that is

• Create a tombstone or
• Create a deleted object

but the dynamic object is purged from the database, leaving no traces. Every Domain Controller will purge that object locally, so there is no replication impact from the death of the object.

Dynamic objects are realized by using an auxiliary object class called “dynamicObject”, which can be “attached” to almost any of well-known AD objects on object creation. This includes users, computers, organizationalUnits and groups. By attaching the auxiliary dynamicObject-class to the user object, we’ll tell Active Directory that this object won’t last long. During object creation we not only attach this aux class but can specify the object’s lifetime using the entryTTL* attribute that comes with the dynamicObject class. We specify the lifetime in seconds, where a value of “60” is one minute, “3600” is 1 hour.

In case you have no preference in the object’s lifetime and do not specify entryTTL on object creation, Active Directory assume the default value, which is 86400 (1 day). The default value is buried deep down as an AD attribute of the CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=domain,DC=tld object. The attribute is called “msDS-Other-Settings” and is a multi-value attribute, containing:

• DynamicObjectDefaultTTL specifies the default number of seconds an object lives in case entryTTL is not specified. It’s default is 86400 (seconds, equals 1 day).
• DynamicObjectMinTTL specifies the minimum lifetime of an object. It’s default is 900 (seconds)


So what is such an object good for? I would tend to use it primarily with applications that need to store data temporarily. For example, have an application that tracks online users or users logged on to the network. You could write an agent that gets loaded upon user logon/domain logon. The agent would create a dynamic objects in some OU and would, while it is running, update the object every 5 minutes to increase its entryTTL to keep it alive. The entryTTL could be set to 15 minutes to allow for two updates not to happen and, if no update is made any more, the object gets deleted. Like this, you could have a better picture of which users are online and have connectivity to Active Directory.

I’ll use them for a different scenario. Let’s say we have temp users that only work for us for one day, do their job, go away and never come back. Clearly, I wouldn’t worry about a full-blown user account with an Exchange mailbox and all the bells and whistles – but that temp user might need access to certain kinds of data that is stored on the network. I could create a group that allows this access and – for the temp users that visit me, create an account and add them to the group. Tomorrow, when that user is gone, the account will die alone, not leaving a tombstone or any other garbage around until Tombstone Lifetime is over.

I’ll go create that user account with an LDF import script via LDIFDE – but you sure can use Powershell or VBS scripting for this, too. It is just a matter of using the correct objectClass on object creation (that is both “user” and “dynamicObject” at the same time). Below’s the text that I use to save in notepad as “newUser.ldf”:

dn: CN=Friderike Bartel (temp),OU=Sales,OU=Berlin,DC=intern,DC=frickelsoft,DC=net

changetype: add
objectClass: user
objectClass: dynamicObject
sAMAccountName: t-fbartel
userAccountControl: 514

dn: CN=Friderike Bartel (temp),OU=Sales,OU=Berlin,DC=intern,DC=frickelsoft,DC=net
changetype: modify
replace: unicodePwd

replace: userAccountControl
userAccountControl: 512

Notice the blank line after the last -. I first create a user account for Friderike Bartel and assign both user and dynamicObject as the objectClasses. I first set her account to “disabled”.

In a second step, I’ll set her password to “newPassword!1” and enable her account.I kick off the ldifde with the following command:
Ldifde –t 636 –v –I –f newUser.ldf –j C:\temp\ and off it goes.

Friderike’s user account is created and she can instantly log on with the password to a workstation. Notice that I haven’t used entryTTL here, so the default value of one day lifetime applied. I could have added another line with the entryTTL specified, such as:

entryTTL: 3600
For a Powershell script, Robert M. Toups Jr. has a nice example on his blog:

One thing to note, though: you cannot create a “normal” object as a child object of a dynamic object. This means that, you cannot create an ordinary user account in an OU that is configured to die at some point in time. Active Directory does not allow that.

* Oh – and by saying we write to the “entryTTL” attribute, this wasn’t completely accurate. In fact, entryTTL is a constructed attribute we actually cannot write to. The object’s lifetime is stored in a different attribute that is read-only. Funny enough, it’s called msDS-Entry-Time-To-Die (see, I told you they die!) and contains the absolute date and time (14.10.2011 15:10:23) when the object dies.

No Comment