Re: (ITS#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com
Le 16/01/2014 16:42, Howard Chu a écrit :
> coudot(a)linagora.com wrote:
>>
>>
>> Le 16/01/2014 15:31, Howard Chu a écrit :
>>> coudot(a)linagora.com wrote:
>>>> Full_Name: Clement OUDOT
>>>> Version: 2.4.38
>>>> OS: GNU/Linux
>>>> URL: ftp://ftp.openldap.org/incoming/
>>>> Submission from: (NULL) (83.145.72.122)
>>>>
>>>>
>>>> Here is the situation : a user account is
>>>> 1/ expired (the password age is more that the one configured in
>>>> pwdMaxGae)
>>>> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy
>>>> configuration
>>>> object is TRUE)
>>>>
>>>> In this case, when doing a BIND, the result code is 0:
>>>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret
>>>> -e
>>>> ppolicy
>>>> ldap_bind: Success (0); Password must be changed (Password expires
>>>> in
>>>> 0
>>>> seconds)
>>>> dn: uid=coudot,ou=users,dc=example,dc=com
>>>>
>>>> If I remove pwdReset attribute, then:
>>>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret
>>>> -e
>>>> ppolicy
>>>> ldap_bind: Invalid Credentials (49); Password expired
>>>>
>>>> According to password policy draft, the password must change flag
>>>> should not
>>>> affect the BIND result code.
>>>
>>> The draft specifies the policy checks in the order in which they are
>>> to be performed. The PasswordMustBeChanged check occurs before the
>>> PasswordExpired check.
>>>
>>> The code works as designed.
>>
>>
>> Well, I understand. If this is not a bug in the OpenLDAP
>> implementation, it is maybe a point to discuss in the draft. Indeed,
>> a
>> simple LDAP client (that don't use ppolicy control) will get a
>> successful BIND response even if the password is expired.
>
> How can the password be expired if the admin has just reset it?
>
I never said it was *just* reset, we can imagine the password was reset
a year ago and that the user never changed it. What I point here is that
a reset password never expires, whatever you configure in pwdMaxAge.
People using the password reset feature must be aware of this, and be
sure to have an application that will force the user to change its
password.
>> Maybe it is the wanted behavior, maybe not.
>
>> The fact is that if an administator reset the password (by changing
>> password value and setting pwdReset to TRUE), this reseted password
>> will
>> never expire. From my point of view, this is a security flaw in the
>> password policy system, as a lot of applications just use the BIND
>> operation on LDAP server (searches and other operations are done by
>> application LDAP accounts).
>
> I agree that the MustChange feature doesn't mesh well with
> applications that simply perform a Bind and then do nothing else. Feel
> free to raise this point on the ldapext mailing list.
Yes I will give a try. You can close this ITS, thanks for the answers.
Clement.
9 years, 8 months
Re: (ITS#7787) Authentication success if password is expired and password must be changed
by hyc＠symas.com
coudot(a)linagora.com wrote:
>
>
> Le 16/01/2014 15:31, Howard Chu a écrit :
>> coudot(a)linagora.com wrote:
>>> Full_Name: Clement OUDOT
>>> Version: 2.4.38
>>> OS: GNU/Linux
>>> URL: ftp://ftp.openldap.org/incoming/
>>> Submission from: (NULL) (83.145.72.122)
>>>
>>>
>>> Here is the situation : a user account is
>>> 1/ expired (the password age is more that the one configured in
>>> pwdMaxGae)
>>> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy
>>> configuration
>>> object is TRUE)
>>>
>>> In this case, when doing a BIND, the result code is 0:
>>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e
>>> ppolicy
>>> ldap_bind: Success (0); Password must be changed (Password expires in
>>> 0
>>> seconds)
>>> dn: uid=coudot,ou=users,dc=example,dc=com
>>>
>>> If I remove pwdReset attribute, then:
>>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e
>>> ppolicy
>>> ldap_bind: Invalid Credentials (49); Password expired
>>>
>>> According to password policy draft, the password must change flag
>>> should not
>>> affect the BIND result code.
>>
>> The draft specifies the policy checks in the order in which they are
>> to be performed. The PasswordMustBeChanged check occurs before the
>> PasswordExpired check.
>>
>> The code works as designed.
>
>
> Well, I understand. If this is not a bug in the OpenLDAP
> implementation, it is maybe a point to discuss in the draft. Indeed, a
> simple LDAP client (that don't use ppolicy control) will get a
> successful BIND response even if the password is expired.
How can the password be expired if the admin has just reset it?
> Maybe it is the wanted behavior, maybe not.
> The fact is that if an administator reset the password (by changing
> password value and setting pwdReset to TRUE), this reseted password will
> never expire. From my point of view, this is a security flaw in the
> password policy system, as a lot of applications just use the BIND
> operation on LDAP server (searches and other operations are done by
> application LDAP accounts).
I agree that the MustChange feature doesn't mesh well with applications that
simply perform a Bind and then do nothing else. Feel free to raise this point
on the ldapext mailing list.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 8 months
Re: (ITS#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com
Le 16/01/2014 15:31, Howard Chu a écrit :
> coudot(a)linagora.com wrote:
>> Full_Name: Clement OUDOT
>> Version: 2.4.38
>> OS: GNU/Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (83.145.72.122)
>>
>>
>> Here is the situation : a user account is
>> 1/ expired (the password age is more that the one configured in
>> pwdMaxGae)
>> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy
>> configuration
>> object is TRUE)
>>
>> In this case, when doing a BIND, the result code is 0:
>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e
>> ppolicy
>> ldap_bind: Success (0); Password must be changed (Password expires in
>> 0
>> seconds)
>> dn: uid=coudot,ou=users,dc=example,dc=com
>>
>> If I remove pwdReset attribute, then:
>> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e
>> ppolicy
>> ldap_bind: Invalid Credentials (49); Password expired
>>
>> According to password policy draft, the password must change flag
>> should not
>> affect the BIND result code.
>
> The draft specifies the policy checks in the order in which they are
> to be performed. The PasswordMustBeChanged check occurs before the
> PasswordExpired check.
>
> The code works as designed.
Well, I understand. If this is not a bug in the OpenLDAP
implementation, it is maybe a point to discuss in the draft. Indeed, a
simple LDAP client (that don't use ppolicy control) will get a
successful BIND response even if the password is expired.
Maybe it is the wanted behavior, maybe not.
The fact is that if an administator reset the password (by changing
password value and setting pwdReset to TRUE), this reseted password will
never expire. From my point of view, this is a security flaw in the
password policy system, as a lot of applications just use the BIND
operation on LDAP server (searches and other operations are done by
application LDAP accounts).
Clément.
9 years, 8 months
Re: (ITS#7787) Authentication success if password is expired and password must be changed
by hyc＠symas.com
coudot(a)linagora.com wrote:
> Full_Name: Clement OUDOT
> Version: 2.4.38
> OS: GNU/Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (83.145.72.122)
>
>
> Here is the situation : a user account is
> 1/ expired (the password age is more that the one configured in pwdMaxGae)
> 2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy configuration
> object is TRUE)
>
> In this case, when doing a BIND, the result code is 0:
> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy
> ldap_bind: Success (0); Password must be changed (Password expires in 0
> seconds)
> dn: uid=coudot,ou=users,dc=example,dc=com
>
> If I remove pwdReset attribute, then:
> $ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy
> ldap_bind: Invalid Credentials (49); Password expired
>
> According to password policy draft, the password must change flag should not
> affect the BIND result code.
The draft specifies the policy checks in the order in which they are to be
performed. The PasswordMustBeChanged check occurs before the PasswordExpired
check.
The code works as designed.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 8 months
(ITS#7787) Authentication success if password is expired and password must be changed
by coudot＠linagora.com
Full_Name: Clement OUDOT
Version: 2.4.38
OS: GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.145.72.122)
Here is the situation : a user account is
1/ expired (the password age is more that the one configured in pwdMaxGae)
2/ must be reset (pwdReset is TRUE and pwdMustChange in ppolicy configuration
object is TRUE)
In this case, when doing a BIND, the result code is 0:
$ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy
ldap_bind: Success (0); Password must be changed (Password expires in 0
seconds)
dn: uid=coudot,ou=users,dc=example,dc=com
If I remove pwdReset attribute, then:
$ ldapwhoami -x -D uid=coudot,ou=users,dc=example,dc=com -w secret -e ppolicy
ldap_bind: Invalid Credentials (49); Password expired
According to password policy draft, the password must change flag should not
affect the BIND result code.
9 years, 8 months
Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by hyc＠symas.com
pierangelo.masarati(a)polimi.it wrote:
> On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote:
>> Full_Name: Raphael Ouazana
>> Version: 2.4.38
>> OS: Linux
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (88.173.78.196)
>>
>>
>> Hi,
>>
>> I have an old configuration that I would like to export/reimport. The
>> olcDbDirectory item of this configuration contains a directory that does not
>> longer exist.
>> It it then impossible to modify the parameter:
>> - I was told not to edit directly LDIF config files
>> - if i try a slapcat -n0 I get:
>> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory
>> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory:
>> value #0: invalid path: No such file or directory
>> slapcat: bad configuration directory!
>>
>> I think slapcat should always allow to export a configuration.
>
> I see the point; slapcat is failing because to export the configuration
> (c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first,
> and it reads the whole config tree.
>
> Perhaps when slapcat of only the config database is requested, config
> parsing should skip other databases, or at least ignore errors, if possible.
Agreed, we definitely need this.
>
> p.
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9 years, 8 months
Re: (ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by pierangelo.masarati＠polimi.it
On 01/15/2014 09:59 AM, raphael.ouazana(a)linagora.com wrote:
> Full_Name: Raphael Ouazana
> Version: 2.4.38
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (88.173.78.196)
>
>
> Hi,
>
> I have an old configuration that I would like to export/reimport. The
> olcDbDirectory item of this configuration contains a directory that does not
> longer exist.
> It it then impossible to modify the parameter:
> - I was told not to edit directly LDIF config files
> - if i try a slapcat -n0 I get:
> 52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory
> 52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory:
> value #0: invalid path: No such file or directory
> slapcat: bad configuration directory!
>
> I think slapcat should always allow to export a configuration.
I see the point; slapcat is failing because to export the configuration
(c->op == SLAP_CONFIG_EMIT) it needs to read the configuration first,
and it reads the whole config tree.
Perhaps when slapcat of only the config database is requested, config
parsing should skip other databases, or at least ignore errors, if possible.
p.
--
Pierangelo Masarati
Associate Professor
Dipartimento di Scienze e Tecnologie Aerospaziali
Politecnico di Milano
9 years, 8 months
(ITS#7786) Impossible to modify cn=config if olcDbDirectory doesn't exist
by raphael.ouazana＠linagora.com
Full_Name: Raphael Ouazana
Version: 2.4.38
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (88.173.78.196)
Hi,
I have an old configuration that I would like to export/reimport. The
olcDbDirectory item of this configuration contains a directory that does not
longer exist.
It it then impossible to modify the parameter:
- I was told not to edit directly LDIF config files
- if i try a slapcat -n0 I get:
52d64c91 olcDbDirectory: value #0: invalid path: No such file or directory
52d64c91 config error processing olcDatabase={2}hdb,cn=config: olcDbDirectory:
value #0: invalid path: No such file or directory
slapcat: bad configuration directory!
I think slapcat should always allow to export a configuration.
Regards,
Raphaël Ouazana.
9 years, 8 months
Re: (ITS#7785) ContextCSN not updated
by michael＠stroeder.com
badguy9588(a)hotmail.com wrote:
> Full_Name:
> Version: 2.4.11
> OS: Redhat Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (202.82.28.193)
>
>
> We are using 4 ways multimaster openldap 2.4.11 for more than 5 years.
>
> On Jan 3, 2014, one of the openldap contextCSN is not updated, always stay at
> Jan 3 01:xx:xx, all the other servers are already updated to Jan 6.
Any reason why you insist on using such an ancient release? In 5,5 years since
2.4.11 release there have been numerous important contextCSN related fixes to
OpenLDAP 2.4.x code.
You should definitely upgrade!
Everything else is wasting your own time and the OpenLDAP project people's
resources.
Ciao, Michael.
9 years, 8 months
