Highlighted
Absent Member.
Absent Member.
931 views

ldapsearch query


Hi,

This is in regards of a concern while running ldapsearch query on an
eDirectory server using Putty console:

- when ldapsearch is used to search for a user object , we are not
getting desired result. Instead when search is done for same user
through which authentication is made or authenticating with admin ID, it
provides the required result.

#ldapsearch -D "cn=admUser1.Test1,ou=Users,o=RBAC" -W -p 389 -h
10.236.10.117 -b "o=RBAC" -s sub "cn=admUser2.Test2"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <o=RBAC> with scope subtree
# filter: cn=admUser2.Test2
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

- Is RBS 'Role Based Service' mandatory to be configured on the
eDirectory server for ldapsearch query to work?
- Is there any alternate available?

Thanks in advance!


--
neha_gupta
------------------------------------------------------------------------
neha_gupta's Profile: https://forums.netiq.com/member.php?userid=1249
View this thread: https://forums.netiq.com/showthread.php?t=55886

Labels (1)
0 Likes
10 Replies
Highlighted
Knowledge Partner
Knowledge Partner

Re: ldapsearch query

On 05/17/2016 06:34 AM, neha gupta wrote:
>
> Hi,
>
> This is in regards of a concern while running ldapsearch query on an
> eDirectory server using Putty console:
>
> - when ldapsearch is used to search for a user object , we are not
> getting desired result. Instead when search is done for same user
> through which authentication is made or authenticating with admin ID, it
> provides the required result.


Which example are you showing below? I see nothing returned, so I assume
the bad example, but nothing looks terribly wrong here, so where is the
good result for comparison?

> #ldapsearch -D "cn=admUser1.Test1,ou=Users,o=RBAC" -W -p 389 -h
> 10.236.10.117 -b "o=RBAC" -s sub "cn=admUser2.Test2"
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <o=RBAC> with scope subtree
> # filter: cn=admUser2.Test2
> # requesting: ALL
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1


Yes, no objects found, but no errors so presumably it worked properly per
the conditions you specified.

> - Is RBS 'Role Based Service' mandatory to be configured on the
> eDirectory server for ldapsearch query to work?


No, RBS is all about iManager. It can, and usually does, impact users'
rights directly which would impact ldapsearch's (or any other queries via
any other LDAP or NCP tool's) results, but that there is no direct
relationship. RBS is all about eDirectory, and ldapsearch is a tool that
can query eDirectory.

> - Is there any alternate available?


What are you doing, specifically, in detail, that works? As shown, I
would guess that your admuser1.test user does not have rights to query for
admUser2.Test by its CN. Perhaps ensure it has rights, or show another
example that works so we can see what is different and then point that
out. If this works with a tree admin, it's a rights issue that you'll
need to resolve by giving this user rights to do the query, see the
object, etc.

--
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
Highlighted
Absent Member.
Absent Member.

Re: ldapsearch query


Thanks for your suggestion.

Can you help me with the minimum rights that need to be assigned to user
to enable ldapsearch ?


--
neha_gupta
------------------------------------------------------------------------
neha_gupta's Profile: https://forums.netiq.com/member.php?userid=1249
View this thread: https://forums.netiq.com/showthread.php?t=55886

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: ldapsearch query

On 05/17/2016 07:17 AM, neha gupta wrote:
>
> Thanks for your suggestion.
>
> Can you help me with the minimum rights that need to be assigned to user
> to enable ldapsearch ?


In general you do not need any special rights to use ldapsearch. To do
your specific search you need to have the ability to read CN attributes
for objects you want to find, and to have Browse to [Entry Rights] to
those objects so that you can find them to read their CNs.

By default, the latter should be in place. Getting rights to CN is
trivial, but as a quick test perhaps change your query to uid= instead of
cn= since the UID attribute, when creating objects using standard tools,
has the same value as the CN (again, in most cases), and is also marked
[Public Read] in schema by default, so it likely works unless you have
modified permissions somewhere.

If you want to grant rights in your tree you can do that most-easily via
iManager. Section 1.9 of the eDirectory Administration Guide has good
information you should probably know:

https://www.netiq.com/documentation/edir88/edir88/data/fbachifb.html

--
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
Highlighted
Knowledge Partner
Knowledge Partner

Re: ldapsearch query

The eDir rights needed is the same for LDAP as for eDir.

So to see an object you need browse, to read an attribute value you need read for that attribute.

Begin with assigning the user Object right Browse and all attribute rights Read and you should get a result. You can fine grain the rights after that if needed.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: ldapsearch query


Thanks for the response!
By trying the suggestion of using 'uid' instead of 'CN', I am seeing
difference in result when authenticating using "admin" & "User1". what
are the specific rights needs to be assigned to User1 for reading all
attributes of any search object?

Current Effective Rights for User1 are:
[All Attribute Rights] -> Compare & Read
[Entry Rights] -> Browse

