joeware - never stop exploring... :)

I previously wrote that many applications that are using Active Directory aren’t meeting even the lowest bar for proper Active Directory integration. That lowest bar being the ability to properly find an Active Directory domain controller to use for LDAP operations. This is something that regularly plagues me and it is ridiculous that it is still a problem.

If someone can’t properly find a domain controller is it realistic to expect them to get anything else related to Active Directory truly right? Finding a domain controller is literally step one in "How to query AD with LDAP". If a developer is already bored with and doesn’t properly develop step one there isn’t much hope, IMO, for anything that follows. If a company purposely makes the decision to not find domain controllers properly and still claim “Active Directory Integrated” I would (and do when I find them) consider the company untrustworthy for at least anything related to Active Directory and I look at everything else with a jaundiced eye as well.

So what do they do instead of properly locating domain controllers? *A lot* of vendors and *a lot* of developers simply write the code to specify an IP address or an FQDN of a host or an FQDN of the domain name in the configuration and then they hope for the best. They may add "load balancing" or "redundancy" by adding additional IP addresses or FQDNs or possibly not… Usually not. This truly isn’t acceptable for finding Active Directory domain controllers unless you want an application that is susceptible to (read: guaranteed to have) outages. These same vendors and developers (or the customer application folks that depend on the applications) get mad when their apps fail because of these bad decisions and then they often want to blame the AD folks. Further they go on to say it is up to the AD Admins to find a solution and fix the developers’ and vendors’ inability to write their applications properly. Seriously… They come at the AD admins saying they should put their domain controllers behind virtual IPs / load balancers, etc. The answer should be “No, do your job properly and go fix your poorly written application and/or make sure you know what the product you are buying is actually capable of and only reward companies that do things properly.” You will thank me in the end when you DON’T have to keep crutching their failures.

I would really like to more specifically define the term "a lot" as it is an inadequate description but I simply cannot do it. It stands in for some number that cannot be known but I can state unequivocally that industrywide it is massive and it includes apps written in the back rooms of companies for their internal use as well as in the coding pits of some very large, very well-known software vendors that you would expect, yes expect but cannot guarantee, to know better who are showing their disrespect for you by making you pay for their poorly/incorrectly written product. The sales guys will tell you "Yes our application is compatible with AD" yet by that they just simply mean that it can perform basic LDAP operations and they know that Active Directory can speak LDAP.

There is no reason NOT to do this initial step properly other than vendors expecting customers will pay for what they build no matter how poorly it works. Active Directory is old enough to vote and is not the only LDAP Directory that has similar DNS SRV record based intelligent service location capabilities available based on RFC 2782. If you are a developer and have been writing LDAP code PRIOR to the year 2000 then perhaps you have an excuse not to do this correctly but… no, I’m lying, you have no excuse at this point. You are lazy and are content with half-ass code if you don’t think it should be done properly especially now nearly 20 years later.

What will follow on the blog are a series of posts that describe in detail various aspects of the DC Locator process (and other AD dev related things) that applications can leverage to properly find domain controllers and be properly redundant. There will be a post on the generic high level process, a post on pure Windows doing it “The Easy Way”™, a post on pure Windows doing it a little more long and draw out, and a post for generic mechanisms that will work on any OS (including Windows) that has DNS resolver lookup and LDAP client network functionality.

Stay tuned…

    joe

I spent some time this weekend relearning something I learned 15 or so years ago… How to make 2.5.5.14 (DN with String) attribute schema changes that actually work. It’s simple but there is also a trick to it that you need to be aware of.

Let’s go back a bit…

I was recently asked about setting up a special multi-multi forward and backward (back) linked attribute pair for tracking relationships between users and computers. The computers would hold the forward link, the users, groups, or anything used would hold the reverse link. Then if you want to specify a group of individual users and/or groups that “own” a specific computer object (or OU or Group or Application/Process IDs or whatever you want really) you can easily do so and those linkages would carry back to the users themselves so they could see what objects they “own”.

