5:25 p.m.
Our security group is hassling us because we don't currently provide them an
audit log of failed login attempts on our LDAP servers. For most of our
other systems, we simply provide them a syslog feed with this information.
However, openldap doesn't appear to have a logging level that provides
detail about login attempts on a single line, but rather across many lines
that would need to be correlated. It seems more like connection debugging
logging as opposed to authentication logging.
It looks like we might need to set up an accesslog overlay to log all of the
attempted binds and then have a separate process that runs through that and
generates the syslog feed to our ISO group's central logging server? That's
a bit more overhead than I would like.
Are there any other simpler ways of generating failed login logs?
Thanks much.
5:53 p.m.
--On Tuesday, September 17, 2013 5:25 PM -0700 "Paul B. Henson"
<henson(a)acm.org> wrote:
Our security group is hassling us because we don't currently
provide them
an audit log of failed login attempts on our LDAP servers. For most of our
other systems, we simply provide them a syslog feed with this information.
However, openldap doesn't appear to have a logging level that provides
detail about login attempts on a single line, but rather across many lines
that would need to be correlated. It seems more like connection debugging
logging as opposed to authentication logging.
It looks like we might need to set up an accesslog overlay to log all of
the attempted binds and then have a separate process that runs through
that and generates the syslog feed to our ISO group's central logging
server? That's a bit more overhead than I would like.
Are there any other simpler ways of generating failed login logs?
slapo-auditlog?
slapo-accesslog?
Don't know if you use it, but your security team may like you to use
ppolicy:
<http://www.openldap.org/software/man.cgi?query=slapo-ppolicy&apropos=...
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
10:02 a.m.
Caveat with using ppolicy to sync pwdfailures, etc:
I've failed in my attempts to get both of the following to work at same time:
1) passwords are actually checked (vs anything submitted for password will work)
2) and getting ppolicy pwdfailures to replicate from slaves to the master
Obviously #1 trumps #2.
Perhaps I did something wrong (along with follow up users), but no-one offered any
suggestions or pointers, or things are better now.
Just make sure you test bad passwords before you assume 'authentication is
working'.
Caveat Emptor.
- chris
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org
[mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Quanah Gibson-Mount
Sent: Tuesday, September 17, 2013 5:53 PM
To: Paul B. Henson; openldap-technical(a)openldap.org
Subject: Re: auditing failed login attempts
--On Tuesday, September 17, 2013 5:25 PM -0700 "Paul B. Henson"
<henson(a)acm.org> wrote:
Our security group is hassling us because we don't currently
provide
them an audit log of failed login attempts on our LDAP servers. For
most of our other systems, we simply provide them a syslog feed with this information.
However, openldap doesn't appear to have a logging level that provides
detail about login attempts on a single line, but rather across many
lines that would need to be correlated. It seems more like connection
debugging logging as opposed to authentication logging.
It looks like we might need to set up an accesslog overlay to log all
of the attempted binds and then have a separate process that runs
through that and generates the syslog feed to our ISO group's central
logging server? That's a bit more overhead than I would like.
Are there any other simpler ways of generating failed login logs?
slapo-auditlog?
slapo-accesslog?
Don't know if you use it, but your security team may like you to use
ppolicy:
<http://www.openldap.org/software/man.cgi?query=slapo-ppolicy&apropos=...
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
This message is private and confidential. If you have received it in error, please notify
the sender and remove it from your system.
10:47 a.m.
Regarding #2, you do have ppolicy_forward_updates enabled in your
configuration, correct?
-Michael Proto
On Wed, Sep 18, 2013 at 1:02 PM, Chris Jacobs <Chris.Jacobs(a)apollogrp.edu>wrote:
Caveat with using ppolicy to sync pwdfailures, etc:
I've failed in my attempts to get both of the following to work at same
time:
1) passwords are actually checked (vs anything submitted for password will
work)
2) and getting ppolicy pwdfailures to replicate from slaves to the master
Obviously #1 trumps #2.
Perhaps I did something wrong (along with follow up users), but no-one
offered any suggestions or pointers, or things are better now.
Just make sure you test bad passwords before you assume 'authentication is
working'.
Caveat Emptor.
- chris
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org [mailto:
openldap-technical-bounces(a)OpenLDAP.org] On Behalf Of Quanah Gibson-Mount
Sent: Tuesday, September 17, 2013 5:53 PM
To: Paul B. Henson; openldap-technical(a)openldap.org
Subject: Re: auditing failed login attempts
--On Tuesday, September 17, 2013 5:25 PM -0700 "Paul B. Henson"
<henson(a)acm.org> wrote:
> Our security group is hassling us because we don't currently provide
> them an audit log of failed login attempts on our LDAP servers. For
> most of our other systems, we simply provide them a syslog feed with
this information.
> However, openldap doesn't appear to have a logging level that provides
> detail about login attempts on a single line, but rather across many
> lines that would need to be correlated. It seems more like connection
> debugging logging as opposed to authentication logging.
>
> It looks like we might need to set up an accesslog overlay to log all
> of the attempted binds and then have a separate process that runs
> through that and generates the syslog feed to our ISO group's central
> logging server? That's a bit more overhead than I would like.
>
> Are there any other simpler ways of generating failed login logs?
slapo-auditlog?
slapo-accesslog?
Don't know if you use it, but your security team may like you to use
ppolicy:
<
http://www.openldap.org/software/man.cgi?query=slapo-ppolicy&apropos=...
>
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
This message is private and confidential. If you have received it in
error, please notify the sender and remove it from your system.
11:03 a.m.
Did; didn't work without other options which then resulted in the defeat of the
purpose of passwords.
See: http://www.openldap.org/lists/openldap-technical/201005/msg00001.html
The configs in that message (from May 2010) weren't the only configs I tried, but it
seemed the most correct as a starting point when seeking a hand.
- chris
From: openldap-technical-bounces(a)OpenLDAP.org
[mailto:openldap-technical-bounces@OpenLDAP.org] On Behalf Of Michael Proto
Sent: Wednesday, September 18, 2013 10:48 AM
To: Chris Jacobs
Cc: openldap-technical(a)openldap.org
Subject: Re: auditing failed login attempts
Regarding #2, you do have ppolicy_forward_updates enabled in your configuration, correct?
-Michael Proto
On Wed, Sep 18, 2013 at 1:02 PM, Chris Jacobs
<Chris.Jacobs@apollogrp.edu<mailto:Chris.Jacobs@apollogrp.edu>> wrote:
Caveat with using ppolicy to sync pwdfailures, etc:
I've failed in my attempts to get both of the following to work at same time:
1) passwords are actually checked (vs anything submitted for password will work)
2) and getting ppolicy pwdfailures to replicate from slaves to the master
Obviously #1 trumps #2.
Perhaps I did something wrong (along with follow up users), but no-one offered any
suggestions or pointers, or things are better now.
Just make sure you test bad passwords before you assume 'authentication is
working'.
Caveat Emptor.
- chris
-----Original Message-----
From: openldap-technical-bounces(a)OpenLDAP.org
[mailto:openldap-technical-bounces@OpenLDAP.org<mailto:openldap-technical-bounces@OpenLDAP.org>]
On Behalf Of Quanah Gibson-Mount
Sent: Tuesday, September 17, 2013 5:53 PM
To: Paul B. Henson;
openldap-technical@openldap.org<mailto:openldap-technical@openldap.org>
Subject: Re: auditing failed login attempts
--On Tuesday, September 17, 2013 5:25 PM -0700 "Paul B. Henson"
<henson@acm.org<mailto:henson@acm.org>> wrote:
Our security group is hassling us because we don't currently
provide
them an audit log of failed login attempts on our LDAP servers. For
most of our other systems, we simply provide them a syslog feed with this information.
However, openldap doesn't appear to have a logging level that provides
detail about login attempts on a single line, but rather across many
lines that would need to be correlated. It seems more like connection
debugging logging as opposed to authentication logging.
It looks like we might need to set up an accesslog overlay to log all
of the attempted binds and then have a separate process that runs
through that and generates the syslog feed to our ISO group's central
logging server? That's a bit more overhead than I would like.
Are there any other simpler ways of generating failed login logs?
slapo-auditlog?
slapo-accesslog?
Don't know if you use it, but your security team may like you to use
ppolicy:
<http://www.openldap.org/software/man.cgi?query=slapo-ppolicy&apropos=...
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
This message is private and confidential. If you have received it in error, please notify
the sender and remove it from your system.
________________________________
This message is private and confidential. If you have received it in error, please notify
the sender and remove it from your system.
12:20 p.m.
--On Wednesday, September 18, 2013 11:03 AM -0700 Chris Jacobs
<Chris.Jacobs(a)apollogrp.edu> wrote:
http://www.openldap.org/lists/openldap-technical/201005/msg00001.html
The configs in that message (from May 2010) weren't the only configs I
tried, but it seemed the most correct as a starting point when seeking a
hand.
3 years ago?
There have been quite a few fixes to ppolicy since then.
--Quanah
--
Quanah Gibson-Mount
Lead Engineer
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
11:19 a.m.
From: Quanah Gibson-Mount [mailto:quanah@zimbra.com]
slapo-auditlog?
From the documentation, it looks like that only logs changes, not
accesses/binds?
slapo-accesslog?
That is one of the options I mentioned in my initial inquiry, it's just
going to induce a bit more overhead than I would like as far as getting our
security group the plaintext log records they want. It would be nice if one
of the syslog options simply included authentication logging that included
everything (username, source IP, success/failure) on one line. Also, can you
have more than one accesslog overlay for a given database? We're currently
using regular syncrepl, but plan to transition to delta syncrepl, which also
requires an accesslog overlay.
Don't know if you use it, but your security team may like you to
use
policy
We don't currently, we are actually using a central identity management
system for account/password expiration and history; however, our security
group is pushing us to enable failed login lockout, so we will most likely
be looking into it soon.
Thanks much.
2:42 p.m.
From: Michael Ströder [mailto:michael@stroeder.com]
Paul B. Henson wrote:
> our security group is pushing us to enable failed login lockout
..which will stupidly open a DoS attack vector...
Preaching to the choir on that one, my friend. I already promised our ISO
that the day we turn it on there are going to start to be random
authentication failures on his account originating from untraceable web
proxies around the world to the point where he'll never be able to actually
login ;). I just work here
3725
days inactive
3725
days old
openldap-technical@openldap.org
8 comments
5 participants
participants (5)
-
Chris Jacobs -
Michael Proto -
Michael Ströder -
Paul B. Henson -
Quanah Gibson-Mount