What does it mean when I see "Schema (1.1) not found" in my DSA's warn logs?

Document ID : KB000053832
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

The most common reasons why the warning message "Schema (1.1) not found" is generated, concerns the routing of unknown schema by a CA Directory DSA. This technical document explains in detail both the symptom, the cause and the resolution of the issue.

Solution:

Symptom

In the DSA's warn log, you may find that you will see the following messages:

[3692] 20090304.155412.538 WARN : Schema: '(1.1)' not found[3692] 20090304.155412.538 WARN : LDAP: unknown attr: (1.1)[3692] 20090304.155412.554 WARN : Schema: '(1.1)' not found[3692] 20090304.155412.554 WARN : LDAP: unknown attr: (1.1)

Cause

When CA Directory processes an operation and finds that the search filter contains unknown schema, it will generate the "Schema: (1.1)" warning messages. This is most commonly found when a customer is routing operations to a third party LDAP server over a DXLINK connection.

A trace=all debug trace of an operation being routed to an Active Directory Server is displayed below. In this example, the LDAP search is searching for "samAccountName", which is an AD attribute that is unknown to the CA Directory router DSA. In the example it has been highlighted in the relevant sections of the trace.

> [3692] <-- LDAP MESSAGE messageID 14> [3692] SearchRequest> [3692]  baseObject: cn=user1,ou=users,c=us> [3692]  scope: wholeSubtree> [3692]  derefAliases: derefAlways> [3692]  sizeLimit: 0> [3692]  timeLimit: 0> [3692]  typesOnly: false> [3692]  filter:> [3692]   equalityMatch: samAccountName = test> [3692]  attributes:> [3692]   objectClass> [3692] controls:> [3692]   controlType: 2.16.840.1.113730.3.4.2> [3692]   non-critical> [3692] ? [3692] 20090304.155412.538 WARN : LDAP: unknown attr-type: samAccountName? [3692] 20090304.155412.538 WARN : Schema: '(1.1)' not found? [3692] 20090304.155412.538 WARN : LDAP: unknown attr: (1.1)! [3692] > [3692] > [3692] <- #6 LDAP SEARCH-REQ> [3692]  invoke-id = 14   credit = 4> [3692]     Base object:> [3692]         <countryName "co">> [3692]         <cosineDomainComponent "AD_CO">> [3692]         <organizationalUnitName "Usuarios Comcel">> [3692]         <organizationalUnitName "Externos">> [3692]         <commonName "Carlos Andres Gonzalez Casas">> [3692]     Search subset: Whole subtree> [3692]     Filter:> [3692]         (1.1) = (unreg)> [3692]     Attributes to return:  > [3692]         objectClass> [3692]     Controls:> [3692]         manage-dsa-it

In the highlighted sections above, you can see that the CA Directory router DSA determines that "samAccountName" is unknown to it. The DSA will substitute the attribute OID of "1.1", and continue the search. As a result, the search will not return any results, as the attribute of "1.1" is unknown.

Resolution

In order to instruct a CA Directory DSA to route unknown schema, you need to add the following configuration command to the end of the DSA's knowledge file (after the "set dsa" command):

  set transparent-routing = true ;

Once the transparent-routing command is added and the file is saved, stop and start your CA Directory DSA.

If the same search is performed after the transparent-routing command is added, the DSA will route the operation unmodified, and generate no errors. The search is displayed below as a reference:

> [2000] <-- LDAP MESSAGE messageID 12> [2000] SearchRequest> [2000]  baseObject: cn=user1,ou=users,c=us> [2000]  scope: wholeSubtree> [2000]  derefAliases: derefAlways> [2000]  sizeLimit: 0> [2000]  timeLimit: 0> [2000]  typesOnly: false> [2000]  filter:> [2000]   equalityMatch: samAccountName = test> [2000]  attributes:> [2000]   objectClass> [2000] controls:> [2000]   controlType: 2.16.840.1.113730.3.4.2> [2000]   non-critical> [2000] ! [2000] > [2000] > [2000] <- #0 LDAP SEARCH-REQ> [2000]  invoke-id = 12   credit = 4> [2000]     Base object:> [2000]         <countryName "us">> [2000]         <organizationalUnitName Users>> [2000]         <commonName user1>> [2000]     Search subset: Whole subtree> [2000]     Filter:> [2000]         !samAccountName = (unreg)test> [2000]     Attributes to return:  > [2000]         objectClass> [2000]     Controls:> [2000]         manage-dsa-it> [2000] ! [2000] RemoteSendRequest: rop 01C2619C command 0 busy 1! [2000] ----------RemoteSendIdu (001/007)--------20090304.155723.663 ! [2000] RemoteSendIdu: updateIdleTime 1! [2000] RemoteRemapRequest! [2000] > [2000] > [2000] (Remote) -> #1 [AD_DSA] DXLINK SEARCH-REQ> [2000]  invoke-id = 7   credit = 1> [2000]     Base object:> [2000]         <cosineDomainComponent "com">> [2000]         <organizationalUnitName "Users">> [2000]         <commonName "user1">> [2000]     Search subset: Whole subtree> [2000]     Filter:> [2000]         !samAccountName = (unreg)test> [2000]     Attributes to return:  > [2000]         objectClass> [2000]     Chaining Arguments:> [2000]  Originator:> [2000]             <commonName "Administrator">> [2000]  Trace Information:> [2000]      DSA:> [2000]                 <countryName "us">> [2000]                 <commonName "DXserver">> [2000]             Operation Progress: Name Resolution Phase:  Not Started> [2000]         Controls:> [2000]             manage-dsa-it> [2000]  Auth Level:  simple> [2000]     Controls:> [2000]         manage-dsa-it> [2000] > [2000] > [2000] --> LDAP MESSAGE messageID 7> [2000] SearchRequest> [2000]  baseObject: cn=user1,ou=users,dc=com> [2000]  scope: wholeSubtree> [2000]  derefAliases: derefAlways> [2000]  sizeLimit: 0> [2000]  timeLimit: 0> [2000]  typesOnly: false> [2000]  filter:> [2000]   equalityMatch: samAccountName = test> [2000]  attributes:> [2000]   objectClass> [2000] controls:> [2000]   controlType: 2.16.840.1.113730.3.4.2> [2000]   non-critical> [2000] ! [2000] userCheckAssocLOCK 1c03f7c dsa=1c55f38 busy=0! [2000] userCheckOpLOCK 1c39704! [2000] userCheckAssocLOCK 1c52344 dsa=0 busy=0> [3984] > [3984] <-- LDAP MESSAGE messageID 7> [3984] SearchResDone> [3984]  resultCode: success> [3984]  matchedDN: > [3984]  errorMessage:> [3984]

The end result is that the search is sent to the third party LDAP server without being modified in any way, and there are no messages generated in the warning log.