So spinning up a multi-value forward/back linked attribute pair is easy right? Just a pair of multi-value 2.5.5.1 attributes. You could just use managedBy and managedObjects but managedBy is single valued and that isn’t something you can change. That leaves creating new attributes and again who hasn’t made thousands of schema mods/adds over the years to spin up linked 2.5.5.1 attributes? Boring!

However, we can do better than linked 2.5.5.1s. Active Directory (and LDS) support two other DN style attributes that can be linked. First there is 2.5.5.7 which is DN with Binary (aka DN-Binary aka ADS_DN_WITH_BINARY). Second is 2.5.5.14 which is DN with String (aka DN-String aka ADS_DN_WITH_STRING).

The cool thing with these additional formats is that it allows you to stuff additional information on the DN. Say like UAR / Attestation / Request# info for tracking purposes (you are tracking changes and who requested, when requested, Date of last review, and then reviewing it on a regular frequency right?). Heck with DN with Binary you could build a whole binary structure to jam in there and easily pack and unpack it with code and it would be basically obfuscated for everyone else. And keep that in mind, obfuscated, not encrypted.

Relevant Informational Side-Bar
====================

A 2.5.5.1 Attribute is simply a distinguished name aka DN. It has to be a VALID DN that exists in the DSA (Domain Controller or LDS instance) database because internally it is represented as a pointer to the row of the object in the underlying database, it is not an actual string of the DN value. You can’t put in CN=SchoolofRockElite,OU=Groups,DC=SchoolOfRock,DC=com into a 2.5.5.1 attribute in the single forest domain DC=ClassicalMusicOnly,DC=com because that isn’t a valid DN in that forest. You could, however, add a foreignSecurityPrincipal for the SchoolofRockElite group into the ClassicalMusicOnly domain and put *that* DN into the 2.5.5.1 attribute.

One cool thing about using 2.5.5.1 attributes is that if the object pointed to by the DN specified is changed (i.e. moved around AD) the DN in the attribute will be updated as well. If the object is deleted the linkage will show the link as a deleted DN. So good news bad news there… If someone who is set as the owner of an object is deleted, that linkage will eventually be scrubbed by the OS and then you will have a blank owner attribute (if that one object is the only owner listed). That is why ownership should *generally* be to groups for anything that should survive individuals marked as owners. At the very least you need to scan your links regularly looking for the deleted object links and then handle them in whatever method you define (delete the object with the link to a deleted owner, change the link to another owner, etc)

Another cool thing about using 2.5.5.1 attributes in a multivalued attribute when they are linked (forward/backward linked) with linkid functionality is that linked value replication functionality kicks in and with that there is no defined limit to the number of values for the attribute. This was new as of OEM Windows Server 2003 and FFL2. This is the functionality that allows for groups to have membership in excess of about 5000 members which was an issue in Windows Server 2000 with multiple domain controllers (replication could break temporarily or permanently because of version store exhaustion).

One last cool thing about 2.5.5.1 linked attributes. You will have a forward link and a backward (back) link. You can ONLY change the forward link value, the back link is a reflection only and cannot be modified. Consider member and memberOf. You can modify the member attribute on groups but you cannot modify the memberOf attribute on users or anything else. Just remember, back link is always read only. 

The 2.5.5.7 attribute extends the 2.5.5.1 functionality by allowing you to add binary data to the attribute as well in the format of B:<datasizeinbytes>:<binarydata>:<valid DN> so something like B:32:A9D1CA15768811D1ADED00C04FD8D5CD:CN=Users,DC=multimanage,DC=test,DC=loc which can actually be translated (and is translated to by AdFind) to “GUID_USERS_CONTAINER = CN=Users,DC=multimanage,DC=test,DC=loc”. If you aren’t familiar, that is from the wellKnownObjects attribute on the domain NC head object which you can find on any domain NC head object (and no you will never see that in ADUC). Another more complex example can be seen with msDS-RevealedUsers. For example you could have a value of

