Notes on IT (mainly Microsoft)

Archive for June 2012

Structure Rules! NAMING_VIOLATION and Error 0x2099 (The object cannot be added because the parent is not on the list of possible superiors)

leave a comment »

In AD, structure rules determine which parent child relationships are possible amongst instances of classSchema objects and the structure rules are defined by the possSuperiors and systemPossSuperiors attributes of the classSchema objects. Let’s look at the default schema classSchema for an organizationalUnit (OU) in AD LDS:

We should find ourselves unable to create an organizationalUnit with an object that is not listed in systemPossSuperiors as its parent so e.g. we should not be able to create an organizationalUnit beneath a “container” object. Let’s try:

We would see the same if we tried using ldf, the ldf file (ou.ldf) to create the OU would be

dn: ou=test,cn=roles,o=msft
changetype: add
objectClass: organizationalUnit

It’s possible to modify structural rules by modifying possSuperiors for a classSchema object (it has to be possSuperiors rather than systemPossSuperiors as the latter is owned by the system and so can only be specified when the classSchema object is first created), so in our example to add the  container class as possible parent of an OU we could use an ldf (mod-posssuperiors.ldf):

dn: cn=Organizational-Unit,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: possSuperiors
possSuperiors: container

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

The first modify operation is to add container to possSuperiors of Organizational-Unit.
The second modify operation uses a RootDSE modify operation schemaUpdateNow to tell the directory service to update the cached version of the schema so that the first modification can be used immediately.

If we now import this schema modification:

C:\Windows\system32>ldifde -i -f c:\Local\mod-posssuperiors.ldf -s localhost:389 -c “cn=Schema,cn=Configuration,dc=X” #schemaNamingContext

Connecting to “localhost:389”
Logging in as current user using SSPI
Importing directory from file “c:\Local\mod-posssuperiors.ldf”
Loading entries…
2 entries modified successfully.

and now re-run our attempt to create an OU beneath a container:

C:\Windows\system32>ldifde -i -f c:\local\ou.ldf -s localhost:389
Connecting to “localhost:389”
Logging in as current user using SSPI
Importing directory from file “c:\local\ou.ldf”
Loading entries..
1 entry modified successfully.

The same problem is sometimes seen with adamsync where the AD DS objectClass builtinDomain has only domainDNS as a possSuperior, if that objectClass is imported into the AD LDS schema (using ADSchemaAnalyzer) then if an AD LDS partition is created as, say, cn=mysync,o=msoft the attempt to adamsync from the AD DS will fail as it attempts to create a builtinDomain object with a Container as a superior. The fix is as above:

dn: cn=Builtin-Domain,cn=Schema,cn=Configuration,dc=X
changetype: modify
add: possSuperiors
possSuperiors: container

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

Written by adamsync

June 22, 2012 at 00:51

How to find out which naming contexts and application partitions are hosted by an AD LDS instance

leave a comment »

Suppose we have an AD LDS instance running on localhost port 389. What naming contexts does it hold?

The naming contexts can be enumerated by retrieving namingContexts attribute of the RootDSE of the AD LDS instance:

 

Powershell:

PS C:\Users\Administrator> (Get-ADRootDSE -Server localhost:389).namingContexts

CN=Configuration,CN={0FF76061-6F79-4DF9-AA3F-58239ED6EEA2}
CN=Schema,CN=Configuration,CN={0FF76061-6F79-4DF9-AA3F-58239ED6EEA2}
O=msft

or

ldifde:

C:\Windows\system32>ldifde -f con -s localhost:389 -d “” -p base -l namingContexts

Connecting to “localhost:389”
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries…
Writing out entries.dn:
changetype: add
namingContexts: CN=Configuration,CN={0FF76061-6F79-4DF9-AA3F-58239ED6EEA2}
namingContexts:
CN=Schema,CN=Configuration,CN={0FF76061-6F79-4DF9-AA3F-58239ED6EEA2}
namingContexts: O=msft

1 entries exported

The command has completed successfully

To see the namingContexts in a GUI tool run:

ldp.exe localhost:389

and look for the namingContexts attribute in the right hand pane:

Written by adamsync

June 21, 2012 at 22:57

How to find out which AD LDS instances are runing on a local server

leave a comment »

The first command I usually run when familiarising myself with an AD LDS installation is
dsdbutil.exe “list instances” quit

C:\Windows\system32>dsdbutil “list instances” quit

dsdbutil: list instances

Instance Name:         instance1
Long Name:             instance1
LDAP Port:             389
SSL Port:              636
Install folder:        C:\Windows\
Database file:         C:\Program Files\Microsoft ADAM\instance1\data\adamntds.dit
Log folder:            C:\Program Files\Microsoft ADAM\instance1\data
Service state:         Running

Instance Name:         instance2
Long Name:             instance2
LDAP Port:             50000
SSL Port:              50001
Install folder:        C:\Windows\
Database file:         C:\Program Files\Microsoft ADAM\instance2\data\adamntds.dit
Log folder:            C:\Program Files\Microsoft ADAM\instance2\data
Service state:         Running

dsdbutil: quit

Written by adamsync

June 21, 2012 at 22:51

Posted in AD LDS, ADAM, adam-lds, Microsoft

What’s New in Active Directory Domain Services in Windows Server 2012 (TechNet)

leave a comment »

The four tenets of the Windows Server 2012 AD DS improvements:

“Virtualization that just works
Providing greater support for the capabilities of public and private clouds through virtualization-safe technologies and the rapid deployment of virtual domain controllers through cloning.

Simplified deployment
Simplifying the on-premises AD DS deployment (formerly DCpromo) with a new streamlined domain controller promotion wizard that is integrated with Server Manager and built on Windows PowerShell.

Simplified management
Integrating claims-based authorization decisions into AD DS and the Windows platform that permit a combination of centralized access policies, directory attributes, the Windows file-classification engine, and compound-identities comprising both user and machine identity

Providing a consistent graphical and scripted management experience that allows you to perform tasks in the Active Directory Administrative Center that automatically generate the syntax that is required to enable automation for the task in Windows PowerShell.

AD DS Platform Changes
Updating the AD DS platform with changes such as relative ID improvements, deferred index creation, and off-premises domain join improvements.”

More detail on TechNet:

Active Directory Domain Services

                What’s New in Active Directory Domain Services (AD DS)
                Active Directory Replication and Topology Management Using Windows PowerShell
                Deploy Active Directory Domain Services (AD DS) in Your Enterprise
                Active Directory Domain Services (AD DS) Virtualization
                Active Directory Administrative Center Enhancements
                Dynamic Access Control

Written by adamsync

June 20, 2012 at 22:18

What’s new in Active Directory Domain Services in Windows Server 2012 (TechEd)

leave a comment »

Dean Wells, Program Manager in the Directory Services product group at Microsoft, gave a number of excellent and highly-rated talks at TechEd recently:

What’s New in Active Directory  in Windows Server 2012

Impact of Cloning and Virtualization on Active Directory Domain Services

Running Active Directory on Windows Azure Virtual Machine

The interview that Dean gave to Channel 9 during TechEd is a frank and lucid briefing on the latest developments:

Dean Wells Live at Tech Ed