Search results different from the SSO Policy server and manual search from command line
search cancel

Search results different from the SSO Policy server and manual search from command line


Article ID: 43728


Updated On:


CA Single Sign On Secure Proxy Server (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) CA Single Sign-On


Question: Why do we get different count of entities (siteminder query vs. manual run).. We would like to understand the difference. We have included the stats for your reference in the attachment

Connection made using SiteminderAdmin

[25/May/2016:15:31:20 -0500] conn=904344 op=9747 msgId=9748 - SRCH base="ou=xps,ou=policysvr4,ou=siteminder,ou=netegrity,dc=example,dc=com" scope=1 filter="(&(objectClass=xpsObject)(|(xpsCategory=2)(xpsCategory=3)))" attrs="* modifyTimestamp createTimestamp"
[25/May/2016:15:31:20 -0500] conn=904344 op=9747 msgId=9748 -  SORT modifyTimestamp
[25/May/2016:15:31:20 -0500] conn=904344 op=9747 msgId=9748 -  VLV 0:1000:20160525202552Z 19286:19287 (0)
[25/May/2016:15:31:20 -0500] conn=904344 op=9747 msgId=9748 - RESULT err=0 tag=101 nentries=2 etime=0.001000


Connection made by LDAP Directory Admin (manual ldapsearch)

[25/May/2016:15:35:24 -0500] conn=911235 op=-1 msgId=-1 - fd=212 slot=212 LDAP connection from ::1:43085 to ::1
[25/May/2016:15:35:24 -0500] conn=911235 op=0 msgId=1 - BIND dn="cn=xxx" method=128 version=3
[25/May/2016:15:35:24 -0500] conn=911235 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0.000000 dn="cn=xxx"
[25/May/2016:15:35:24 -0500] conn=911235 op=1 msgId=2 - SRCH base="ou=xps,ou=policysvr4,ou=siteminder,ou=netegrity,dc=example,dc=com" scope=1 filter="(&(objectClass=xpsObject)(|(xpsCategory=2)(xpsCategory=3)))" attrs="dn"
[25/May/2016:15:35:24 -0500] conn=911235 op=1 msgId=2 - RESULT err=0 tag=101 nentries=19287 etime=0.200000



Component: SMPLC



Siteminder policy server when initializing the LDAP directory will check for support control list, specifically Virtual List View Control (VLV)

ldapsearch -h _host -p10001  -b "" -s base "(objectclass=*)" supportedcontrol > rootDSE.txt


version: 1
supportedcontrol: 2.16.840.1.113730.3.4.2
supportedcontrol: 2.16.840.1.113730.3.4.3
supportedcontrol: 2.16.840.1.113730.3.4.4
supportedcontrol: 2.16.840.1.113730.3.4.5
supportedcontrol: 1.2.840.113556.1.4.473
supportedcontrol: 2.16.840.1.113730.3.4.9
supportedcontrol: 2.16.840.1.113730.3.4.16
supportedcontrol: 2.16.840.1.113730.3.4.15
supportedcontrol: 2.16.840.1.113730.3.4.17
supportedcontrol: 2.16.840.1.113730.3.4.19
supportedcontrol: 2.16.840.1.113730.3.4.14
supportedcontrol: 2.16.840.1.113730.3.4.12
supportedcontrol: 2.16.840.1.113730.3.4.18
supportedcontrol: 2.16.840.1.113730.3.4.13

Housekeeping thread is a VLV search (2.16.840.1.113730.3.4.9) – not expected to return ALL the objects in the store

 One of the steps to setup ODSEE as a policy store is to run the following (sets ups the VLV search)

ldapsetup -ldmod <SSO Policy Server_home>/xps/db/OracleDirectoryServerBrowse.ldif (NOTE: Root DN must be modified first)

dn: cn=xps_housekeep_index,cn=PolicySvr4,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectClass: top
objectClass: vlvSearch
cn: xps_housekeep_index
vlvBase: ou=xps,ou=PolicySvr4,ou=siteminder,ou=netegrity,<Root DN>
vlvScope: 1
vlvFilter: (&(objectClass=xpsObject)(|(xpsCategory=2)(xpsCategory=3))

If you look closer at the search provided the breakdown is as followed

  • Before=0*. Specifies that 0 entries before the target should be displayed.
  • After=1000*. Specifies that 1000 entries after the target should be displayed.
  • Index=20160525202552Z*. Specifies that the string 20160525202552Z within the result set be returned.
  • Count=not specified*. Use the default count=0, which is the first entry. 

How to manual perform same search

ldapsearch -h _host -p5014 -b "ou=xps,ou=policysvr4,ou=siteminder,ou=netegrity ," -s one -D "cn=xxx" -w "xxx" -G "0:1000:20160526160810Z:0" --sortOrder modifyTimestamp  "(&(objectClass=xpsObject)(|(xpsCategory=2)(xpsCategory=3)))" modifyTimestamp

Basically the policy server is not expecting OR looking to return all LDAP entries