[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
{ in cleartext passwords
- To: openldap-software@OpenLDAP.org
- Subject: { in cleartext passwords
- From: l0calh0st <127.0.0.1x@gmail.com>
- Date: Tue, 23 Aug 2005 17:19:19 -0500
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=T7z02Gdb9gY91ndLYyI1GHJsaWErkCsOnyDW8744YW1szFX4bBccFpVunv1aCJ396DR45UONNb6cXi9Nhuho8UKs3x8KgDxPctCyorNSEwOZafoypbQJd7wzZ2XDW44AsIfx4kBhTu/UL0ReteEjvA60w5bqK+HTvwfAh3uw+5E=
Hi:
Over the weekend, I upgraded our 4 server environment from ldbm-backend
2.0.23 on RedHat 7.1 to bdb-backend 2.2.23 on Debian Sarge. Things went
quite swimmingly, but I am noticing issues with some of our users that have
{ as the first character in their password. We store the passwords in
cleartext in the database, and my workaround has been to convert the
affected folks' passwords to {CRYPT} hashes, but I think it is only a
feasible temporary solution, as our password programming application will
eventually pick an incompatible password.
We have a homebrew application that generates 8 character passwords with
special characters and posts them to the master in cleartext, then slurpd
replicates them to the slaves. In the old environment, things were great,
but now users are not able to authenticate if their password contains a {...
my guess is because slapd wants to know what type of hash it is stored in.
The funny thing (ha ha) is that it worked fine in 2.0.23. I don't think
changing the app is much of an option in the short term, but I want to have
it tweaked soon.
If it matters, I slapcat'd out the 2.0.23 database, then grep/awk'd it to
modify the format quite a bit and then toss it into LDIF format, where it
was added via ldapadd.
Any help is appreciated!
-john