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.
--On Tuesday, September 17, 2013 5:25 PM -0700 "Paul B. Henson" 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=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html
--Quanah
--
Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration
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@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 Subject: Re: auditing failed login attempts
--On Tuesday, September 17, 2013 5:25 PM -0700 "Paul B. Henson" 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=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html
--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.
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.eduwrote:
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:
- 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@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 Subject: Re: auditing failed login attempts
--On Tuesday, September 17, 2013 5:25 PM -0700 "Paul B. Henson" 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=0&a...
--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.
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@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@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.edumailto: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@OpenLDAP.org [mailto:openldap-technical-bounces@OpenLDAP.orgmailto: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.orgmailto:openldap-technical@openldap.org Subject: Re: auditing failed login attempts
--On Tuesday, September 17, 2013 5:25 PM -0700 "Paul B. Henson" <henson@acm.orgmailto: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=0&sektion=0&manpath=OpenLDAP+2.4-Release&format=html
--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.
--On Wednesday, September 18, 2013 11:03 AM -0700 Chris Jacobs Chris.Jacobs@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
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.
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
openldap-technical@openldap.org