On 01/27/12 17:25 -0500, Randy Schultz wrote:

Howdy,

I'm confused as to why an operation with the -y filename works great, but the same operation with the -w pw dies with "ldap_bind: Invalid credentials (49)".

The first file I've attached is with the -y, it works. The second is with the -w. I did notice the difference where the working one had a "." at the end of the pw, which was not present when using the -w option. To make sure I was not entering a typo on the commandline pw, I wrote a quick script, just a

#!/bin/sh

P=`cat p2` echo "|$P|"

ldapsearch -v -d -1 -x -w "$P" -D cn=manager,dc=earlham,dc=edu -b ou=People,dc=earlham,dc=edu -h xaga

This also died with invalid credentials after printing out the pw.

Anybody have an idea what's going on?

-- Randy (schulra@earlham.edu) 765.983.1283 <*>

nosce te ipsum

ldapsearch -v -d -1 -x -y p2 -D cn=manager,dc=earlham,dc=edu -b ou=People,dc=earlham,dc=edu -h xaga ldap_initialize( ldap://xaga ) ldap_create ldap_url_parse_ext(ldap://xaga) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP xaga:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 159.28.1.98:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x80103f000 ptr=0x80103f000 end=0x80103f036 len=54 0000: 30 34 02 01 01 60 2f 02 01 03 04 1c 63 6e 3d 6d 04...`/.....cn=m 0010: 61 6e 61 67 65 72 2c 64 63 3d 65 61 72 6c 68 61 anager,dc=earlha 0020: 6d 2c 64 63 3d 65 64 75 80 0c 73 75 70 65 72 73 m,dc=edu..supers 0030: 65 63 52 45 54 0a ecret.

It appears your password file has a trailing newline character (0x0a).

ldapsearch -v -d -1 -x -w 'supersecret' -D cn=manager,dc=earlham,dc=edu -b ou=People,dc=earlham,dc=edu -h xaga ldap_initialize( ldap://xaga ) ldap_create ldap_url_parse_ext(ldap://xaga) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP xaga:389 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 159.28.1.98:389 ldap_pvt_connect: fd: 3 tm: -1 async: 0 ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x801040000 ptr=0x801040000 end=0x801040035 len=53 0000: 30 33 02 01 01 60 2e 02 01 03 04 1c 63 6e 3d 6d 03...`......cn=m 0010: 61 6e 61 67 65 72 2c 64 63 3d 65 61 72 6c 68 61 anager,dc=earlha 0020: 6d 2c 64 63 3d 65 64 75 80 0b 73 75 70 65 72 73 m,dc=edu..supers 0030: 65 63 52 45 54 ecret

Which is missing here.

On Jan 28, 2012, at 13.15, Randy Schultz wrote:

so there shouldn't have been a NL in the file, yet the 0a is there.

quite the contrary, actually.

while there may be nuances depending on which echo you're using [stand alone program for a given os or a given shell builtin], as a general rule, you need to supply -n to the command to prevent a newline from being appended. as far as reading it back after assigning the string to a variable, that is how many shells handle words and their adjacent whitespace, bash being a popular example:

echo 'string\n\n\n\n\n\n\n\n\n\n\n' > pwf

wc -l pwf

12 pwf

p=$(cat pwf); echo "|${p}|"

|string|

Just for grins tho', your thoughts got me thinking. I just ran an md5 on the file and compared it to just the string. Well lookee here, they're different. Run od on the file and !surprise - the NL shows up.

hashing the contents or printing octal representations are fine, but this can be demonstrated with just cat, on most systems:

echo 'string' > pwf; cat pwf

string

echo -n 'string' > pwf; cat pwf

string>

regards -b