Password Policy pwdFailureTime count limits?
by Jeffrey Crawford
Hello Everyone,
I'm having trouble enforcing our password policy for login attempts
within a particular time frame. After looking into the issue a little
further it seems to stem from the fact that the operational attribute
pwdFailureTime can only resolve time down to the second. so if there
are three Bind attempts within a single second we only get a single
pwdFailureTime entry for that time. Our policy is geared more to try
and prevent brute force attacks since this instance of the ldap server
will be available publicly. However someone can continuously try to
bind and not lock the account for as many seconds as is defined in the
pwdMaxFailure attribute in the policy definition.
For example:
if the following account locking configs are set
pwdMaxFailure: 10
pwdFailureCountInterval: 3600
pwdLockout: TRUE
pwdLockoutDuration: 30
If I try to lock my account by providing the incorrect credentials 11
times, it didn't lock if my 11 attempts were shorter than 10 seconds,
I then tried 100 in a for loop which finished in 7 seconds, it still
didn't lock. I looked at the account and counted the number of
pwdFailureTime's and found 7. I then place a one second sleep between
each bad bind attempt and low an behold it would lock as expected.
Therefore there seems to be a limitation of pwdFailureTime to only
resolve down to the second and its inability to store the same time
multiple times.
I'm not sure if this is expected behavior, but it makes locking
policies against brute force attacks more difficult to fend against. I
did a quick look to see if there was a way of delaying a incorrect
credential bind so it wouldn't return for at least a second, but
didn't see one. If such a config exists it might help if someone can
point me to it.
Thanks
Jeffrey Crawford
11 years, 11 months
Changing ACLs in dynamic configuration off-line
by Nick Milas
When we want to do some non-trivial re-engineering in ACLs, on-line
configuration using ldapmodify might be cumbersome.
So I think we could slapcat the config database, change ACLs in the
output, and slapadd it while the server is offline.
So, if we have a set of >100 ACL rules and we want to add one ACL rule
after, say, 22, would we have to *manually* renumber all the ACLs after
the new 23 so that they are numbered n+1? Or, when the config db is
read, is OpenLDAP able to resolve such conflicts (two ACLs with the same
number) and renumber automatically? If so, what is the logic?
(Maintenance of ACLs in the dynamic configuration remains one of my
concerns.)
Thanks,
Nick
11 years, 11 months
Bind with alternative DN pattern
by Mathias
Hi,
I have trouble understanding a rather simple LDAP config issue that
I'm sure someone on this list can easily help with:
How do I add a (or change the) pattern of the bind DN that slapd lets
me authenticate with?
I have a working slapd setup that I can happily bind to using DNs of
the form "cn=Bob Parr,dc=example,dc=com". However, all accounts also
have a unique "uid" attribute that I would like to use in addition to
(or, if not possible, instead of) the "cn"-based RDN for binding.
So, I'd like to (also) bind using the DN "uid=bob,dc=example,dc=com".
My understanding is that one entry can have several DNs as long as
each one is unambiguous. Shouldn't I be able to bind with anyone of
these?
I have spent hours on searching for documentation on this and turned
up surprisingly little. The problem is not an ACL issue since the
logged error when trying a "uid"-based bind is "DB_NOTFOUND: No
matching key/data pair found" rather than anything else...
I'd be _very_ grateful for any pointers on this...
Cheers,
Mathias
11 years, 11 months
openldap admin guide and 'slapd from scratch'
by Stefan Skoglund
Howdy.
I wonder if the ldif sample example the end of chapter 5 is correct ?
See below:
----
1. # example config file - global configuration entry
2. dn: cn=config
3. objectClass: olcGlobal
4. cn: config
5. olcReferral: ldap://root.openldap.org
6.
Line 1 is a comment. Lines 2-4 identify this as the global configuration
entry. The
olcReferral: directive on line 5 means that queries not local to one of
the
databases defined below will be referred to the LDAP server running on
the standard
port (389) at the host root.openldap.org. Line 6 is a blank line,
indicating the
end of this entry.
7. # internal schema
8. dn: cn=schema,cn=config
9. objectClass: olcSchemaConfig
10. cn: schema
11.
Line 7 is a comment. Lines 8-10 identify this as the root of the schema
subtree.
The actual schema definitions in this entry are hardcoded into slapd so
no
additional attributes are specified here. Line 11 is a blank line,
indicating the
end of this entry.
12. # include the core schema
13. include: file:///usr/local/etc/openldap/schema/core.ldif
14.
Line 12 is a comment. Line 13 is an LDIF include directive which
accesses the core
schema definitions in LDIF format. Line 14 is a blank line.
Next comes the database definitions. The first database is the special
frontend
database whose settings are applied globally to all the other databases.
15. # global database parameters
16. dn: olcDatabase=frontend,cn=config
17. objectClass: olcDatabaseConfig
18. olcDatabase: frontend
19. olcAccess: to * by * read
20.
Line 15 is a comment. Lines 16-18 identify this entry as the global
database entry.
Line 19 is a global access control. It applies to all entries (after any
applicable
database-specific access controls). Line 20 is a blank line.
The next entry defines the config backend.
21. # set a rootpw for the config database so we can bind.
22. # deny access to everyone else.
23. dn: olcDatabase=config,cn=config
24. objectClass: olcDatabaseConfig
25. olcDatabase: config
26. olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
27. olcAccess: to * by * none
28.
Lines 21-22 are comments. Lines 23-25 identify this entry as the config
database
entry. Line 26 defines the super-user password for this database. (The
DN defaults
to "cn=config".) Line 27 denies all access to this database, so only the
super-user
will be able to access it. (This is already the default access on the
config
database. It is just listed here for illustration, and to reiterate that
unless a
means to authenticate as the super-user is explicitly configured, the
config
database will be inaccessible.)
-----
The trouble i had is regarding the olcDatabase=frontend and
olcDatabase=config stanzas.
slapadd could do its work but the layout in cn=config/
would look like this afterwards:
-----
olcDatabase=frontent.ldif
olcDatabase=config.ldif
olcDatabase=hdb.ldif
-----
And as soon as slapd started an extraneous ghostly
olcDatabase={-1}frontend.ldif would show up.
I had to instantiate the frontend and config as this.
---
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {-1}frontend
---
and
----
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
----
Which works for me.
11 years, 11 months
Modify or add information after conversion of slapd.conf to cn=config with fresh install of OpenLdap
by rey sebastien
Hi!
I start with a fresh installation of openldap 2.4.28 on debian. They are
some problem with the debian package, and with gnuTLS, so i compile a
version with opennSSL library.
It's hard to understand with the official documentation how to start a
from scratch installation with the new cn=config administration of
openLDAP. So, i make a conversion ( with the great help of users on this
mailling list ) from slapd.conf to cn=config on the first launch of
openLDAP with this commands :
|/usr/local/libexec/slapd -u openldap -g openldap -f slapd.conf.seb -F /usr/local/etc/openldap/slapd.d/ -d -1
|
My slapd.conf.seb, really simple, equal :
|include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/nis.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/openldap.schema
include /usr/local/etc/openldap/schema/misc.schema
include /usr/local/etc/openldap/schema/ppolicy.schema
include /usr/local/etc/openldap/schema/gosa/samba3.schema
include /usr/local/etc/openldap/schema/gosa/trust.schema
include /usr/local/etc/openldap/schema/gosa/gofax.schema
include /usr/local/etc/openldap/schema/gosa/gofon.schema
include /usr/local/etc/openldap/schema/gosa/gosystem.schema
include /usr/local/etc/openldap/schema/gosa/goto-mime.schema
include /usr/local/etc/openldap/schema/gosa/goto.schema
include /usr/local/etc/openldap/schema/gosa/goserver.schema
include /usr/local/etc/openldap/schema/gosa/gosa-samba3.schema
include /usr/local/etc/openldap/schema/gosa/openssh-lpk.schema
include /usr/local/etc/openldap/schema/gosa/dnszone.schema
include /usr/local/etc/openldap/schema/gosa/nagios.schema
include /usr/local/etc/openldap/schema/gosa/dhcp.schema
include /usr/local/etc/openldap/schema/gosa/sudo.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
database bdb
suffix "dc=parisgeo,dc=cnrs,dc=fr"
rootdn "cn=admin,cn=config,dc=parisgeo,dc=cnrs,dc=fr"
rootpw {SSHA} secret
directory /srv/openldap-data
index objectClass eq
|
I have no problem with this simple conversion, but after that, it's
impossible to import data with this command ldapadd or ldapmodify.
I don't understand the default right for read/write for openLDAP, i try
with ldapmodify, with bind and password, and i have the same problem :
||
|root@xxxx:/usr/local/etc/openldap# ldapadd -x -D "cn=admin,cn=config,dc=parisgeo,dc=cnrs,dc=fr" -W -f sauvegarde.ldif
Enter LDAP Password: xxx
adding new entry "cn=admin,dc=parisgeo,dc=cnrs,dc=fr"
ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification allowed
|
I try to modify the right for cn=config with this sample :
|dn: olcDatabase={-1}frontend,cn=config
changetype: modify
delete: olcAccess
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootDN
olcRootDN: cn=admin,cn=config
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA} secret
dn: olcDatabase={0}config,cn=config
changetype: modify
delete: olcAccess
ldapadd -Y EXTERNAL -H ldapi:/// -f slapd.modify.root.ldif
|
Same problem, i have no right todo that, with or without option the
password entry -W or bind option -D
"cn=config,cn=admin,dc=parisgeo,dc=cnrs,dc=fr"
|root@xxxx:/usr/local/etc/openldap# ldapadd -Y EXTERNAL -H ldapi:/// -f slapd.modify.root.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={-1}frontend,cn=config"
ldap_modify: Insufficient access (50)
root@xxxx:/usr/local/etc/openldap# ldapadd -x -W -H ldapi:/// -f slapd.modify.root.ldif Enter LDAP Password:
ldap_bind: Invalid credentials (49)
root@xxxxx:/usr/local/etc/openldap# ldapadd -D "cn=config,cn=admin,dc=parisgeo,dc=cnrs,dc=fr" -W -Y EXTERNAL -H ldapi:/// -f slapd.modify.root.ldif
Enter LDAP Password:
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={-1}frontend,cn=config"
ldap_modify: Insufficient access (50)|
Anybody have this problem in the past, and have an idea of the solution
to create a good start configuration from scratch installation ? Do you
think there is mistake in my simple installation/configuration ?
I also create a post on serverFault.Com site, but i have no answer at
this time
http://serverfault.com/questions/342086/impossible-to-modify-or-add-infor...
Best regards,
SR
11 years, 11 months
RE: OpenLDAP replciation issue with MirrorMode
by ZHOU Eric JP
Dear OpenLDAP Administrators,
Not sure if you get time to look into this issue yet.
This issue only happens when power-off/power cut-off one of the mirror servers, and could be probably prevented by “sending heart beat” to verify the established connections.
Thanks for your time looking at this email thread and your effort :)
Thanks,
Eric
________________________________
From: owner-qdlcp-security(a)LIST.ALCATEL-LUCENT.COM [mailto:owner-qdlcp-security@LIST.ALCATEL-LUCENT.COM] On Behalf Of ZHOU Eric JP
Sent: 2012年1月4日 15:56
To: openldap-bugs(a)openldap.org; info(a)OpenLDAP.org; openldap-technical(a)openldap.org; openldap-devel(a)openldap.org
Cc: qdlcp-security(a)list.alcatel-lucent.com; ANTHONY Michael; HO Yao; VAN RANGELROOIJ Ardo
Subject: OpenLDAP replciation issue with MirrorMode
Dear OpenLDAP Administrators,
Recently we come across an OpenLDAP replication issue with OpenLDAP Mirror Mode.
After configuring MIRROR-A and MIRROR-B in mirror mode with below configuration, it worked pretty well for a long period.
But an issue comes up after MIRROR-A reboot, MIRROR-B could not get modification from MIRROR-A any more.
After investigating the issue we find the original socket on MIRROR-B (consumer) is not reconnected.
====================================
## MIRROR-A ----------------------------------------------------------------------
## ----------------------------------------------------------------------
serverID 1
## Consumer
syncrepl rid=001
provider=ldap://10.207.131.1:389
bindmethod=simple
binddn="uid=PrivDirUsr,o=CSOSSO"
credentials=mypassword
searchbase="o=CSOSSO"
schemachecking=on
type=refreshAndPersist
interval=00:00:01:00
retry="10 +"
mirrormode on
## MIRROR-A ----------------------------------------------------------------------
## ----------------------------------------------------------------------
serverID 2
## Consumer
syncrepl rid=001
provider=ldap://10.207.130.1:389
bindmethod=simple
binddn="uid=PrivDirUsr,o=CSOSSO"
credentials=mypassword
searchbase="o=CSOSSO"
schemachecking=on
type=refreshAndPersist
interval=00:00:01:00
retry="10 +"
mirrormode on
Below is the socket information after MIRROR-A reboot,
====================================
## MIRROR-A ----------------------------------------------------------------------
# lsof -i :389 | grep ldap | grep -v sshd | grep -v localhost | grep 10
slapd 16842 root 14u IPv4 36160 TCP ln007-cnfg-p00m000-d0:51114->10.207.131.1:ldap (ESTABLISHED)
## MIRROR-B ----------------------------------------------------------------------
# lsof -i :389 | grep ldap | grep -v sshd | grep -v localhost | grep 10
slapd 4825 root 14u IPv4 168497 TCP ln007-cnfg-p00m001-d0:52239->10.207.131.0:ldap (ESTABLISHED)
slapd 4825 root 18u IPv4 193403 TCP ln007-mi-p00m001-d0:ldap->10.207.130.0:51114 (ESTABLISHED)
Normally it should be,
## MIRROR-A ----------------------------------------------------------------------
# lsof -i :389 | grep ldap | grep -v sshd | grep -v localhost | grep 10
slapd 16842 root 14u IPv4 36160 TCP ln007-cnfg-p00m000-d0:51114->10.207.131.1:ldap (ESTABLISHED)
slapd 4825 root 18u IPv4 193403 TCP ln007-mi-p00m000-d0:ldap->10.207.130.1: 52239 (ESTABLISHED) // This link is missing
## MIRROR-B ----------------------------------------------------------------------
# lsof -i :389 | grep ldap | grep -v sshd | grep -v localhost | grep 10
slapd 4825 root 14u IPv4 168497 TCP ln007-cnfg-p00m001-d0:52239->10.207.131.0:ldap (ESTABLISHED)
slapd 4825 root 18u IPv4 193403 TCP ln007-mi-p00m001-d0:ldap->10.207.130.0:51114 (ESTABLISHED)
I would greatly apreicate if you could provide some suggestions/comments upon this or improve OpenLDAP functionality to avoid this.
For me I think this is normal TCP server down scenario, but probably you people could prohibit this from happening in below two methods?
1. Let OpenLDAP send mutual heart beat so that client knows when server is dead.
2. Let OpenLDAP send message to all its client when it is dying (e.g. receiving SIGTERM) // this does not work when MIRROR-A power cycle.
Sincerely,
Eric Zhou Jianping
P please save a tree by not printing this e-mail.
________________________________
To unsubscribe: qdlcp-security-unsubscribe-request(a)list.alcatel-lucent.com<mailto:qdlcp-security-unsubscribe-request@list.alcatel-lucent.com>
11 years, 11 months
Copy ldap to another with different schema
by rey sebastien
Hi,
I have two ldap, one full of users, with gosa open source project
specific schema (https://oss.gonicus.de/labs/gosa), and one which is
empty, without this schema. I want to make a clean copy of my users into
the first ldap to the second ldap, because my version of gosa installed
is not functionnal :-/
Is it possible with slapcat to extract only useful information (so
information without gosa schema information) ? Is there any solution to
resolve this use case ?
Thanks a lot,
Best regards,
SR
11 years, 11 months
How to check syncrepl?
by Marco Weber
Hi,
We have a MirrorMode replication setup that uses openldap's syncrepl.
The HA setup seems work fine with pacemaker.
Now i would like to setup a nagios check for the replication.
But before i can do that, i've got a simple question:
How can i poll the replication status?
Thanks in advance for any reply,
Marco
11 years, 11 months