B:96:A0000900060000006CC2ED0E03000000DCBD06B345297D4AB7CE0BC829C55C5A00D801000000000000D8010000000000:CN=joe user,OU=Users,OU=TestOU,DC=k16tst,DC=test,DC=loc

which translates to (as done by AdFind)

lmPwdHistory                     6  2017/03/30-12:25:16      120832  {B306BDDC-2945-4A7D-B7CE-0BC829C55C5A}  CN=joe user,OU=Users,OU=TestOU,DC=k16tst,DC=test,DC=loc 

The 2.5.5.14 attribute extends like 2.5.5.7 only it is a string value that you can add in the format of S:<datasizeinbytes>:<stringdata>:<valid DN> so something like S:23:supplementalCredentials:CN=krbtgt_20940,CN=Users,DC=k16tst,DC=test,DC=loc.

The one truly sucky thing about 2.5.5.14 (and to a lesser extent 2.5.5.7) is that the extra data can’t be quantified and used in a search query in any way that I am aware of. It is a lesser extent issue with 2.5.5.7 because that is the case for any binary data attributes and it really doesn’t make a lot of sense for searches of binary data.

Note that the back link for 2.5.5.7 and 2.5.5.14 forward link attributes is always a 2.5.5.1 attribute. You need to look at the forward link in order to get the additional data.

Anyway… back to the beginning. I sometimes wonder if part of the reason these special versions of linked DN attributes are not really used by others (MSFT uses them in a few different areas) is because there is a little trick to it to make it work right. Unlike most attributes you have to remember to set the oMObjectClass property on the schema attribute definitions because each of these two attributeSyntax types have two forms that are controlled by oMObjectClass and for fun MSFT set it up so the one you will get when you create the definitions is NOT the one you want. I haven’t seen everything but I have never once in many hundreds of production corporate directories ever seen the alternate versions of these attributes being used; if they are there, they are DN String and DN Binary. So chalk it up to not well thought out and something we have to handle on our end when defining the attributes in the Schema and all will be good.

This is so arcane and little used that I completely forgot about it myself and had to relearn “the trick” again this weekend. I thought to myself I know I have done this for companies in the past and it worked fine… Why is it not working fine now. Once I finally recalled the issue after about 10 minutes of looking closely at the schema definitions over and over and the extended errors and trying with LDP and ADSIEDIT to make sure I didn’t at some point introduce a bug into AdMod to cause it to break and then a literal palm slap to the forehead and an “oh yeah I remember this stupid implementation now” I thought why didn’t I blog this before so I could find the blog when I tried to do it again and failed??? So here we are, you are now all caught up with me and I am actually blogging it this time so when I try to do again many years from now I can google it.  

First the error you will hit if you create the DN with String attribute incorrectly (with the version of Windows Server 2016 at this time of this post[1]):

Error 0x15 (21) – Invalid Syntax
Extended Error: 00000057: LdapErr: DSID-0C090F3A, comment: Error in attribute conversion operation, data 0, v3839

Depending on the tool you are using it will be exposed (or not) in different ways. This is what it will look like in full from AdMod:

[Sun 07/08/2018 12:24:42.83]
E:\Dev\AD\Schema>admod -default -rb cn=testcomputer,cn=computers joeware-managedby:++:"S:6:MyTest:cn=testuser,cn=computers,DC=multimanage,DC=test,DC=loc" -exterr

AdMod V01.18.00cpp Joe Richards (joe@joeware.net) March 2012

DN Count: 1
Using server: K16SC-DC1.multimanage.test.loc:389
Directory: Windows Server 2008 R2
Base DN: cn=testcomputer,cn=computers,DC=multimanage,DC=test,DC=loc

