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
--On Friday, January 27, 2012 5:25 PM -0500 Randy Schultz schulra@earlham.edu wrote:
Anybody have an idea what's going on?
Nope. -w works great for me:
zimbra@zre-ldap001:~$ zmlocalconfig -s ldap_root_password ldap_root_password = zimbra zimbra@zre-ldap001:~$ ldapsearch -x -H ldap://zre-ldap004 -LLL -s base -b "" -D "cn=config" -w zimbra ldap_bind: Invalid credentials (49) zimbra@zre-ldap001:~$ ldapsearch -x -H ldap://zre-ldap001.eng.vmware.com -LLL -s base -b "" -D "cn=config" -w zimbra dn: objectClass: top objectClass: OpenLDAProotDSE
zimbra@zre-ldap001:~$ ldapsearch -x -H ldap://zre-ldap001.eng.vmware.com -LLL -s base -b "" -D "cn=config" -w 'zimbra' dn: objectClass: top objectClass: OpenLDAProotDSE
zimbra@zre-ldap001:~$ ldapsearch -x -H ldap://zre-ldap001.eng.vmware.com -LLL -s base -b "" -D "cn=config" -w `zmlocalconfig -m nokey -s ldap_root_password` dn: objectClass: top objectClass: OpenLDAProotDSE
--Quanah
--
Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration
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 Fri, 27 Jan 2012, Dan White spaketh thusly:
-}On 01/27/12 17:25 -0500, Randy Schultz wrote: -}> 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). -} (snip,crinkle,drop) -}> 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.
Hrm. I forgot to mention that not only was the pw file created with echo "string">pwf, but the script that pulls in the pw file and echos it, and no NL was shown. IOW, when run the
P=`cat p2` echo "|$P|"
would show
|supersecret|
so there shouldn't have been a NL in the file, yet the 0a is there. 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.
Tnx for jolt, Dan. I never thought to closely cmp the 2. It's "feeling much better now". ;>
-- Randy (schulra@earlham.edu) 765.983.1283 <*>
nosce te ipsum
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
openldap-technical@openldap.org
-
ben thielsen -
Dan White -
Quanah Gibson-Mount -
Randy Schultz