Notes on IT (mainly Microsoft)

Archive for the ‘adam-lds’ Category

Two new posts on ADAMsync over at AskDS

leave a comment »

There are two new posts on ADAMsync over at AskDS.

The first is an ADAMsync 101, covering basic ADAMsync configuration; see also my AdamSync Common problems

The second (ADAMSync + (AD Recycle Bin OR searchFlags) = “FUN”) covers interaction between ADAMsync and the AD Recycle Bin functionality; I saw a related issue a long time ago with a customer who had chosen to preserve most every attribute on deletion as a way of trying to avoid doing database restores after accidental deletions. Another issue in this area was in very early versions where the ADAMsync did not have sufficient privilege to see deleted objects; this was fixed by introducing “obscured tombstone” logic that supports DirSync (which underlies ADAMsync) by just returning objectGUID and isDeleted for callers that would not usually have rights to see tombstones.

It’s great to see Microsoft still actively supporting ADAMsync.

Written by adamsync

February 8, 2013 at 00:13

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

Adding Users to AD LDS (ADAM) Readers Role

leave a comment »

There are three default Roles (groups) in an application partition in an AD LDS (ADAM) instance:

  • Administrators
  • Readers
  • Users

Let’s look the permissions of the Readers role (the application partition here is o=msft) using the Security UI in ldp.exe:

or using dsacls.exe:

The Readers role is empty by default, individual users or groups within AD LDS can be added by distinguishedName to the member attribute of the group.

The following ldf adds (nests) the Users role in AD LDS into the Readers role:

dn: CN=Readers,CN=Roles,O=msft
changetype: modify
add: member
member: CN=Users,CN=Roles,O=msft

placed in a file UserstoReaders.ldf and imported with

ldifde -i -f UserstoReaders.ldf -s localhost:389

from a command prompt on the AD LDS instance with the instance running on port 389.
As a result all AD LDS users would have Readers permission on the instance.

If we want to allow Windows/Domain users that can authenticate to the AD LDS instance to have Readers permissions then we can add the security identifier for Authenticated Users (SID: S-1-5-11) to the group as with the following ldf

dn: CN=Readers,CN=Roles,O=msft
changetype: modify
add: member
member:: PFNJRD1TLTEtNS0xMT4=

The Base64 encoding of the member attribute is explained here.

Written by adamsync

May 23, 2012 at 22:27

Auditing for ADAM and AD LDS

leave a comment »

Linda Taylor’s One stop Audit shop for ADAM and ADLDS is the go to reference for audit in ADAM and AD/LDS. When you read Linda’s post you will mention of the SeSecurityPrivilege right required to manipulate SACLs.

As Linda points out AD LDS native principals can not have windows rights so a windows principal is needed to adjust SACLs in AD LDS.

SeSecurityPrivilege is a bit confusing partly because it gets referred to by different names :
ACCESS_SYSTEM_SECURITY, SE_SECURITY_NAME, SeSecurityPrivilege, “Manage auditing and security log”

The bookmark I have for recalling these is here which largely covers the access to the SACL aspect of this right. One thing to note is that the access right is not valid in a DACL as DACLs do not control access to a SACL, which can be confusing – a confusion which lead to the transitory appearance of the right in the ACE editor in ldp.exe in one release.

I think the policy name “Manage auditing and security log” can be confusing. Here’s a case in point: if the SeSecurityPrivilege right is not available to the Exchange Enterprise Servers group problems arise . However if you look at the Exchange “Understanding and Troubleshooting Directory Access” doc., it states in respect of event 2080:

“DSAccess does not use a server if it does not have permission to read
the SACL on the nTSecurityDescriptor attribute for the configuration naming
context.”

which has nothing to do with event log management (something that the right is also required for), the snip from the guide above explains why the right is required in this case but not why that specific check is needed in domain controller selection by Exchange.

Written by adamsync

May 18, 2012 at 22:10

AdamSync Common problems

leave a comment »

Here’s a list I have kept of the common problems in attempting to use Adamsync:

[1]Schema mismatch. (Use ADSchemaAnalyzer)

[2]Target partition in Adamsync configuration does not exist in target ADAM. Note: target partition must be an NC head.

[3]MS-AdamSyncMetadata.ldf is not imported

[4]Source AD is W2K and so Replicating Directory Changes permission is not granted for sync account on source AD NC head.

[5]ObjectClass foo is not in the ADAM schema when target-object-class in the ADAMsync configuration is set to foo. foo is usually userProxy.

[6]If target-object-class in ADAMsync is userProxy then objectSID must be in the include element of the ADAMsync configuration.

[7]Account used for ADAMsync /install must be able to write to target ADAM application NC head.

[8]If source-ad-account element is used in the ADAMSync configuration then will probably need /passPrompt on the ADAMSync /install command line.

[9]If object-filter element in ADAMSync configuration uses objectCategory then problems can arise, in particular deletions in source AD will likely not be sync’ed.

[10]object-filter element in ADAMSync configuration needs:

and = “&” use &

or = “|” use  & #124;

not = “!” use & #33;

[11]Choice of target-dn restricts the children that can be sync’ed from AD through possSuperiors e.g. if you make your target-dn ou=something and your base-dn is a domain NC head dc=contoso,dc=com then CN=builtin under the domain NC head will cause a sync failure as OU is not a possSuperior of builtinDomain

[12]Not using /log on the ADAMsync /sync when hitting problems.

[13] Infinite loops in synchronization with Windows 2003 Adamsync

[14] Problems with Adamsync aging runs e.g. random objects may be renamed and then moved into the ADAM Lost and Found container. Aging has many problems and is best avoided.

See also How to troubleshoot an OBJ_CLASS_VIOLATION error in Adamsync in Windows Server 2003 or in Windows Server 2008

Written by adamsync

May 15, 2012 at 21:52