Modifying specified objects…
   DN: cn=testcomputer,cn=computers,DC=multimanage,DC=test,DC=loc…: [K16SC-DC1.multimanage.test.loc] Error 0x15 (21) – Invalid Syntax

   Extended Error: 00000057: LdapErr: DSID-0C090F3A, comment: Error in attribute conversion operation, data 0, v3839

ERROR: Too many errors encountered, terminating…

The command did not complete successfully

Now for the error you get when you incorrectly create DN with Binary (with the version of Windows Server 2016 at this time of this post[1]):

Error 0x13 (19) – Constraint Violation
Extended Error: 000020B5: AtrErr: DSID-03152E86, #1:
        0: 000020B5: DSID-03152E86, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9667ed48 (joeware-ManagedBy-Bin)

One again, depending on the tool you are using it will be exposed (or not) in different ways. This is what it will look like in full from AdMod:

[Sun 07/08/2018 12:24:46.72]
E:\Dev\AD\Schema>admod -default -rb cn=testcomputer,cn=computers joeware-managedby-bin:++:"B:8:00000000:cn=testuser,cn=computers,DC=multimanage,DC=test,DC=loc" -exterr

AdMod V01.18.00cpp Joe Richards (joe@joeware.net) March 2012

DN Count: 1
Using server: K16SC-DC1.multimanage.test.loc:389
Directory: Windows Server 2008 R2
Base DN: cn=testcomputer,cn=computers,DC=multimanage,DC=test,DC=loc

Modifying specified objects…
   DN: cn=testcomputer,cn=computers,DC=multimanage,DC=test,DC=loc…: [K16SC-DC1.multimanage.test.loc] Error 0x13 (19) – Constraint Violation

   Extended Error: 000020B5: AtrErr: DSID-03152E86, #1:
        0: 000020B5: DSID-03152E86, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9667ed48 (joeware-ManagedBy-Bin)

ERROR: Too many errors encountered, terminating…

The command did not complete successfully

You may think well gee golly, that DN with Binary error sure is different, what is going on there? I can’t really say. Personally I would expect a similar invalid syntax error as is the case with DN with String or both have the same sort of Constraint Violation error (especially with the attribute info as the Constraint Violation error which is useful when updating multiple attributes at once). 

The secret for DN-String is that the oMObjectClass value that needs to be set for the DN with String format is – 0x2A 0x86 0x48 0x86 0xF7 0x14 0x01 0x01 0x01 0x0C which translates to the OID 1.2.840.113556.1.1.1.12. In an LDIF file it will look like (KoZIhvcUAQEBDA==) and for an AdMod Schema update it would look like (2A864886F7140101010C).

The secret for DN-Binary is that the oMObjectClass value that needs to be set for the DN with Binary format is – 0x2A 0x86 0x48 0x86 0xF7 0x14 0x01 0x01 0x01 0x0B which translates to the OID 1.2.840.113556.1.1.1.11. In an LDIF file it will look like (KoZIhvcUAQEBCw==) and for an AdMod Schema update it would look like (2A864886F7140101010B).

So after all of that here is how you can define these attributes in the schema. For fun I have allocated space for this from my personal Joeware OID space (1.2.840.113556.1.8000.1420) that I claimed from MSFT back when they first offered that service (service no longer available). I am also using my standard schema prefix for my joeware stuff (joeware-).

If you choose to use these definitions, either use them exactly as defined OR change the attributeIDs and names (i.e. there should be no 1.2.840.113556.1.8000.1420.* anything and there should be no joeware-* anything).

Another Relevant Informational Side-Bar
===========================

When you add forward/back link attributes you should usually try to stick with a naming standard where you specify the forward link attribute name and then for the backlink attribute name you use the same name with BL appended. However for some attributes it may make sense to be more specific on the naming of the backlink attribute. The member / memberof pair is a great example as is the managedBy / managedObjects pair. When I am creating attribute names I try to be as specific as possible with the naming but if I am doing something related to existing attributes such as in this case I will use a variation on the existing attributes. Another example of this can be found in my blog post http://blog.joeware.net/2008/07/12/1401 – Dotted Line Managers and Reports To in Active Directory and/or ADAM. 

