Re: ldap user login attempt kills slapd service

[Matus Honek]

I must have missed the e-mail below from you, sorry for that. The link
to the archives is http://www.openldap.org/lists/openldap-technical/.

The related Red Hat Bugzilla is
https://bugzilla.redhat.com/show_bug.cgi?id=1335194

>From the backtraces provided by Liz in the case it seems to be
technically (except for presence of back_relay) the same as ITS#7384. So
it does not seem to be MozNSS-related. I will let Liz to include
additional backtraces (etc.) if asked for it.

"Real, Elizabeth (392K)"  writes:

> I reported the bug to red hat.
>
> What is the openldap technical URL where all of the submitted requests are 
> listed on?
>
> Thank you,
> Liz
>
>

-- 
Matúš Honěk
Associate Software Engineer @ Red Hat, Inc.

Re: Checking that account is locked

[Radovan Semancik]

On 06/16/2016 11:45 AM, Michael Ströder wrote:

The caveat with reading cn=config is that you might not be allowed doing so. One
would need fine-grained read ACLs to avoid e.g. revealing the rootpw hash to an
application. Well, on my systems there is no rootpw hash but you get the idea.


Yes. That's exactly my concern. I do not like the idea of letting 
ordinary LDAP clients access cn=config at all.

So, it looks like there is currently no good solution for this.


AFAIK other LDAP servers (e.g. OpenDJ) has two operational attributes:

1. 'pwdPolicySubentry' is set in every entry and therefore always points to the
effective (default) pwdPolicy entry.

2. Another attribute (IIRC 'ds-pwp-password-policy-dn') is for setting an
individual pwdPolicy entry to be used for a particular entry overriding the
default value.

I'd love to see something like this standardized and implemented in OpenLDAP.


I completely agree with that.

--
Radovan Semancik
Software Architect
evolveum.com

Re: Checking that account is locked

[Michael Ströder]

Radovan Semancik wrote:
> I'm glad that you confirmed that. I was afraid that I'm overlooking something
> essential here.
> 
> On 06/15/2016 10:14 PM, Clément OUDOT wrote:
>> Well, if there is a default ppolicy configured, and yes you need to search it
>> in cn=config, but it can also be a configuration parameter on your side. If
>> there is not, the policy will be defined in pwdPolicySubentry, so you can
>> directly request it.
> 
> Yes, theoretically I can have configuration parameter on my side. But
> practically that is asking for trouble during operation and maintenance. If 
> the
> pointer to default password policy in OpenLDAP changes I'm quite sure nobody
> will think about updating the configuration of my application.

The caveat with reading cn=config is that you might not be allowed doing so. One
would need fine-grained read ACLs to avoid e.g. revealing the rootpw hash to an
application. Well, on my systems there is no rootpw hash but you get the idea.

AFAIK other LDAP servers (e.g. OpenDJ) has two operational attributes:

1. 'pwdPolicySubentry' is set in every entry and therefore always points to the
effective (default) pwdPolicy entry.

2. Another attribute (IIRC 'ds-pwp-password-policy-dn') is for setting an
individual pwdPolicy entry to be used for a particular entry overriding the
default value.

I'd love to see something like this standardized and implemented in OpenLDAP.

Ciao, Michael.



smime.p7s
Description: S/MIME Cryptographic Signature

Re: Odd MMR behaviour with delta-syncrepl and refreshAndPersist

[Mark Cairney]

Hi Quanah,

Apologies for taking it off-list. I didn't want to clutter the list
archive with reams of my logging output which probably isn't meaningful
to anyone else.

I'll fill in an ITS as suggested.
Thanks for your help with this.

Kind regards,

Mark


