fp_idmworks
New Member.
1604 views

SSPR 4.02 search for Administrator Group not returning users


Below is a trace out of trying to return the results of the
administrator group setting in the filter.

Note that all I'm specifying is for the cn to be uaadmin.

The LDAP search results are fine from Apache Directory Studio, as you
see in the trace, but from SSPR it doesn't return any users.

FAILING FROM SSPR
2913007360 LDAP: [2017/01/03 9:06:11.399]
(10.26.132.121:40626)(0x0006:0x63) DoSearch on connection 0x39189c00
2913007360 LDAP: [2017/01/03 9:06:11.399]
(10.26.132.121:40626)(0x0006:0x63) Search request:
base: "ou=sa,o=data"
scope:2 dereference:0 sizelimit:5000 timelimit:31
attrsonly:0
filter: "(cn=uaadmin)"
attribute: "1.1"
2913007360 LDAP: [2017/01/03 9:06:11.399]
(10.26.132.121:40626)(0x0006:0x63) nds_back_search: Search Control OID
1.2.840.113556.1.4.319
2913007360 LDAP: [2017/01/03 9:06:11.399]
(10.26.132.121:40626)(0x0006:0x63) nds_back_search: Search Control OID
2.16.840.1.113730.3.4.2
2913007360 LDAP: [2017/01/03 9:06:11.400] iterCountEntries:
ispositionable returned FALSE
2913007360 LDAP: [2017/01/03 9:06:11.400]
(10.26.132.121:40626)(0x0006:0x63) Sending operation result 0:"":"" to
connection 0x39189c00



WORKING WITH ADS
2913007360 LDAP: [2017/01/03 9:06:17.712]
(10.26.132.120:50737)(0x0009:0x63) DoSearch on connection 0x35407c00
2913007360 LDAP: [2017/01/03 9:06:17.712]
(10.26.132.120:50737)(0x0009:0x63) Search request:
base: "ou=sa,o=data"
scope:2 dereference:3 sizelimit:5000 timelimit:0
attrsonly:0
filter: "(cn=uaadmin)"
attribute: "objectClass"
2913007360 LDAP: [2017/01/03 9:06:17.712]
(10.26.132.120:50737)(0x0009:0x63) Sending search result entry
"cn=uaadmin,ou=sa,o=data" to connection 0x35407c00
2913007360 LDAP: [2017/01/03 9:06:17.713]
(10.26.132.120:50737)(0x0009:0x63) Sending operation result 0:"":"" to
connection 0x35407c00



The filter being used by sspr is:
base: "ou=sa,o=data"
scope:2 dereference:0 sizelimit:5000 timelimit:31
attrsonly:0
filter: "(cn=uaadmin)"
attribute: "1.1"

Attribute 1.1 is to return no attributes, which should be fine as we
just need a dn.
We are not able to close out the sspr configuration on 4.x as we don't
have the administrators group section finding users.


--
fp_IDMWORKS
------------------------------------------------------------------------
fp_IDMWORKS's Profile: https://forums.netiq.com/member.php?userid=9869
View this thread: https://forums.netiq.com/showthread.php?t=57138

0 Likes
16 Replies
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users

I saw this and asked about it a week or two ago and I think this is a
combination of quirk and bug.

In my testing, I tried using an admin container like you have separate
from my main users container; this is not something SSPR likes, so if you
have a contextless login base of something like dc=org or dc=data where
all of the main users are, then you need to add another contextless login
base for your admin container(s). I think this will help you, but let me
know if not. The need for this is, I believe, at least a quirk. It seems
that the contextless login bases are needed by lots of things within SSPR.

As an alternative, I tried specifying a zero-length base (top of tree) for
SSPR so it would find all users everywhere, and SSPR does not like this at
all. This, I believe, is a bug, but we'll see if it gets accepted as such.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
fp_idmworks
New Member.

Re: SSPR 4.02 search for Administrator Group not returning users


Thanks Aaron. Happy New Year!

Yes I did set an authentication base to both the sa.data and the
user.data containers.

I have a ticket open, so we will see what comes of it.


--
fp_IDMWORKS
------------------------------------------------------------------------
fp_IDMWORKS's Profile: https://forums.netiq.com/member.php?userid=9869
View this thread: https://forums.netiq.com/showthread.php?t=57138

0 Likes
Micro Focus Contributor
Micro Focus Contributor

Re: SSPR 4.02 search for Administrator Group not returning u

fp_IDMWORKS;2447748 wrote:
Thanks Aaron. Happy New Year!

Yes I did set an authentication base to both the sa.data and the
user.data containers.