Creating the attributes with AdMod

Linked Multi-Multi 2.5.5.14 DN with String Attribute

:: Forward Link (Writeable)
admod  -schema -rb cn=joeware-ManagedBy -add objectclass::attributeschema attributeID::1.2.840.113556.1.8000.1420.1.2.3000 attributeSyntax::2.5.5.14 isSingleValued::FALSE adminDisplayName::joeware-ManagedBy adminDescription::joeware-ManagedBy oMSyntax::127 BIN##omobjectclass::2A864886F7140101010C lDAPDisplayName::joeware-ManagedBy systemOnly::FALSE isMemberOfPartialAttributeSet::TRUE linkid::1.2.840.113556.1.2.50 -exterr

admod  -sc refreshschema

:: Back Link (Read Only)
admod  -schema -rb cn=joeware-ManagedObjects -add objectclass::attributeschema attributeID::1.2.840.113556.1.8000.1420.1.2.3001 attributeSyntax::2.5.5.1 isSingleValued::FALSE adminDisplayName::joeware-ManagedObjects adminDescription::joeware-ManagedObjects oMSyntax::127 lDAPDisplayName::joeware-ManagedObjects systemOnly::FALSE isMemberOfPartialAttributeSet::TRUE linkid::joeware-ManagedBy -exterr

admod  -sc refreshschema

Linked Multi-Multi 2.5.5.7 DN with Binary Attribute    

:: Forward Link (Writeable)
admod  -schema -rb cn=joeware-ManagedBy-Bin -add objectclass::attributeschema attributeID::1.2.840.113556.1.8000.1420.1.2.3002 attributeSyntax::2.5.5.7 isSingleValued::FALSE adminDisplayName::joeware-ManagedBy-Bin adminDescription::joeware-ManagedBy-Bin oMSyntax::127 BIN##omobjectclass::2A864886F7140101010B lDAPDisplayName::joeware-ManagedBy-Bin systemOnly::FALSE isMemberOfPartialAttributeSet::TRUE linkid::1.2.840.113556.1.2.50  -exterr

admod  -sc refreshschema

:: Back Link (Read Only)
admod  -schema -rb cn=joeware-ManagedObjects2-Bin -add objectclass::attributeschema attributeID::1.2.840.113556.1.8000.1420.1.2.3003 attributeSyntax::2.5.5.1 isSingleValued::FALSE adminDisplayName::joeware-ManagedObjects-Bin adminDescription::joeware-ManagedObjects-Bin oMSyntax::127 lDAPDisplayName::joeware-ManagedObjects-Bin systemOnly::FALSE isMemberOfPartialAttributeSet::TRUE linkid::joeware-ManagedBy-Bin -exterr

admod  -sc refreshschema

LDIF Files for the attributes

Linked Multi-Multi 2.5.5.14 DN with String Attribute

# Forward Link (Writeable)
dn: CN=joeware-ManagedBy,SCHEMA
changetype: add
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.8000.1420.1.2.3000
attributeSyntax: 2.5.5.14
isSingleValued: FALSE
linkID: 1.2.840.113556.1.2.50
adminDisplayName: joeware-ManagedBy
oMObjectClass:: KoZIhvcUAQEBDA==
adminDescription: joeware-ManagedBy
oMSyntax: 127
lDAPDisplayName: joeware-ManagedBy
isMemberOfPartialAttributeSet: TRUE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

# Back Link (Read Only)
dn: CN=joeware-ManagedObjects,SCHEMA
changetype: add
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.8000.1420.1.2.3001
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
linkID: joeware-ManagedBy
adminDisplayName: joeware-ManagedObjects
oMObjectClass:: KwwCh3McAIVK
adminDescription: joeware-ManagedObjects
oMSyntax: 127
lDAPDisplayName: joeware-ManagedObjects
isMemberOfPartialAttributeSet: TRUE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

