Category: Uncategorized

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.

This is the latest hotfixes that updates the NTDSAI/NTDSA.dll (The Directory Service Agent) by Operating System.

Windows Server 2012 R2:Address AD object renaming issues when success auditing is enabled:
http://support.microsoft.com/kb/2862304/en-US

Windows Server 2012:
AD DS or AD LDS responds slowly to complex LDAP query that has a deeply nested filter on Windows server:
http://support.microsoft.com/kb/2862304/en-US

Windows Server 2008 R2 SP1:
AD DS or AD LDS responds slowly to complex LDAP query that has a deeply nested filter on Windows server:
http://support.microsoft.com/kb/2862304/en-US

Windows Server 2008 SP2:
Lsass.exe process crashes and error code 255 is logged because of a CNF NTDS Settings object in Active Directory on Windows
http://support.microsoft.com/kb/2913087/en-US

Windows Server 2003 SP2:
MS13-032: Description of the security update for Active Directory: April 9, 2013:
http://support.microsoft.com/kb/2772930/en-US

The DC Locator flags to specify the requirements of a Windows Server 2012 DC or a Windows Server 2012 R2 DC using the DsGetDCName API are as following:

Table 1: Windows Server 2012 DC Locator flags

So if you read up on modifyTimeStamp – for example here: http://blog.joeware.net/2006/10/03/655/ or at MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/ms677125(v=vs.85).aspx “modifyTimeStamp” is a constructed attribute and as Joe points out it’s based on the “whenChanged” attribute and that assumption is right in 99,9% of all cases, BUT not always – So where is the exception?

The exceptional case

The exception is the DMD or the SubSchemaSubEntry “CN=Aggregate,CN=Schema,CN=Configuration,DC=X“

Let’s have a look with LDP.exe:

So this clearly shows that ‘modifyTimeStamp’ is NOT based on the ‘whenChanged’ attribute for the subSchemaEntry.

How it really works

Let’s agree we have confirmed that, so to the next question, what is it based on? Well it’s based on the last time the in-memory schema cache of the particular DC was updated either during boot or by manually triggering the operational attribute “SchemaUpdateNow:1”

So let’s try that?

So let’s have a look again:

Yes – “modifyTimeStamp” now shows todays date: 2013-06-28 instead of previously 2013-06-21 J

Why it was implemented

So I guess now there is really one good question left, why?

The answer can be found if you read up on RFC 2251 that says:

“modifyTimestamp: the time this entry was last modified” – you can read further on MSDN where you can see what functionality defined in RFC 2551 Active Directory has implemented: http://msdn.microsoft.com/en-us/library/cc223231.aspx

It’s late and I’ve just gone thru the “Windows Server 2012 R2 Preview” schema aka “Schema 69” and it seems like it first introduces an attribute to the schema that it later on in the process will defunct.

Table 1: Sch61.ldf

 

Table 2: Sch61.ldf

 

Table 3: Sch67.ldf

I don’t want more crap in my dev forest than I have to so I’m going to comment those out.