Description of problem: rsearch expects a rigid layout for tests which search and then bind. It expects to search on the uid, and then bind using the DN and the uid as a password. This, naturally, doesn't work if the entry does not have a uid, or if the password does not match it. Version-Release number of selected component (if applicable): 1.1.3 How reproducible: Always Steps to Reproduce: 1. Run rsearch using the -B and -x flags. Actual results: rsearch searches based on the uid attribute and uses it as the password to bind. Expected results: Ideally, this would be customizable. Additional info:
Created attachment 322913 [details] Propose patch This patch adds a -W flag for the user password and a -U flag for the filter to use. Their use is optional and the default values remain intact. Example usage would be: rsearch [options] -B bindfile -x -U "(myUserNameAttr=%s)" -W secret12 Omitting -U and –W would use “uid” and the uid value as is done currently. The patch also contains some unrelated minor adjustments: 1. It fixes the bind-only (noop) -N option. This had apparently atrophied over time and the threads would do exactly one loop and then exit. 2. It prints the current time out next to each "Rate" line. This helps when trying to correlate any messages to access/error log statements. 3. It gives the threads a better chance of passing different seed values to srand().
The proposed patch looks good. Thank you for your contribution! I will apply this to the current code and get it checked in if there are no merge conflicts.
Checked into ldapserver (HEAD). Thanks again for the contribution! Checking in ldap/servers/slapd/tools/rsearch/rsearch.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/tools/rsearch/rsearch.c,v <-- rsearch.c new revision: 1.6; previous revision: 1.5 done Checking in ldap/servers/slapd/tools/rsearch/rsearch.h; /cvs/dirsec/ldapserver/ldap/servers/slapd/tools/rsearch/rsearch.h,v <-- rsearch.h new revision: 1.5; previous revision: 1.4 done Checking in ldap/servers/slapd/tools/rsearch/searchthread.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/tools/rsearch/searchthread.c,v <-- searchthread.c new revision: 1.7; previous revision: 1.6 done
Could you please add the rsearch commands to verify this bug? Thanks
As Thomas stated in comment #2, the new usage is: rsearch [options] -B bindfile -x -U "(myUserNameAttr=%s)" -W secret12 You need to create a bindfile and use some attribute other than "uid" for "myUserNameAttr" to find the DN to bind as. Setup your entries with the password you use in the -W option. You should see rsearch bind successfully as the entries found using the filter in the -U option.
verified DS 8.1 - RHEL 4 user has no uid, bind file: UID: test 1 rsearch command: rsearch -h `hostname` -p 389 -D "cn=Directory Manager" -w Secret123 -s "dc=bos,dc=redhat,dc=com" -f "objectclass=person" -B bindfile -x -U '(cn=%s)' -W test [15/Apr/2009:12:50:26 -0400] conn=18 op=0 BIND dn="cn=Directory Manager" method=128 version=3 [15/Apr/2009:12:50:26 -0400] conn=18 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=directory manager" [15/Apr/2009:12:50:26 -0400] conn=18 op=1 SRCH base="dc=bos,dc=redhat,dc=com" scope=2 filter="(cn=test 1)" attrs=ALL [15/Apr/2009:12:50:26 -0400] conn=18 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [15/Apr/2009:12:50:26 -0400] conn=19 fd=67 slot=67 connection from 10.16.0.49 to 10.16.0.49 [15/Apr/2009:12:50:26 -0400] conn=19 op=0 BIND dn="cn=test 1,dc=bos,dc=redhat,dc=com" method=128 version=3 [15/Apr/2009:12:50:26 -0400] conn=19 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=test 1,dc=bos,dc=redhat,dc=com" [15/Apr/2009:12:50:26 -0400] conn=19 op=1 SRCH base="dc=bos,dc=redhat,dc=com" scope=2 filter="(objectClass=person)" attrs=ALL [15/Apr/2009:12:50:26 -0400] conn=19 op=1 RESULT err=0 tag=101 nentries=5 etime=0 [15/Apr/2009:12:50:26 -0400] conn=19 op=2 SRCH base="dc=bos,dc=redhat,dc=com" scope=2 filter="(objectClass=person)" attrs=ALL [15/Apr/2009:12:50:26 -0400] conn=19 op=2 RESULT err=0 tag=101 nentries=5 etime=0
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html