Linked Multi-Multi 2.5.5.7 DN with Binary Attribute

# Forward Link (Writeable)
dn: CN=joeware-ManagedBy-Bin,SCHEMA
changetype: add
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.8000.1420.1.2.3002
attributeSyntax: 2.5.5.7
isSingleValued: FALSE
linkID: 1.2.840.113556.1.2.50
adminDisplayName: joeware-ManagedBy-Bin
oMObjectClass:: KoZIhvcUAQEBCw==
adminDescription: joeware-ManagedBy-Bin
oMSyntax: 127
lDAPDisplayName: joeware-ManagedBy-Bin
isMemberOfPartialAttributeSet: TRUE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

# Back Link (Read Only)
dn: CN=joeware-ManagedObjects-Bin,SCHEMA
changetype: add
objectClass: attributeSchema
attributeID: 1.2.840.113556.1.8000.1420.1.2.3003
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
linkID: joeware-ManagedBy-Bin
adminDisplayName: joeware-ManagedObjects-Bin
oMObjectClass:: KwwCh3McAIVK
adminDescription: joeware-ManagedObjects-Bin
oMSyntax: 127
lDAPDisplayName: joeware-ManagedObjects-Bin
isMemberOfPartialAttributeSet: TRUE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

So now you have the attributes defined (or the ability to get them defined) and you just need to assign them to some object classes to use them. Which object classes? It depends on where you want the forward linked attribute functionality. If you want the functionality on computers, you can add the forward link attribute(s) to the computer objectClass definition. If you want them for computers and users you can add to the user objectClass definition and they will be useable on both users and computers. If you want them on groups you add them to the group objectClass definition. Ditto Organizational Unit objects, Ditto Containers, Ditto Organization Objects, Ditto Sites, Ditto subnets, etc. The one thing that would be cool for you to do that you can’t do is add the forward link to the Top object definition (it simply won’t work). However you absolutely can and absolutely should add the back link to the Top object.

Linking the attributes to various object classes with AdMod

Linked Multi-Multi 2.5.5.14 DN with String Attribute

Here are some commands to link the forward link attribute to multiple different classes, pick and choose as you like. The back link should be left as-is being linked to Top.

admod  -schema -rb CN=User maycontain:+:joeware-ManagedBy
admod  -schema -rb CN=Group maycontain:+:joeware-ManagedBy
admod  -schema -rb CN=Organizational-Unit maycontain:+:joeware-ManagedBy
admod  -schema -rb CN=Container maycontain:+:joeware-ManagedBy
admod  -schema -rb CN=Site maycontain:+:joeware-ManagedBy
admod  -schema -rb CN=Subnet maycontain:+:joeware-ManagedBy
admod  -schema -rb CN=Top maycontain:+:joeware-ManagedObjects
admod  -sc refreshschema  

Linked Multi-Multi 2.5.5.7 DN with Binary Attribute

Here are some commands to link the forward link attribute to multiple different classes, pick and choose as you like. The back link should be left as-is being linked to Top.

admod  -schema -rb CN=User maycontain:+:joeware-ManagedBy-Bin
admod  -schema -rb CN=Group maycontain:+:joeware-ManagedBy-Bin
admod  -schema -rb CN=Organizational-Unit maycontain:+:joeware-ManagedBy-Bin
admod  -schema -rb CN=Container maycontain:+:joeware-ManagedBy-Bin
admod  -schema -rb CN=Site maycontain:+:joeware-ManagedBy-Bin
admod  -schema -rb CN=Subnet maycontain:+:joeware-ManagedBy-Bin
admod  -schema -rb CN=Top maycontain:+:joeware-ManagedObjects-Bin
admod  -sc refreshschema  

LDIF Files for linking the attributes

Linked Multi-Multi 2.5.5.14 DN with String Attribute

# Forward Link (Writeable)
dn: CN=User,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy
–

dn: CN=Group,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy
–

