Re: SASL and non-cleartext passwords storage

On 18.09.2011 14:36, Jacobus brogly.decap wrote: No, encrypting passwords over the wire is somthing TOTALLY different and seperate from how they are stored on disk (in case you want to migrate or export) Dont solve 2 different problems at the same time,..I recommend you read chapter 2 of IB

Re: SASL and non-cleartext passwords storage

horization ? the ldapdb auxprop plugin in postfix doesn't work with hash passwords. Should I go back to using saslauthd ? 2011/9/18 Julien Vehent Hi List, I'm working on a setup where postfix and cyrus-imap do proxy authorization against openldap (my setup is here http://1nw.e

Re: cn=config and authz-regexp

On 11/30/2010 01:37 PM, Hallvard B Furuseth wrote: Julien Vehent writes: On my former installation, I have SASL configured using : (...) --- authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=domain,dc=net??sub?(uid=$1)" authz-policy to passwo

cn=config and authz-regexp

Hi list, I'm moving a LDAP directory on a freshly installed Debian Squeeze and I'm discovering cn=config. On my former installation, I have SASL configured using : --- authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" "ldap:///dc=domain,dc=net??sub?(uid=$1)" authz-policy to password

Re: invalid syntax on pwdPolicy object add

On Tue, 14 Sep 2010 10:51:01 +0200, Emmanuel Lecharny wrote: On 9/14/10 8:40 AM, mailing lists wrote: Hello, I think that the pwdAttribute needs an OID value (specified by the syntax) so you would must use the OID of the userPassword attribute which is 2.5.4.35 I thought that would be a

Re: invalid syntax on pwdPolicy object add

On Mon, 13 Sep 2010 19:29:12 +0530, Kiran Ayyagari wrote: > On Mon, Sep 13, 2010 at 5:07 PM, Julien Vehent wrote: >> >> >> >> # slapd -V >> @(#) $OpenLDAP: slapd 2.4.23 (Aug 26 2010 18:33:04) $ >>        r...@monster:/tmp/buildd/openldap-2.4.23/debian/

Re: invalid syntax on pwdPolicy object add

On Mon, 13 Sep 2010 13:12:15 +0200, Emmanuel Lecharny wrote: >> >> On Mon, 13 Sep 2010 11:34:56 +0200, Emmanuel Lecharny >> wrote: On Mon, 13 Sep 2010 10:52:03 +0200, Christian Manal wrote: > Hi, > > pwdPolicy is an auxiliary objectClass. You have to use it in conjunct

Re: invalid syntax on pwdPolicy object add

On Mon, 13 Sep 2010 11:34:56 +0200, Emmanuel Lecharny wrote: >> On Mon, 13 Sep 2010 10:52:03 +0200, Christian >> Manal wrote: >>> Hi, >>> >>> pwdPolicy is an auxiliary objectClass. You have to use it in conjunction >>> with a structural objectClass. Look at the example from the admin guide: >

Re: invalid syntax on pwdPolicy object add

On Mon, 13 Sep 2010 10:52:03 +0200, Christian Manal wrote: > > Hi, > > pwdPolicy is an auxiliary objectClass. You have to use it in conjunction > with a structural objectClass. Look at the example from the admin guide: > >

invalid syntax on pwdPolicy object add

Hello all, I'm trying to add a default password policy to my directory. I have set the following parameters in slapd.conf: include /etc/ldap/schema/ppolicy.schema [...] moduleload ppolicy [...] backend hdb databasehdb suffix "dc=example,dc=net" [...] #

Re: Proxy authorization fail with cyrus-sasl and postfix

On Mon, 24 May 2010 15:37:48 +0200 (CEST), masar...@aero.polimi.it wrote: > > > Just change your authz-regexp line to > > authz-regexp "^uid=([^,]+).*,cn=[^,]*,cn=auth$" > "ldap:///dc=linuxwall,dc=info??sub?(|(uid=$1)(mail=$1))" > > > p. YES ! I WORKS ! I couldn't be more grate

Re: Proxy authorization fail with cyrus-sasl and postfix

On Sun, 23 May 2010 18:35:21 +0200 (CEST), masar...@aero.polimi.it wrote: > Can you check what exact operation is being attempted? I mean: what > identity "cn=postfix administrator,ou=infrastructure,dc=linuxwall,dc=info" > is trying to authorize as during conn=109 op=2? You should try to > reprod

Proxy authorization fail with cyrus-sasl and postfix

julien SASL SSF: 128 SASL data security layer installed. dn:cn=julien vehent,ou=people,dc=linuxwall,dc=info Thus, I set up the ldapdb driver from the sasl library in the chroot of postfix. I see connections from postfix to slapd, postfix user is properly authenticated, but then I have the fo