I have a ticket open, so we will see what comes of it.


--
fp_IDMWORKS
------------------------------------------------------------------------
fp_IDMWORKS's Profile: https://forums.netiq.com/member.php?userid=9869
View this thread: https://forums.netiq.com/showthread.php?t=57138


There is a similar issue that is caused by a bug in earlier versions of eDirectory 9 when used with paged ldap searches (which SSPR uses). Make sure your running the latest patches if your on eDirectory 9.
0 Likes
fp_idmworks
New Member.

Re: SSPR 4.02 search for Administrator Group not returning users


Thanks Guys!

patching to 888p9_hf1 fixed the issue.


--
fp_IDMWORKS
------------------------------------------------------------------------
fp_IDMWORKS's Profile: https://forums.netiq.com/member.php?userid=9869
View this thread: https://forums.netiq.com/showthread.php?t=57138

0 Likes
fp_idmworks
New Member.

Re: SSPR 4.02 search for Administrator Group not returning users


Have a ticket open with NetIQ. ED was able to duplicate the issue.


--
fp_IDMWORKS
------------------------------------------------------------------------
fp_IDMWORKS's Profile: https://forums.netiq.com/member.php?userid=9869
View this thread: https://forums.netiq.com/showthread.php?t=57138

0 Likes
mroyall Absent Member.
Absent Member.

Re: SSPR 4.02 search for Administrator Group not returning u

eDirectory bug 1012208.
The issue is caused by eDirectory not returning results during certain types (paged list) of LDAP queries. Updating to the latest public patch of eDir 8.8 or eDir 9 will resolve the problem.
Patch for 8.8 can be found here. https://dl.netiq.com/Download?buildid=UXcUa0UNvHw~
0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users


>
> The filter being used by sspr is:
> base: "ou=sa,o=data"
> scope:2 dereference:0 sizelimit:5000 timelimit:31
> attrsonly:0
> filter: "(cn=uaadmin)"
> attribute: "1.1"
>
> Attribute 1.1 is to return no attributes, which should be fine as we
> just need a dn.
> We are not able to close out the sspr configuration on 4.x as we don't
> have the administrators group section finding users.


So one thing you did not call out, and I am seeing in an implementation
is that the filter is not returning in the timelimit of 31 milliseconds
that are available.

We are using Group Membership equals a DN. Works in an LDAP tool,
tested our filter there.

We noticed the value of timelimit is milliseconds, since if you use
Apache DS and query for 30 seconds, you get 30,099 as the time limit.

It is interesting in that all the queries we look at, only the test for
Admin seems to generate this timelimit.

We tried in 4.1.0.0 and 4.2.0.2 as well.

Fred's example here shows that it does it that way as well.