On 15/06/16 20:41, Quanah Gibson-Mount wrote:
> --On Wednesday, June 15, 2016 1:59 PM +0100 Mark Cairney
>  wrote:
> 
>> Hi Quanah,
>>
>> I can confirm I still see the issue when deleting and adding user
>> objects and groups using 3-way delta-MMR.
> 
> Please keep replies on the list.
> 
>> From one of the servers receiving the change:
>>
> 
> [snip]
> 
>> I spotted the reference to "cn=marksgroup2" in the log above so decided
>> to try it with an objectclass that has no group memberships managed by
>> the memberOf overlay (simplesecurityobject) and it worked as expected:
>>
>> Again from the consumer I see the following logged:
> 
> [snip]
> 
>> So it looks like there's possibly an additional effect being caused by
>> the memberOf overlay but as about 90% of our LDAP writes are the
>> creation/modification/deletion of users and groups this could be a pain
>> on a production system :-)
>>
>> Is this enough for you to go on? If there's any additional logging or
>> details of my config I'm happy to pass them on.
> 
> I dropped your replication log bits in case there was anything sensitive
> in there.
> 
> I agree, it looks like the memberof overlay is breaking replication in
> your case.  I would suggest filing an ITS with details on your setup,
> and the logging you provided, obfuscated as necessary.
> 
> --Quanah
> 
> 
> 
> -- 
> 
> Quanah Gibson-Mount
> Platform Architect
> Manager, Systems Team
> Zimbra, Inc.
> 
> Zimbra ::  the leader in open source messaging and collaboration
> A division of Synacor, Inc
> 

-- 
/

Mark Cairney
ITI Enterprise Services
Information Services
University of Edinburgh

Tel: 0131 650 6565
Email: mark.cair...@ed.ac.uk
PGP: 0x435A9621

***/

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.



signature.asc
Description: OpenPGP digital signature

Re: Checking that account is locked

[Clément OUDOT]

Le 16/06/2016 10:36, Radovan Semancik a écrit :

Thanks Clement,

I'm glad that you confirmed that. I was afraid that I'm overlooking 
something essential here.


On 06/15/2016 10:14 PM, Clément OUDOT wrote:
Well, if there is a default ppolicy configured, and yes you need to 
search it in cn=config, but it can also be a configuration parameter 
on your side. If there is not, the policy will be defined in 
pwdPolicySubentry, so you can directly request it.


Yes, theoretically I can have configuration parameter on my side. But 
practically that is asking for trouble during operation and 
maintenance. If the pointer to default password policy in OpenLDAP 
changes I'm quite sure nobody will think about updating the 
configuration of my application.


You also need to take into account the value 0101Z in 
pwdAccountLockedTime which means the password is locked forever.


Sure. I have seen that in the docs.

But we clearly lack of some operations that would allow to know the 
state of an account. This could be an interesting discussion if we 
work on a new ppolicy draft.


Well, that's a bit more complex. It is not just an operation to check 
the status. But there are also usecases to search such accounts. E.g. 
statistics how many accounts are locked, look for locked accounts if 
an password attack is suspected, etc.





Maybe a solution can be to rely on the pwdAccountLockedTime attribute 
presence and create a cronjob that will remove this attribute if the 
pwdLockoutDuration is over. Not very clean but seems a quick fix.




--
Clément OUDOT
Consultant en logiciels libres, Expert infrastructure et sécurité
Savoir-faire Linux
87, rue de Turbigo - 75003 PARIS
Blog: http://sflx.ca/coudot

Re: Checking that account is locked

[Radovan Semancik]

Thanks Clement,

I'm glad that you confirmed that. I was afraid that I'm overlooking 
something essential here.


On 06/15/2016 10:14 PM, Clément OUDOT wrote:
Well, if there is a default ppolicy configured, and yes you need to 
search it in cn=config, but it can also be a configuration parameter 
on your side. If there is not, the policy will be defined in 
pwdPolicySubentry, so you can directly request it.


Yes, theoretically I can have configuration parameter on my side. But 
practically that is asking for trouble during operation and maintenance. 
If the pointer to default password policy in OpenLDAP changes I'm quite 
sure nobody will think about updating the configuration of my application.


You also need to take into account the value 0101Z in 
pwdAccountLockedTime which means the password is locked forever.


Sure. I have seen that in the docs.

But we clearly lack of some operations that would allow to know the 
state of an account. This could be an interesting discussion if we 
work on a new ppolicy draft.


Well, that's a bit more complex. It is not just an operation to check 
the status. But there are also usecases to search such accounts. E.g. 
statistics how many accounts are locked, look for locked accounts if an 
password attack is suspected, etc.


--
Radovan Semancik
Software Architect
evolveum.com