Knowledge Partner
Knowledge Partner
1083 views

Helpdesk module - user searching not working

OK, so I was testing the Helpdesk module and left the User Search query blank, which according to the docs, says that SSPR will then construct the LDAP query based on the (in my case, the DEFAULT) search items like:
cn, last name, first name, etc.

Comes back with no results found.

I fired up LDAP trade via iMonitor. (back end is OES11 SP2, and I Think eDir 8.8.8.something)

Anyway, this is what it looks like it's doing:


09:24:02 6E317700 LDAP: (09:24:02 6E317700 LDAP: (134.179.106.109:45036)(0x0005:0x63) Search request:
base: "ou=CO,o=abc"
scope:2 dereference:0 sizelimit:501 timelimit:31 attrsonly:0
filter: "(&(objectClass=inetOrgPerson)(|(cn=*kjhurni*)(givenName=*kjhurni*)(sn=*kjhurni*)(mail=*kjhurni*)(workforceID=*kjhurni*)))"
attribute: "mail"
attribute: "givenName"
attribute: "cn"
attribute: "sn"
attribute: "workforceID".106.109:45036)(0x0005:0x63) Search request:
base: "ou=CO,o=abc"
scope:2 dereference:0 sizelimit:501 timelimit:31 attrsonly:0
filter: "(&(objectClass=inetOrgPerson)(|(cn=*kjhurni*)(givenName=*kjhurni*)(sn=*kjhurni*)(mail=*kjhurni*)(workforceID=*kjhurni*)))"
attribute: "mail"
attribute: "givenName"
attribute: "cn"
attribute: "sn"
attribute: "workforceID"
09:24:02 6E317700 LDAP: (192.168.106.109:45036)(0x0005:0x63) nds_back_search: Search Control OID 1.2.840.113556.1.4.319
09:24:02 6E317700 LDAP: (192.168.106.109:45036)(0x0005:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
09:24:02 6E317700 LDAP: iterCountEntries: ispositionable returned FALSE
09:24:02 6E317700 LDAP: (192.168.106.109:45036)(0x0005:0x63) SearchWithControls: iterator copy request failed with -714
09:24:02 6E317700 LDAP: (192.168.106.109:45036)(0x0005:0x63) nds_back_search: Failure of non-critical control ignored, err = not implemented (-714)
09:24:02 6E317700 LDAP: (192.168.106.109:45036)(0x0005:0x63) Sending operation result 0:"":"" to connection 0x109fa380
09:24:02 7124D700 LDAP: (192.168.106.109:45036)(0x0006:0x63) DoSearch on connection 0x109fa380
09:24:02 7124D700 LDAP: (192.168.106.109:45036)(0x0006:0x63) Search request:


Any ideas? Or should I ask this over in the eDir forum?
0 Likes
7 Replies
Knowledge Partner
Knowledge Partner

Re: Helpdesk module - user searching not working

I presume that 'ou=CO,o=abc' is a valid context for your environment, or
perhaps it is something you changed to post the trace.

Other than that, the -714 is an eDirectory error, but it means that the
control attempted is not valid. The 1.2.840.113556.1.4.319 OID is for
paged results, but those should generally work with any version of
eDirectory but perhaps it did not because of the bad base scope (if you
did not change that), or because the user lacks rights (try with admin),
or because of something else within eDirectory.

If I were you I would check your RootDSE with an LDAP tool and see if that
OID is advertised. For example, on the eDirectory server itself:


ldapsearch -x -b '' -s base | grep 1.2.840.113556.1.4.319


On my 8.8 SP8 system I get one line returned with that OID, confirming it
is supported. You could also try this to see all of them in case the
ManageDSA option is not there, but that would be weird too:

[CODE[
ldapsearch -x -b '' -s base


Is it safe to assume that your eDirectory server has a replica of all
objects within that subtree you specified?

--
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: Helpdesk module - user searching not working

ab;2465225 wrote:
I presume that 'ou=CO,o=abc' is a valid context for your environment, or
perhaps it is something you changed to post the trace.

Other than that, the -714 is an eDirectory error, but it means that the
control attempted is not valid. The 1.2.840.113556.1.4.319 OID is for
paged results, but those should generally work with any version of
eDirectory but perhaps it did not because of the bad base scope (if you
did not change that), or because the user lacks rights (try with admin),
or because of something else within eDirectory.

If I were you I would check your RootDSE with an LDAP tool and see if that
OID is advertised. For example, on the eDirectory server itself:


ldapsearch -x -b '' -s base | grep 1.2.840.113556.1.4.319


On my 8.8 SP8 system I get one line returned with that OID, confirming it
is supported. You could also try this to see all of them in case the
ManageDSA option is not there, but that would be weird too:

[CODE[
ldapsearch -x -b '' -s base


Is it safe to assume that your eDirectory server has a replica of all
objects within that subtree you specified?

--
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.


Thanks Aaron.

So yes, I changed the code to hide the innocent (haha). However, this is my test lab currently, so the tree structure was created (long time ago) via LDIF, and the O was created lower case (as opposed to Prod where the O is upper-case). Not that it should matter (the only issue we've ever run across is when doing things in Designer with drivers and such is that we have to remember to change the lower case O to upper-case O).

That being said

1) This server is the Master replica server (holds all replicas). There's another server in the tree with R/W replicas
2) Using the cn=admin,o=abc account for SSPR
3) output for the ldapsearch:

co-idm-dev1:~ # ldapsearch -x -b '' -s base | grep 1.2.840.113556.1.4.319
supportedControl: 1.2.840.113556.1.4.319


I get a big list when doing the other search, but am lazy and didn't want to have to change all the IP's and stuff, so unless you need the supported control lines it came back with, I'll leave that out for the time being.

What's REALLY strange:

It can find ONE user so far (and only one). It returns the -714 error on all other users I've tried (in the same context, BTW) including the one it actually finds, so I'm puzzled.

10:45:07 71651700 LDAP: (192.168106.109:45475)(0x0005:0x63) Search request:
base: "ou=CO,o=abc"
scope:2 dereference:0 sizelimit:501 timelimit:31 attrsonly:0
filter: "(&(objectClass=inetOrgPerson)(|(cn=*mpis*)(givenName=*mpis*)(sn=*mpis*)(mail=*mpis*)))"
attribute: "mail"
attribute: "givenName"
attribute: "cn"
attribute: "sn"
10:45:07 71651700 LDAP: (192.168106.109:45475)(0x0005:0x63) nds_back_search: Search Control OID 1.2.840.113556.1.4.319
10:45:07 71651700 LDAP: (192.168106.109:45475)(0x0005:0x63) nds_back_search: Search Control OID 2.16.840.1.113730.3.4.2
10:45:07 71651700 LDAP: iterCountEntries: ispositionable returned FALSE
10:45:07 71651700 LDAP: (192.168106.109:45475)(0x0005:0x63) SearchWithControls: iterator copy request failed with -714
10:45:07 71651700 LDAP: (192.168106.109:45475)(0x0005:0x63) nds_back_search: Failure of non-critical control ignored, err = not implemented (-714)
10:45:07 71651700 LDAP: (192.168106.109:45475)(0x0005:0x63) Sending search result entry "cn=mpistest,ou=DIS,ou=OAS,ou=CO,o=abc" to connection 0x10acd500
10:45:07 71651700 LDAP: (192.168106.109:45475)(0x0005:0x63) Sending operation result 0:"":"" to connection 0x10acd500


BTW, I had to specify multiple search bases to avoid the helpdesk from being able to "do things" via SSPR to the admin/service accounts we have in a different ou. (iMangler it's easy, you just don't scope the container), but SSPR appears you have to limit the search bases.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Helpdesk module - user searching not working

No, case does not matter in these cases (LDAP is case-aware).

I do not see anything wrong, then, other than you do not get responses
back, which I would point to rights, but you claim to be using an admin.
I guess I just will have to not believe you. 🙂

Try this out from the eDirectory box:


/usr/bin/ldapsearch -x -LLL -D cn=admin,o=abc -W -b '' -s sub
'cn=*kjhurni*' dn


If that works, then try specifying the base and the rest of the filter:


/usr/bin/ldapsearch -x -LLL -D cn=admin,o=abc -W -b 'ou=co,o=abc' -s sub
'(&(objectClass=inetOrgPerson)(|(cn=*kjhurni*)(givenName=*kjhurni*)(sn=*kjhurni*)(mail=*kjhurni*)(workforceID=*kjhurni*)))'
dn


Watch ndstrace while doing these to see if anything interesting shows up.

You may need to use TLS for the connection, and if so perhaps it would be
easier to use Apache Directory Studio, but if you want to use the command
line, here's that version too:


LDAPTLS_REQCERT=allow /usr/bin/ldapsearch -x -LLL -H
'ldaps://localhost:636' -D cn=admin,o=abc -W -b '' -s sub 'cn=*kjhurni*' 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: Helpdesk module - user searching not working

ab;2465240 wrote:
No, case does not matter in these cases (LDAP is case-aware).

I do not see anything wrong, then, other than you do not get responses
back, which I would point to rights, but you claim to be using an admin.
I guess I just will have to not believe you. 🙂

Try this out from the eDirectory box:


/usr/bin/ldapsearch -x -LLL -D cn=admin,o=abc -W -b '' -s sub
'cn=*kjhurni*' dn


If that works, then try specifying the base and the rest of the filter:


/usr/bin/ldapsearch -x -LLL -D cn=admin,o=abc -W -b 'ou=co,o=abc' -s sub
'(&(objectClass=inetOrgPerson)(|(cn=*kjhurni*)(givenName=*kjhurni*)(sn=*kjhurni*)(mail=*kjhurni*)(workforceID=*kjhurni*)))'
dn


Watch ndstrace while doing these to see if anything interesting shows up.

You may need to use TLS for the connection, and if so perhaps it would be
easier to use Apache Directory Studio, but if you want to use the command
line, here's that version too:


LDAPTLS_REQCERT=allow /usr/bin/ldapsearch -x -LLL -H
'ldaps://localhost:636' -D cn=admin,o=abc -W -b '' -s sub 'cn=*kjhurni*' 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.


So the first two ldapsearch commands work fine.

However, this got me thinking:

I don't see in the LDAP trace (although I only scanned through it) what actual user account SSPR is using when doing the LDAP queries. I *assumed* it's using the LDAP user account specified in the SSPR configuration (which is admin).

However, perhaps it's using the actual user account of the user that's logged into SSPR(?)

Although I'm fairly certain that the [Public] object has Browse/Compare rights to those items.

Although that would not exactly explain why it returns results for ONE user in a particular context, and fail to return results from (so far) all other users in that same context.

So I tried with my own account (which essentially has admin rights), and it, like the admin user, returns the dn value.

However, the user in question doesn't show an error (although I perhaps did not have all the necessary dstrace options turned on) when doing the ldapsearch (vs. SSPR which shows the -714 error):

13:57:19 8E66A700 LDAP: New cleartext connection 0x109fa700 from 127.0.0.1:45755, monitor = 0x70a2f700, index = 12
13:57:19 6E71B700 LDAP: (127.0.0.1:45755)(0x0001:0x60) DoBind on connection 0x109fa700
13:57:19 6E71B700 LDAP: (127.0.0.1:45755)(0x0001:0x60) Bind name:cn=itsuser,ou=ee-its,ou=co,o=abc, version:3, authentication:simple
13:57:19 6E71B700 NMAS: 63701026: Create NMAS Session
13:57:19 6E71B700 NMAS: 63701026: Trying local password login shortcut for CN=itsuser.OU=EE-ITS.OU=CO.O=abc
13:57:19 6E71B700 NMAS: 63701026: TCP client network address
13:57:19 6E71B700 NMAS: 63701026: sasUpdateLoginTimeInterval is not set (or) invalid. Setting to global value = 0 mins
13:57:19 6E71B700 NMAS: 63701026: UpdateLoginTimeInterval for object = 0 mins
13:57:19 6E71B700 NMAS: 63701026: NMAS Audit with Audit PA not installed
13:57:19 6E71B700 NMAS: 63701026: NMAS Audit with XDAS not installed
13:57:19 6E71B700 NMAS: 63701026: Local password login shortcut successful
13:57:19 6E71B700 NMAS: 63701026: Client Session Destroy Request
13:57:19 6E71B700 NMAS: 63701026: Destroy NMAS Session
13:57:19 6E71B700 NMAS: 63701026: Aborted Session Destroyed (with MAF)
13:57:19 6E71B700 LDAP: (127.0.0.1:45755)(0x0001:0x60) Sending operation result 0:"":"" to connection 0x109fa700
13:57:19 6FF24700 LDAP: (127.0.0.1:45755)(0x0002:0x63) DoSearch on connection 0x109fa700
13:57:19 6FF24700 LDAP: (127.0.0.1:45755)(0x0002:0x63) Search request:
base: "ou=co,o=abc"
scope:2 dereference:0 sizelimit:0 timelimit:0 attrsonly:0
filter: "(&(objectClass=inetOrgPerson)(|(cn=*kjhurni*)(givenName=*kjhurni*)(sn=*kjhurni*)(mail=*kjhurni*)(workforceID=*kjhurni*)))"
attribute: "dn"
13:57:19 6FF24700 LDAP: (127.0.0.1:45755)(0x0002:0x63) Sending operation result 0:"":"" to connection 0x109fa700
13:57:19 71651700 LDAP: (127.0.0.1:45755)(0x0003:0x42) DoUnbind on connection 0x109fa700
13:57:19 71651700 LDAP: (127.0.0.1:45755)(0x0003:0x42) Forcing abandon on operation 0x2:0x63 on connection 0x109fa700
13:57:19 6FF24700 LDAP: Connection 0x109fa700 closed
0 Likes
Knowledge Partner
Knowledge Partner

Re: Helpdesk module - user searching not working

Well I think I found an anomaly (although again, doesn't explain why one particular user will return a result and others won't).
Somehow in the test lab (must've been a result of the LDIF import) is missing a trustee (or perhaps it's leftover from the fact that prod tree started at NetWare 4.something years ago and the test lab started at like OES2 or something).

Anyway:
the:
[All Attribute Rights] = Read
is missing in Test Lab.

In Prod, the Tree object, has a trustee of:
[root]
that has:
[All Attribute Rights] set to "read" and set to inherit

That's missing in Test Lab and doesn't appear to be able to be added (there's no "root" object to choose from in iManager).

So I just added the "ou" that only the helpdesk staff are in as a trustee to the ou's I want them to be able to search and that seems to have resolved the issue.

Looks like it'll still have to be a combo of RBS roles in iManager to set the rights (ability to change passwords, etc.) and then SSPR to use as the interface.
Proxy user would technically work, but it may end up granting more rights than I care (I have to dig more into the setup as we don't, for example, want helpdesk staff to be able to monkey with the Forgotten password stuff which also includes the challenge/response data/questions).
0 Likes
Knowledge Partner
Knowledge Partner

Re: Helpdesk module - user searching not working

On 08/30/2017 12:34 PM, kjhurni wrote:
>
> Well I think I found an anomaly (although again, doesn't explain why one
> particular user will return a result and others won't).
> Somehow in the test lab (must've been a result of the LDIF import) is
> missing a trustee (or perhaps it's leftover from the fact that prod tree
> started at NetWare 4.something years ago and the test lab started at
> like OES2 or something).
>
> Anyway:
> the:
> [All Attribute Rights] = Read
> is missing in Test Lab.
>
> In Prod, the Tree object, has a trustee of:
> [root]
> that has:
> [All Attribute Rights] set to "read" and set to inherit


WARNING!!!!! This is a pretty terrible thing to have. Bad, evil, wrong.

You are effectively granting every object in your tree the ability to read
every attribute of every other object in your tree. I doubt you want
that. This should be considered a security vulnerability. The only
object needing those rights for you to have better luck is the proxy user.
Even then, it only really needs read/compare to those specific attributes
used as part of the query.

> That's missing in Test Lab and doesn't appear to be able to be added
> (there's no "root" object to choose from in iManager).


Good; stop it, and take it out of production after you grant explicit
rights where needed..

> So I just added the "ou" that only the helpdesk staff are in as a
> trustee to the ou's I want them to be able to search and that seems to
> have resolved the issue.


Yes, it would; I would still highly recommend granting rights to specific
attributes (i.e. not passwords, not ACL, not security equivalences, not
IDM drivers' attributes, etc.) at that one OU level where your users live,
and then giving those rights just to the objects which need them,
preferably a proxy user for SSPR (so that your users do not go wandering
about with lots of rights outside of SSPR, perhaps doing unintended things).

> Looks like it'll still have to be a combo of RBS roles in iManager to
> set the rights (ability to change passwords, etc.) and then SSPR to use
> as the interface.
> Proxy user would technically work, but it may end up granting more
> rights than I care (I have to dig more into the setup as we don't, for
> example, want helpdesk staff to be able to monkey with the Forgotten
> password stuff which also includes the challenge/response
> data/questions).


At least if SSPR has a proxy user with too many rights there is still the
potential that the application will prevent arbitrary use of those rights
by its users. Granting rights to all helpdesk users means they can pull
up ConsoleOne, iManager, or any LDAP-based tool, and walk around with
those same rights.

--
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: Helpdesk module - user searching not working

ab;2465267 wrote:
On 08/30/2017 12:34 PM, kjhurni wrote:
>
> Well I think I found an anomaly (although again, doesn't explain why one
> particular user will return a result and others won't).
> Somehow in the test lab (must've been a result of the LDIF import) is
> missing a trustee (or perhaps it's leftover from the fact that prod tree
> started at NetWare 4.something years ago and the test lab started at
> like OES2 or something).
>
> Anyway:
> the:
> [All Attribute Rights] = Read
> is missing in Test Lab.
>
> In Prod, the Tree object, has a trustee of:
> [root]
> that has:
> [All Attribute Rights] set to "read" and set to inherit


WARNING!!!!! This is a pretty terrible thing to have. Bad, evil, wrong.

You are effectively granting every object in your tree the ability to read
every attribute of every other object in your tree. I doubt you want
that. This should be considered a security vulnerability. The only
object needing those rights for you to have better luck is the proxy user.
Even then, it only really needs read/compare to those specific attributes
used as part of the query.

> That's missing in Test Lab and doesn't appear to be able to be added
> (there's no "root" object to choose from in iManager).


Good; stop it, and take it out of production after you grant explicit
rights where needed..

> So I just added the "ou" that only the helpdesk staff are in as a
> trustee to the ou's I want them to be able to search and that seems to
> have resolved the issue.


Yes, it would; I would still highly recommend granting rights to specific
attributes (i.e. not passwords, not ACL, not security equivalences, not
IDM drivers' attributes, etc.) at that one OU level where your users live,
and then giving those rights just to the objects which need them,
preferably a proxy user for SSPR (so that your users do not go wandering
about with lots of rights outside of SSPR, perhaps doing unintended things).

> Looks like it'll still have to be a combo of RBS roles in iManager to
> set the rights (ability to change passwords, etc.) and then SSPR to use
> as the interface.
> Proxy user would technically work, but it may end up granting more
> rights than I care (I have to dig more into the setup as we don't, for
> example, want helpdesk staff to be able to monkey with the Forgotten
> password stuff which also includes the challenge/response
> data/questions).


At least if SSPR has a proxy user with too many rights there is still the
potential that the application will prevent arbitrary use of those rights
by its users. Granting rights to all helpdesk users means they can pull
up ConsoleOne, iManager, or any LDAP-based tool, and walk around with
those same rights.

--
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.


Thanks! I honestly don't know where the old [root] Trustee came from. We've had so many Novell products (that got discontinued, etc.) who knows why it's there any longer.

Although in less than a year it'll be going away to all AD/MS stuff anyway (not my choice).

But these are good things to know.

Thank you very much for all your help!
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.