Archive for May 2012
The version of the Schema in use by AD DS and AD LDS (ADAM) is to be found in the objectVersion attribute of the Schema Naming context and as such can be determined by navigating to the Schema Naming context using say ADSIedit or ldp.exe. From the command line we can use the Active Directory powershell module or ldifde or repadmin:
The commands above were run on a DC hence localhost:389, substitute the DC name as required. Repadmin and ldifde were run in the PowerShell window but could just be run from the command line on any device with AD DS tools installed.
There are three default Roles (groups) in an application partition in an AD LDS (ADAM) instance:
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:
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
The Base64 encoding of the member attribute is explained here.
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
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.
Here’s a list I have kept of the common problems in attempting to use Adamsync:
Schema mismatch. (Use ADSchemaAnalyzer)
Target partition in Adamsync configuration does not exist in target ADAM. Note: target partition must be an NC head.
MS-AdamSyncMetadata.ldf is not imported
Source AD is W2K and so Replicating Directory Changes permission is not granted for sync account on source AD NC head.
ObjectClass foo is not in the ADAM schema when target-object-class in the ADAMsync configuration is set to foo. foo is usually userProxy.
If target-object-class in ADAMsync is userProxy then objectSID must be in the include element of the ADAMsync configuration.
Account used for ADAMsync /install must be able to write to target ADAM application NC head.
If source-ad-account element is used in the ADAMSync configuration then will probably need /passPrompt on the ADAMSync /install command line.
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.
object-filter element in ADAMSync configuration needs:
and = “&” use &
or = “|” use & #124;
not = “!” use & #33;
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
Not using /log on the ADAMsync /sync when hitting problems.
 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.
It’s often a good fall back to have BUILTIN\Administrators (BA) as a member of the Administrators role in an AD LDS or ADAM installation. A use case for this was in ADAM releases prior to AD LDS when you wanted to take a copy of an ADAM instance to a test server, and having BA in the Administrators role made that backup portable (i.e. not dependent on whatever local account had been used as the ADAM Administrator on the machine from which the backup was taken); in AD LDS spinning up a test copy is best done by taking a snapshot.
What does adding a member to a group look like? Well using LDIF the import file would look like:
To add BUILTIN\Administrators using an LDIF file, call it AddBA.ldf, we need:
(avoiding any trailing whitespace at line ends).
The first line in each of the above is just the group object we are adding a member to but the last lines look very different. The reason for the difference is that in the first (more usual) case we are adding the member we are adding to the group is an object within the directory tree that also contains the group but in the second case we are adding a “foreign” object; the BA group is a native Windows security principal which does not exist within the directory tree rather it is an external construct from the point of view of the directory service (it’s not even an object in another directory tree).
The string PFNJRD1TLTEtNS0zMi01NDQ+ is the Base64 encoding of <SID=S-1-5-32-544> where S-1-5-32-544 is the string SID for the BA group. What’s going on under the hood here is that the member attribute is an “FPO enabled” attribute and when an add operation is made against such an attribute using the form <SID=string SID>, for what would be a distinguishedName, the directory service creates a Foreign Security Principal (FSP) in the FSP container for the directory service and adds a reference to that FSP in the attribute (member in this case). Why the Base64 encoding? It’s to avoid a clash with LDIF syntax as a line starting “member:<” would be interpreted as an external input URL .
The LDIF above can be imported using an account that is an ADAM Administrator (into an instance running on port 50002) using:
ldifde -i -f AddBA.ldf -s localhost:50002 -c "CN=Configuration,DC=X" #configurationNamingContext
Performing an ldifde export to the console ( -f con) we can see the result of our work:
ldifde -f con -d "cn=administrators,cn=roles,"#configurationNamingContext -l member -s localhost:50002
Connecting to “localhost:50002”
Logging in as current user using SSPI
Exporting directory to file con
Searching for entries…
Writing out entries.
The ADAM technical reference on TechNet is still one of the best guides for understanding ADAM and is still relevant for AD LDS in the main, see in particular the “How Active Directory Application Mode Works” article.
Microsoft Open Specifications are the references that Microsoft provide for developers working on interoperability and integration. They are also an invaluable source of information for architects working with Microsoft technologies. The two key references for Active Directory technology are MS-ADTS (the AD Technical Specification) and MS-DRSR (the replication specification); the latter being largely a protocol implementation reference for developers whilst the former is more generally readable. For AD LDS three important documents are:
to be found amongst the other Windows Server Protocol Specifications here.