(We tried indexing groupMembership to boost return performance, no joy.
We tried (cn=Admin) as the filter, and the base of the top container,
thinking that would be found fast. No joy.

The sizelimit only shows up in some queries as well. So clearly some of
the calls to LDAPChai inside SSPR are passing parameters and others are
using defaults. (Or maybe it is the other way around, and the default is
31ms and 5000 and all the other examples specify the values?)

A

0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users

On 01/29/2018 01:54 PM, Geoffrey Carman wrote:
>
>>
>> The filter being used by sspr is:
>> base: "ou=sa,o=data"
>> scope:2 dereference:0 sizelimit:5000 timelimit:31
>> attrsonly:0
>> filter: "(cn=uaadmin)"
>> attribute: "1.1"
>>
>> Attribute 1.1 is to return no attributes, which should be fine as we
>> just need a dn.
>> We are not able to close out the sspr configuration on 4.x as we don't
>> have the administrators group section finding users.

>
> So one thing you did not call out, and I am seeing in an implementation is
> that the filter is not returning in the timelimit of 31 milliseconds that
> are available.


Unless I am greatly mistaken, those are seconds, not milliseconds, at
least with eDirectory 8.8.x. I have never seen any LDAP implementation
care about milliseconds in things user-facing, though, so I doubt this
changes anywhere.

Tested in one of my environments:

3974276864 LDAP: [2018/01/29 14:30:58.405] New cleartext connection
0xcc46e00 from 127.0.0.1:48900, monitor = 0xcf762700, index = 2
3978487552 LDAP: [2018/01/29 14:30:58.405] (127.0.0.1:48900)(0x0001:0x60)
DoBind on connection 0xcc46e00
3978487552 LDAP: [2018/01/29 14:30:58.405] (127.0.0.1:48900)(0x0001:0x60)
Treating simple bind with empty DN and no password as anonymous
3978487552 LDAP: [2018/01/29 14:30:58.405] (127.0.0.1:48900)(0x0001:0x60)
Bind name:NULL, version:3, authentication:simple
3978487552 LDAP: [2018/01/29 14:30:58.406] (127.0.0.1:48900)(0x0001:0x60)
Sending operation result 0:"":"" to connection 0xcc46e00
3461998336 LDAP: [2018/01/29 14:30:58.406] (127.0.0.1:48900)(0x0002:0x63)
DoSearch on connection 0xcc46e00
3461998336 LDAP: [2018/01/29 14:30:58.406] (127.0.0.1:48900)(0x0002:0x63)
Search request:
base: ""
scope:2 dereference:0 sizelimit:0 timelimit:31 attrsonly:0
filter: "(uid=admin)"
attribute: "dn"
3461998336 LDAP: [2018/01/29 14:30:58.406] (127.0.0.1:48900)(0x0002:0x63)
Sending search result entry "cn=admin,dc=sa,dc=system" to connection 0xcc46e00
3461998336 LDAP: [2018/01/29 14:30:58.407] (127.0.0.1:48900)(0x0002:0x63)
Sending operation result 0:"":"" to connection 0xcc46e00
3982698240 LDAP: [2018/01/29 14:30:58.407] (127.0.0.1:48900)(0x0003:0x42)
DoUnbind on connection 0xcc46e00
3982698240 LDAP: [2018/01/29 14:30:58.407] Connection 0xcc46e00 closed


The command used to test was the following from the same SLES 11
SP-whatever box:


ldapsearch -x -LLL -l 31 uid=admin dn


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users

> Unless I am greatly mistaken, those are seconds, not milliseconds, at
> least with eDirectory 8.8.x. I have never seen any LDAP implementation
> care about milliseconds in things user-facing, though, so I doubt this
> changes anywhere.


I normally would agree with you, but we set Apache DS's timeout to 30
seconds and we got shown 30999 in the LDAP search. Which makes me think
it is milliseconds.

How do you know that the -l option is second based not milliseconds? I
didnot look at the docs to see.


> Tested in one of my environments:
>

> 3974276864 LDAP: [2018/01/29 14:30:58.405] New cleartext connection
> 0xcc46e00 from 127.0.0.1:48900, monitor = 0xcf762700, index = 2
> 3978487552 LDAP: [2018/01/29 14:30:58.405] (127.0.0.1:48900)(0x0001:0x60)
> DoBind on connection 0xcc46e00
> 3978487552 LDAP: [2018/01/29 14:30:58.405] (127.0.0.1:48900)(0x0001:0x60)
> Treating simple bind with empty DN and no password as anonymous
> 3978487552 LDAP: [2018/01/29 14:30:58.405] (127.0.0.1:48900)(0x0001:0x60)
> Bind name:NULL, version:3, authentication:simple
> 3978487552 LDAP: [2018/01/29 14:30:58.406] (127.0.0.1:48900)(0x0001:0x60)
> Sending operation result 0:"":"" to connection 0xcc46e00
> 3461998336 LDAP: [2018/01/29 14:30:58.406] (127.0.0.1:48900)(0x0002:0x63)
> DoSearch on connection 0xcc46e00
> 3461998336 LDAP: [2018/01/29 14:30:58.406] (127.0.0.1:48900)(0x0002:0x63)
> Search request:
> base: ""
> scope:2 dereference:0 sizelimit:0 timelimit:31 attrsonly:0
> filter: "(uid=admin)"
> attribute: "dn"
> 3461998336 LDAP: [2018/01/29 14:30:58.406] (127.0.0.1:48900)(0x0002:0x63)
> Sending search result entry "cn=admin,dc=sa,dc=system" to connection 0xcc46e00
> 3461998336 LDAP: [2018/01/29 14:30:58.407] (127.0.0.1:48900)(0x0002:0x63)
> Sending operation result 0:"":"" to connection 0xcc46e00
> 3982698240 LDAP: [2018/01/29 14:30:58.407] (127.0.0.1:48900)(0x0003:0x42)
> DoUnbind on connection 0xcc46e00
> 3982698240 LDAP: [2018/01/29 14:30:58.407] Connection 0xcc46e00 closed
>

>
> The command used to test was the following from the same SLES 11
> SP-whatever box:
>
>

> ldapsearch -x -LLL -l 31 uid=admin dn
>

>


0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users

On 01/29/2018 02:47 PM, Geoffrey Carman wrote:
>> Unless I am greatly mistaken, those are seconds, not milliseconds, at
>> least with eDirectory 8.8.x. I have never seen any LDAP implementation
>> care about milliseconds in things user-facing, though, so I doubt this
>> changes anywhere.

>
> I normally would agree with you, but we set Apache DS's timeout to 30
> seconds and we got shown 30999 in the LDAP search. Which makes me think
> it is milliseconds.


I would not be surprised if a bug in Apache Directory Studio accidentally
sent the wrong number on the wire. Oops for them.

From the LDAP RFC: https://tools.ietf.org/html/rfc4511#section-4.5.1.5


A time limit that restricts the maximum time (in seconds) allowed for
a Search. A value of zero in this field indicates that no client-
requested time limit restrictions are in effect for the Search.
Servers may also enforce a maximum time limit for the Search.


There is no reason for eDirectory to show more granularity than a single
second when the LDAP RFC doesn't bother doing anything else.

> How do you know that the -l option is second based not milliseconds? I
> didnot look at the docs to see.


Either the 'ldapserach --help' command, or the manpage, tells me so. I
think the chances of bugs existing in here are smaller than the chances of
a bug being in Apache Directory Studio.

Testing that a bit more, I tried this:


ldapsearch -x -LLL -l 10 cn=* dn


That returned nicely, within a few seconds, but if I change the timelimit
to one (1) then I get an LDAP error three (3) stating time exceeded. It
is possible, I suppose, that the difference between one (1) millisecond
and ten (10) milliseconds was the cause for that change, but I think it
far more-likely that it was seconds, not milliseconds, making the
unindexed search possible with the longer time limit.

Note that none of this may matter to the issue you are helping resolve; I
just wanted to be sure that the right units were used, since a factor of
1000 is a big one when it comes to searches.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users

On 1/29/2018 5:43 PM, ab wrote:
> On 01/29/2018 02:47 PM, Geoffrey Carman wrote:
>>> Unless I am greatly mistaken, those are seconds, not milliseconds, at
>>> least with eDirectory 8.8.x. I have never seen any LDAP implementation
>>> care about milliseconds in things user-facing, though, so I doubt this
>>> changes anywhere.

>>
>> I normally would agree with you, but we set Apache DS's timeout to 30
>> seconds and we got shown 30999 in the LDAP search. Which makes me think
>> it is milliseconds.

>
> I would not be surprised if a bug in Apache Directory Studio accidentally
> sent the wrong number on the wire. Oops for them.


That may well be. We added a parameter to the SSPRConfiguration.xml file as:

<setting key="ldap.search.timeoutSeconds" syntax="STRING"
syntaxVersion="0" modifyTime="2018-01-29T15:10:37Z">
<value>9098</value>
</setting>

And SSPR queried with a timeout of 9099 (Seems to add 1 to it each time).

But still not finding our Admin group.

LDAP search as same bind user, against same eDir replica, cannot find
it, neither by filter (groupMembership=DN of group) nor by using the
Group Membership button instead of a raw filter (Which lets SSPR build
the filter).

Odd behavior.
Dstrace shows the query that looks good, scope 2, timeout with a higher
value now, the filter looks right (copied from a working example in
Apache DS) base is correct (tree is dc rooted, so dc=net) nothing obvious.



0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users

Just to be clear, have you tried making sure eDirectory is current? This
year-old thread was resolved with a "fixed with latest code" response so
pursuing something else seems like a waste of time. Which exact version
are you on, and could you post your full LDAP trace showing the query and
responses?

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users

On 1/30/2018 9:31 AM, ab wrote:
> Just to be clear, have you tried making sure eDirectory is current? This
> year-old thread was resolved with a "fixed with latest code" response so
> pursuing something else seems like a waste of time. Which exact version
> are you on, and could you post your full LDAP trace showing the query and
> responses?


Ya, I thought about that. Remote system, I am helping a colleague with
via screen sharing so cannot snip. Will get some more info out of it
and report back.


0 Likes
Knowledge Partner
Knowledge Partner

Re: SSPR 4.02 search for Administrator Group not returning users

On 1/30/2018 9:31 AM, ab wrote:
> Just to be clear, have you tried making sure eDirectory is current? This
> year-old thread was resolved with a "fixed with latest code" response so
> pursuing something else seems like a waste of time. Which exact version
> are you on, and could you post your full LDAP trace showing the query and
> responses?


The issue reported seems to be that a paged query is not returning
properly. Would that apply to any simple query? I see other queries
SSPR does return properly. Hmm, I do recall see extensions referenced
before some queries...

Would a simple query like (Cn=admin) avoid using paged queries, or is
once you use the extension you can run into problems?

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.