|
|
Date: Prev Next Date Index Thread: Prev Next Thread Index
Hi
Scott Russell clearly described how to use encrypted passwords in smtpd.conf using auxprop. But I still have troubles. My outgoing mail authentication does'n work since I'm using the encrypted passwords. Targeting a SQL Field with a clear text password works with the setup below. I create my passwords with the encrypt() function in Mysql: mysql> update users set crypt=encrypt('mypassword','salt') where email='test@xxxxxxxxxxxx'; My smtpd.conf looks like this: pwcheck_method: auxprop mysql_user: mail mysql_passwd: *** mysql_hostnames: 127.0.0.1 mysql_database: mail mysql_statement: select decode(crypt,'salt') from users where email = '%u@%r' mysql_verbose: yes Some lines from my mysql.log. The first row (check mail works perfect with the crypt field) the second part (the smtp chat) is resulting in an error. 021225 2:57:11 24 Query SELECT email, crypt, "", uid, gid, homedir, "", "", name FROM users WHERE email = "test@xxxxxxxxxxxx" 021225 2:57:39 105 Connect mail@localhost on 105 Init DB mail 105 Query select decode(crypt,'salt') from users where email = 'test@xxxxxxxxxxxx' 105 Quit 106 Connect mail@localhost on 106 Init DB mail 106 Quit Thank your for any help! --raffi
Thread at a glance:
Previous Message by Date:Re: sasldb/allockey.c - don't blindly use SASL_AUX_PASSWORD (Again)Fixed in CVS, thanks. -Rob On Tue, 24 Dec 2002, Michail Vidiassov wrote: > Dear All, > > the latest change (1.2 -> 1.3) in sasldb/allockey.c > fixed the function _sasldb_putsecret. > But _sasldb_getsecret is still broken in the same way (as of now, 2.1.10). > The leading '*' in SASL_AUX_PASSWORD is not skipped. > Let us fix it in the same way as _sasldb_putsecret was fixed. > The problem surfaces in saslpasswd2 ignoring -c option > (do not change existing passwords, create only), as > secret is never found due to broken _sasldb_getsecret. > Sincerely, Michail > PS. Sample patch. > --- sasldb/allockey.c.orig Fri Apr 26 21:31:47 2002 > +++ sasldb/allockey.c Tue Dec 10 16:32:41 2002 > @@ -146,13 +146,15 @@ > size_t len; > sasl_secret_t *out; > int ret; > + const char *param = SASL_AUX_PASSWORD; > + param++; /* skip leading * */ > > if(!secret) { > utils->seterror(context, 0, "No secret pointer in _sasldb_getsecret"); > return SASL_BADPARAM; > } > > - ret = _sasldb_getdata(utils, context, authid, realm, SASL_AUX_PASSWORD, > + ret = _sasldb_getdata(utils, context, authid, realm, param, > buf, 8192, &len); > > if(ret != SASL_OK) { > > > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper Next Message by Date:Re: 2.1.10 vs Heimdal 0.5--On Sunday, December 22, 2002 4:12 AM +0100 Ian Delahorne <ian@xxxxxxxx> wrote: Ian Delahorne <ian@xxxxxxxx> writes: This is sortof what happens: the configure script can't detect heimdal properly, and thinks it has MIT-krb5-GSSAPI. I found the solution here: http://www.openldap.org/lists/openldap-software/200210/msg00671.html At line 1039 in aclocal.m4, replace LDFLAGS="$LDFLAGS -L$gssapi/lib" with LDFLAGS="$LDFLAGS -ldb -lcrypto -L$gssapi/lib" Could this be patched in the main distribution? This modification as is isn't good---Heimdal doesn't always rely on libdb or libcrypto. If Heimdal is compiled as a shared library, it will pick up most dependencies automatically on most versions of Unix. If it's only compiled statically, it's a pain in the ass figuring out what it depends on. The easiest way for a user to workaround this is (I think) to do env LIBS="-ldb -lcrypto" ./configure ... To do this properly in configure we'd probably have to iterate through the possible libraries Heimdal might depend on. Since libdb is known by about 34523 different names this is challenging. Larry Previous Message by Thread:sasldb/allockey.c - don't blindly use SASL_AUX_PASSWORD (Again)Dear All, the latest change (1.2 -> 1.3) in sasldb/allockey.c fixed the function _sasldb_putsecret. But _sasldb_getsecret is still broken in the same way (as of now, 2.1.10). The leading '*' in SASL_AUX_PASSWORD is not skipped. Let us fix it in the same way as _sasldb_putsecret was fixed. The problem surfaces in saslpasswd2 ignoring -c option (do not change existing passwords, create only), as secret is never found due to broken _sasldb_getsecret. Sincerely, Michail PS. Sample patch. --- sasldb/allockey.c.orig Fri Apr 26 21:31:47 2002 +++ sasldb/allockey.c Tue Dec 10 16:32:41 2002 @@ -146,13 +146,15 @@ size_t len; sasl_secret_t *out; int ret; + const char *param = SASL_AUX_PASSWORD; + param++; /* skip leading * */ if(!secret) { utils->seterror(context, 0, "No secret pointer in _sasldb_getsecret"); return SASL_BADPARAM; } - ret = _sasldb_getdata(utils, context, authid, realm, SASL_AUX_PASSWORD, + ret = _sasldb_getdata(utils, context, authid, realm, param, buf, 8192, &len); if(ret != SASL_OK) { Next Message by Thread:Cyrus-sasl 2.1.10 error on Aix 4.3.3I want to compile this program on aix 4.3.3.10 and gcc-3.2.1 but make(aix make and gnumake too)process show me this error:.Configure process is correct without parameters.(./configure).makeplugin_common.c: In function `_plug_ipfromstring':plugin_common.c:146: `AI_NUMERICHOST' undeclared (first use in thisfunction)plugin_common.c:146: (Each undeclared identifier is reported only onceplugin_common.c:146: for each function it appears in.)make: 1254-004 code error last command is 1.stopped.make: 1254-004 code error last command is 1.stopped.make: 1254-004 code error last command is 2.AThanks.
|
|
