Month: July 2014

So every Windows Server has an NTDS.dit file right? Well, All Windows Server – Domain Controllers you mean right? Nope they in fact have two J

There is something referred to as the distribution DIT that works as a template DIT and is used when you promote a machine to a DC (either ADAM/ADLDS or ADDS) either as the first dc in a forest or as a replica.

The distribution DIT can be found at the following location:

Table 1: Distribution DIT Location

Note: SxS means that the files are package in the SxS folder on the disk and isn’t copied into the location until the actual role is installed.

So what is the Distribution DIT and when is it used?

It’s actually the DIT all DCs start out with except one case

1. IFM promoted replicas; they start with the IFM source DC as there DIT.
   For more information on Install From Media (IFM), see the following post: http://blogs.chrisse.se/2011/07/08/how-install-from-media-ifm-really-works-part-1/

    

The distribution DIT is copied to the database location (DatabasePath) specified in DCPROMO during promotion, we can verify this by checking the JET database signature of the two databases once DCPROMO has completed, in my case I compare between the distribution DIT for ADLDS and my installed ADLDS instance ‘ESEDEV’

1. Distribution DIT:

1. Installed/Promoted DIT:

As you can see – They do match.

So what does the Distribution DIT contains?

The distribution DIT contains the base schema for either ADDS or ADLDS (that has a more light weight schema that ADDS) – So here my tool ESEDump comes into play, let’s dump a distribution DIT for ADLDS:

Dumping table datatable:

We can see that the first rows inside the distribution DIT contains O=Boot and CN=Schema,O=Boot, CN=BootMachine,O=Boot and then simpely the schema comes, we can see that all of the schema objects has a PDNT that equals == 5, the DNT of the CN=Schema,O=Boot naming context (NC) – Or wait are they really NCs? – let’s add in ‘instanceType’

Yes they are NCs – InstanceType decoded as follows:

1. 0x5 (05) == ( IS_NC_HEAD | WRITE );
   
2. 0xD (13) = = ( IS_NC_HEAD | WRITE | NC_ABOVE );
   

More information on the instance-type attribute can be found here: http://msdn.microsoft.com/en-us/library/cc219986.aspx

So what is CN=BootMachine? This is a fake DSA so that the code can use common routines during install (Can’t explain it better than starting an entire new article – might happen someday)

So what happens during install?

So it’s time to determine how the schema in the distribution DIT is used during install (or promotion of a new domain controller) – well it depends – if it’s used at all.

These are the different cases.

1. Promoting the first domain controller in a forest:

    

   1. The distribution DIT is copied into the database location (DatabasePath) specified in DCPROMO.
   2. A domain naming context is created in the DIT (except for ADAM/ADLDS)
   3. A configuration naming context is created in the DIT.
   4. A schema naming context is created in the DIT.
   5. The boot schema is moved from CN=Schema,O=Boot to the newly create schema naming context.

      During this move the following happens for all objects that has a PDNT of:4 e.g. the CN=Schema,O=Boot:

      1. Object’s are moved to CN=Schema,CN=Configuration,X=foo
      2. As the object’s are moved their ancestors_col must be updated in the DIT to inheritance from the new CN=Schema,CN=Configuration,X=foo
      3. As the object’s are moved from one naming context (NC) (CN=Schema,O=Boot) to another (CN=Schema,CN=Configuration,X=foo) their NCDNT_col in the DIT needs to be updated as well.
      4. Object’s have their metadata updated , fields updated are:
         1. OriginatingDsa
         2. timeChanged
      5. Give the object a new GUID.
      6. Set a default security descriptor depending on ADDS or ADLDS and depending on if attribute or class.
   6. The prefixMap is read of CN=Schema,O=Boot and saved into the prefixMap of CN=Schema,CN=Configuration,X=foo
      More information on the prefixMap/prefixTable can be found here: http://msdn.microsoft.com/en-us/library/cc228445.aspx

       

      Note: This allows the distribution DIT to contain schema entries that the DSA doesn’t have knowledge about (e.g. other attributes and classes than the base schema can come pre-loaded) – This used to be the case for Small Business Server that pre-loaded the Exchange Schema.

   7.  
      1. Removing CN=BootMachine,O=Boot
      2. Removing CN=Schema,O=Boot
      3. Removing O=Boot
2. Promoting a replica in an already existing forest:
   
   1. Remove the following as a schema already exists in the enterprise and will be replicated in.
      1. Removing all object’s with a PDNT of 4 == e.g. all objects that have CN=Schema,O=Boot as parent.
      2. Removing CN=BootMachine,O=Boot
      3. Removing CN=Schema,O=Boot
      4. Removing O=Boot

    

Both in case A (First DC in the forest) and case B (Replica in an existing forest) – the install code will trigger the garbage collector so it can immediately delete all traces of the O=Boot naming context (NC) and its decadent object’s.

For more information on the garbage collector have a look at: http://blogs.chrisse.se/2012/11/28/how-the-active-directory-data-store-really-works-inside-ntds.dit-part-4/

This article started out by a question that was – How can the Schema naming context (NC) has a higher USN than many of the attributes in the schema – Doesn’t the schema container have to be created first, before its child objects? – Well we know the answer to that question already but let’s confirm it.

Let’s get the “usnCreated” on the Schema naming context (NC):

Ok, it’s 4100.

Let’s try an attribute “Account-Expires”

OK, that’s a pretty low “usnCreated” and much lower than the Schema naming context (NC) above.

So let’s look up the “Account-Expires” in the distribution DIT:

Yes , “usnCreated” is 6 in the distribution DIT as well, with other words “usnCreated” will come from the distribution DIT for base schema object’s, hence they have a lower usnCreated than the schema naming context (NC) itself.

 

For some background information about the constructed attribute ‘modifyTimeStamp’ that is based off the data in the ‘whenChanged’ attribute in most cases except the subschema entry see the following previous blog post: http://blogs.chrisse.se/2013/06/28/the-constructed-attribute-modifytimestamp-always-whenchanged/

I just played along with a Windows Server 2012 R2 DC and noticed a undocumented registry key (this might was added in already in Windows Server 2012) but is not in Windows Server 2008 R2 or earlier releases – The key are:

‘Subschema modifyTimeStamp behavior’ DWORD registry values can be configured within the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\<INSTANCE>\Parameters.
Note: if the key doesn’t exist or have a value of 0 the default behavior will apply.

But what happens, and what works different if a value of ‘1’ is used?

It seems like we’re getting the time of when the schema actually was updated, and not just when the schemaCache was updated – as the ‘modifyTimeStamp’ attribute will indicate by its default behavior if you request it over the subschema. I compared the time of ‘modifyTimeStamp’ and the metadata for the ‘schemaInfo’ attribute to verify this (more on that attribute another day, if someone want?)

So what can this be used for? I have no idea J One can just read off the schemaInfo instead.