** LdapSearch using User1
ldapsearch -D "cn=admUser1.Test1,ou=Privileged
Accounts,ou=xxx,ou=Users,o=RBAC" -W -p 389 -h 10.236.10.117 -b "o=RBAC"
-s sub "uid=admUser2.Test2"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <o=RBAC> with scope subtree
# filter: uid=admUser2.Test2
# requesting: ALL
#

# admUser2.Test2, Privileged Accounts, xxx, Users, RBAC
dn: cn=admUser2.Test2,ou=Privileged Accounts,ou=xxx,ou=Users,o=RBAC
mail: User2.Test2@xxx.com
uid: admUser2.Test2
givenName: User2
sn: Test2
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top
objectClass: CPunixUser
objectClass: posixAccount

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

** Ldapsearch using admin
ldapsearch -D "cn=admin,ou=sa,o=system" -W -p 389 -h xx.xx.xx.xxx -b
"o=RBAC" -s sub "uid=admUser2.Test2"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <o=RBAC> with scope subtree
# filter: uid=admUser2.Test2
# requesting: ALL
#

# admUser2.Test2, Privileged Accounts, xxx, Users, RBAC
dn: cn=admUser2.Test2,ou=Privileged Accounts,ou=xxx,ou=Users,o=RBAC
loginShell: /bin/bash
homeDirectory: /home/admUser2.Test2
gidNumber: 9999
uidNumber: 3757
workforceID: WFID10001671
mail: User2.Test2@xxx.com
uid: admUser2.Test2
givenName: User2
fullName: User2 Test2
title: xxx
sn: Test2
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: Person
objectClass: ndsLoginProperties
objectClass: Top
objectClass: CPunixUser
objectClass: posixAccount
loginTime: 20160510182408Z
loginDisabled: FALSE
description: 5853598
cn: admUser2.Test2
ACL: 2#subtree#cn=admUser2.Test2,ou=Privileged
Accounts,ou=xxx,ou=Users,o=
RBAC#[All Attributes Rights]
ACL: 6#entry#cn=admUser2.Test2,ou=Privileged
Accounts,ou=xxx,ou=Users,o=RB
AC#loginScript
ACL: 2#entry#[Public]#messageServer
ACL: 2#entry#[Root]#groupMembership
ACL: 6#entry#cn=admUser2.Test2,ou=Privileged
Accounts,ou=xxx,ou=Users,o=RB
AC#printJobConfiguration
ACL: 2#entry#[Root]#networkAddress

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1


--
neha_gupta
------------------------------------------------------------------------
neha_gupta's Profile: https://forums.netiq.com/member.php?userid=1249
View this thread: https://forums.netiq.com/showthread.php?t=55886

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: ldapsearch query

Current Effective Rights for User1 are:
[All Attribute Rights] -> Compare & Read
[Entry Rights] -> Browse


Effective rights on what object?

If you want User1 to be able to read User2 you need to assign Read for User1 to User2 or to a parent container if we assume there is no rights filter blocking the rights.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: ldapsearch query


As per the suggestion you mean:

User1 -> Modify Trustees -> Trustee Name (Root Container or User2) ->
Assigned Rights Link -> [All Attribute Rights] -> READ Check box

Please let me know if something wrong here to assign READ rights ?


--
neha_gupta
------------------------------------------------------------------------
neha_gupta's Profile: https://forums.netiq.com/member.php?userid=1249
View this thread: https://forums.netiq.com/showthread.php?t=55886

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: ldapsearch query

On 05/18/2016 07:54 AM, neha gupta wrote:
>
> As per the suggestion you mean:
>
> User1 -> Modify Trustees -> Trustee Name (Root Container or User2) ->
> Assigned Rights Link -> [All Attribute Rights] -> READ Check box


Yes, that should do it. Keep in mind you're granting the ability to
read/compare ALL attributes, which is kind of extreme. For your
particular original query, all you need is to read/compare CN. To
actually see all attributes when the object is returned, you may want [All
Attributes Rights], but even then that is probably excessive since you may
not need ALL attributes' values to be shown.

--
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
Highlighted
Absent Member.
Absent Member.

Re: ldapsearch query


Thanks for confirmation... But,
after making mentioned change I am seeing difference in the output when
authenticating using 'User1' or 'admin' - The LDAPSEARCH output I posted
above.

The expected result is not restricted to CN but all attributes.


--
neha_gupta
------------------------------------------------------------------------
neha_gupta's Profile: https://forums.netiq.com/member.php?userid=1249
View this thread: https://forums.netiq.com/showthread.php?t=55886

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: ldapsearch query

Just to rule out one thing.
Could you rename the user cn=admUser1.Test1 to cn=admUser1 and try or you could try and escape the . with \. such as "cn=admUser1\.Test1,ou=Privileged
Accounts,ou=xxx,ou=Users,o=RBAC"

I'm not sure this will do anything since I'm not used to having dots in names.
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.