dn: CN=Organizational-Unit,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy
–

dn: CN=Container,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy
–

dn: CN=Site,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy
–

dn: CN=Subnet,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy
–

# Back Link (Read Only)
dn: CN=Top,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedObjects
–

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

Linked Multi-Multi 2.5.5.7 DN with Binary Attribute

# Forward Link (Writeable)
dn: CN=User,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy-Bin
–

dn: CN=Group,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy-Bin
–

dn: CN=Organizational-Unit,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy-Bin
–

dn: CN=Container,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy-Bin
–

dn: CN=Site,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy-Bin
–

dn: CN=Subnet,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedBy-Bin
–

# Back Link (Read Only)
dn: CN=Top,SCHEMA
changetype: modify
add: mayContain
mayContain: joeware-ManagedObjects-Bin
–

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
–

That should be enough to get you and all of your friends up and running with some cool linked DN attributes with additional hopefully useful information actually in the links.

    joe

[1] Which is

[Sun 07/08/2018 12:35:08.89]
E:\Dev\Ad\Schema>wmic /node:"K16SC-DC1.multimanage.test.loc" os get version /format:list

Version=10.0.14393

I posted about this about a decade ago but going through email this morning I found at least 8 or 9 questions from people in some way shape or form related to it so I figured I would re-post and maybe it will show up search engines more or perhaps people will realize it still works…

Q: Every time I look at a network trace from AdFind I see something like:

This is called LDAP Sealing. You can disable this by disabling Client Signing/Sealing. Once disabled the traffic should look like:

The current Client Signing setting is maintained in the registry (of course) in the key

HKLM\System\CurrentControlSet\Services\LDAP under the value LDAPClientIntegrity.

There are three possible values

0
No signing/sealing

1
Negotiate signing/sealing

2
Require signing/sealing

You will likely see it set to 1 if it is set to anything. If it isn’t set, the default internally is 1 anyway… So if you switch this to 0, you will *generally* start seeing the LDAP traffic in the clear and it should work with most LDAP API based apps. If you are trying to do this for another app and it isn’t work then the issue could very well be that the application itself is forcing the information to be “encrypted” anyway like the AdFind -kerbenc switch does. At that point you have no choice but to use Insight for AD[1] which hooks the LDAP calls prior to being encoded.

You can see the current value of the setting with:

reg query HKLM\System\CurrentControlSet\Services\LDAP /v LDAPClientIntegrity

You will see something like:

[Sat 07/07/2018 16:46:32.47]
E:\>reg query HKLM\System\CurrentControlSet\Services\LDAP /v LDAPClientIntegrity

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LDAP
    LDAPClientIntegrity    REG_DWORD    0x1

If you want to quickly set it to 0 you can use the following command:

reg add HKLM\System\CurrentControlSet\Services\LDAP /v LDAPClientIntegrity /t REG_DWORD /d 0x00 /f

You will see something like:

[Sat 07/07/2018 16:46:43.63]
E:\>reg add HKLM\System\CurrentControlSet\Services\LDAP /v LDAPClientIntegrity /t REG_DWORD /d 0x00 /f
The operation completed successfully.

Note that this can also be set through Group Policy so you may find that you set it to 0 and then later it goes back to 1 or even possibly 2. If that happens a GPO was configured to define a value for Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Network Security: LDAP client signing requirements.

     joe

[1] Insight for Active Directory (AD) is an old tool from SysInternals that used to absolutely rock. It hooked the LDAP API calls so every single call that came through you had visibility into what it was doing. At some point this tool broke hard and was worthless and was absolutely worthless for x64. However SysInternals eventually released a new version V1.2 which worked again but I personally have found it to be very hit and miss. Try it, if it helps you and you like it, awesome. Keep in mind that at least I have found this latest version to be quite sporadic on x64 Windows 10 missing calls as well as crashing outright. https://docs.microsoft.com/en-us/sysinternals/downloads/adinsight