password policies not functioning properly
by Kruger, P (Justid)
I've set password policies on my OpenLDAP 2.4.
Unfortunately things do not work as expected and although extensively searched on forums and Google, I cannot get the proper results. What am I missing in what I did or should have done?
What goes wrong:
- Password policies seem not to be validated or I do get a failure message
The failures depend on pwdinHistory setting to zero (no failure) to > 0 failure like given below
5798c94a <= acl_access_allowed: granted to database root
5798c94a bdb_modify_internal: replace userPassword
5798c94a bdb_modify_internal: replace pwdChangedTime
5798c94a bdb_modify_internal: add pwdHistory
5798c94a bdb_modify_internal: replace pwdChangedTime
5798c94a bdb_modify_internal: add pwdHistory
5798c94a bdb_modify_internal: 20 modify/add: pwdHistory: value #0 already exists
5798c94a hdb_modify: modify failed (20)
5798c94a send_ldap_result: conn=1000 op=18 p=3
5798c94a send_ldap_result: err=20 matched="" text="modify/add: pwdHistory: value #0 already exists"
5798c94a send_ldap_response: msgid=62 tag=103 err=20
ber_flush2: 61 bytes to sd 15
0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo
0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis
0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a
0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists
ldap_write: want=61, written=61
0000: 30 3b 02 01 3e 67 36 0a 01 14 04 00 04 2f 6d 6f 0;..>g6....../mo
0010: 64 69 66 79 2f 61 64 64 3a 20 70 77 64 48 69 73 dify/add: pwdHis
0020: 74 6f 72 79 3a 20 76 61 6c 75 65 20 23 30 20 61 tory: value #0 a
0030: 6c 72 65 61 64 79 20 65 78 69 73 74 73 lready exists
5798c94a conn=1000 op=18 RESULT tag=103 err=20 text=modify/add: pwdHistory: value #0 already exists
5798c94a slap_graduate_commit_csn: removing 0x7f8a0c107960 20160727144634.392449Z#000000#000#000000
This makes, as far as I tested, no difference with just using a default policy or when using a default and specific policy with pwdPolicySubentry attribute in the user.
I've used ACL's on my LDAP schema.
My purpose:
Use a default policy which basically says to use no policy
Add a specific policy for users in a subtree.
Below are the steps and LDAP LDIF files used to build the OpenLDAP.
Included here are the LDIF files for:
config, base and sub part of tree, replication ou and user, application users (service accounts), ldap managers ou, ACL's, OU's needed for application specific content, policy.
Excluded here (but done) are the LDIF files for: enable logging, replication, TLS/SSL.
The LDIF files first line contains the LDIF filename and the command used to apply them
# ldapadd -Y EXTERNAL -H ldapi:/// -f 01_addrootpw.ldif
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}hashhashhashhashhashhash
# ldapadd -Y EXTERNAL -H ldapi:/// -f 02_root-base.ldif
# change olcRootPW to your Root password
# change domain parts to your domain
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" read by * none
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=nl
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA} hashhashhashhashhashhash
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by dn="cn=Manager,ou=ldapbeheerders,dc=example,dc=nl" write by anonymous auth by self write by * none
olcAccess: {1}to dn.base="" by * read
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 03_ldap-manager.ldif
dn: dc=example,dc=nl
objectClass: top
objectClass: dcObject
objectclass: organization
o: example nl
dc: example
dn: ou=ldapbeheerders,dc=example,dc=nl
objectclass: organizationalUnit
ou: ldapbeheerders
dn: cn=Manager,ou=ldapbeheerders,dc=example,dc=nl
objectclass: organizationalRole
cn: Manager
description: Directory Manager
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 04_replication_user.ldif
dn: ou=replicatie,dc=example,dc=nl
objectclass: organizationalUnit
ou: replicatie
description: replicatie groep
dn: cn=replicator,ou=replicatie,dc=example,dc=nl
cn: replicator
sn: user
objectClass: person
userPassword: passwordincleartext
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 05_applications.ldif
# Create ou generic application scheme
dn: ou=applicaties,dc=example,dc=nl
objectclass: organizationalUnit
ou: applicaties
# Aanmaak ou APP1 applicatieschema
dn: ou=APP1,dc=example,dc=nl
objectclass: organizationalUnit
ou: APP1
# Aanmaak ou APP2 applicatieschemas
dn: ou=APP2,dc=example,dc=nl
objectclass: organizationalUnit
ou: APP2
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 06_ServiceAccounts.ldif
dn: ou=ServiceAccounts,dc=example,dc=nl
objectclass: organizationalUnit
ou: ServiceAccounts
description: Service Accounts Applicaties
#Service account APP1
dn: cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl
cn: SAAPP1
sn: user
objectClass: person
userPassword: {SSHA}hashedpassword
description: Service Account APP1
#Service account APP2
dn: cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl
cn: SAAPP2
sn: user
objectClass: person
userPassword: {SSHA} hashedpassword
description: Service Account APP2
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 07_ACL.ldif
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: to attrs=userPassword
by anonymous auth
by self write
by * break
olcAccess: to dn="ou=replicatie,dc=example,dc=nl"
by self write
by * none
olcAccess: to *
by dn.base="cn=replicator,ou=replicatie,dc=example,dc=nl" read
by * break
olcAccess: to dn.subtree="cn=default,ou=policies,dc=example,dc=nl"
by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write
by * none
olcAccess: to dn="ou=ldapbeheerders,dc=example,dc=nl"
by dn.children="ou=ldapbeheerders,dc=example,dc=nl" write
by * none
olcAccess: to dn="ou=ServiceAccounts,dc=example,dc=nl"
by self search
by * none
olcAccess: to dn.subtree="ou=applicaties,dc=example,dc=nl"
by dn.children="ou=ServiceAccounts,dc=example,dc=nl" write
by * none
olcAccess: to dn.subtree="ou=APP1,dc=example,dc=nl"
by dn.base="cn=SAAPP1,ou=ServiceAccounts,dc=example,dc=nl" write
by * none
olcAccess: to dn.subtree="ou=APP2,dc=example,dc=nl"
by dn.base="cn=SAAPP2,ou=ServiceAccounts,dc=example,dc=nl" write
by * none
olcAccess: to dn.children="dc=example,dc=nl"
by * read
olcAccess: to dn.children="dc=nl"
by * read
# ldapadd -x -D cn=Manager,ou=ldapbeheerders,dc=example,dc=nl -W -f 08_Add-testusers.ldif
dn: uid=APP1_1,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP1_1
cn: APP1_1 gebruiker
sn: gebruiker
pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl
dn: uid=APP1_2,ou=APP1gebruikers,ou=APP1,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP1_2
cn: APP1_2 gebruiker
sn: gebruiker
pwdPolicySubentry: cn=default,ou=policies,ou=APP1,dc=example,dc=nl
dn: cn=APP2_1,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP2_1
cn: APP2_1 gebruiker
sn: gebruiker
dn: cn=APP2_2,ou=APP2gebruikers,ou=APP2,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP2_2
cn: APP2_2 gebruiker
sn: gebruiker
dn: cn=APP2_3,ou=gebruikers,ou=applicaties,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP2_3
cn: APP2_3 gebruikercat
sn: gebruiker
dn: cn=APP2_4,ou=gebruikers,ou=applicaties,dc=example,dc=nl
objectClass: inetOrgPerson
objectClass: organizationalPerson
ObjectClass: person
objectClass: top
uid: APP2_4
cn: APP2_4 gebruiker
sn: gebruiker
Below is the part where the password policies are configured.
# ldapadd -Y EXTERNAL -H ldapi:/// -f P01_ppolicymodule.ldif
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModuleLoad: ppolicy.la
olcModulePath: /usr/lib64/openldap
# ldapadd -Y EXTERNAL -H ldapi:/// -f P02_ppolicyoverlay.ldif
dn: olcOverlay=ppolicy,olcDatabase={2}hdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=example,dc=nl
olcPPolicyUseLockout: TRUE
olcPPolicyHashCleartext: TRUE
# ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P03_default_ppolicy.ldif
dn: ou=policies,dc=example,dc=nl
objectClass: top
objectClass: organizationalUnit
ou: policies
dn: cn=default,ou=policies,dc=example,dc=nl
objectClass: top
objectClass: device
objectClass: pwdPolicyChecker
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdInHistory: 8
pwdMinLength: 8
pwdMaxFailure: 5
pwdFailureCountInterval: 1800
pwdCheckQuality: 1
pwdMustChange: TRUE
pwdGraceAuthNLimit: 0
pwdMaxAge: 7776000
pwdExpireWarning: 1209600
pwdLockoutDuration: 900
pwdLockout: TRUE
pwdSafeModify: FALSE
# ldapadd -x -D 'cn=Manager,ou=ldapbeheerders,dc=example,dc=nl' -W -f P04_APP1_ppolicies.ldif
dn: ou=policies,ou=APP1,dc=example,dc=nl
ou: policies
objectClass: top
objectClass: organizationalUnit
dn: cn=default,ou=policies,ou=APP1,dc=example,dc=nl
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdAllowUserChange: TRUE
pwdCheckQuality: 0
pwdExpireWarning: 374400
pwdFailureCountInterval: 1800
pwdGraceAuthNLimit: 5
pwdInHistory: 12
pwdLockout: TRUE
pwdLockoutDuration: 0
pwdMaxAge: 2592000
pwdMaxFailure: 5
pwdMinAge: 0
pwdMinLength: 8
pwdMustChange: TRUE
pwdSafeModify: FALSE
6 years, 8 months
Re: openldap 2.4.44 + ITS 8432 patch still infinitely replicates
by Howard Chu
Paul B. Henson wrote:
> I upgraded one of the nodes of a four node MMR delta syncrepl openldap
> system today to 2.4.44 + the backported ITS 8432 patch (the other three
> nodes were still running 2.4.41, which all four had been running for
> quite some time with no issues) and within a few hours they started blowing
> up with the infinite replication issue referred to in ITS 8432, all the
> accesslogs were filled with the same modification repeated over and
> over. I ended up having to slapcat the db, restore the upgraded node to
> 2.4.41, and then reload the db on all of them to recover.
>
>>From what I understand the bug was supposed to have existed in versions
> before 2.4.44, but I had never seen it in 2.4.41, and backing out
> to that version seems to have restored stability. I remember seeing
> another ITS regarding an issue even with the 8432 patch applied if
> you're using the memberOf overlay (although that number escapes me at
> the moment), but I thought that only applied if you were updating group
> memberships and the change that blew up my system was a password change.
>
> Is it possible updating one node to the fixed version somehow triggered
> the bug in one of the other nodes? Do I need to upgrade all the nodes at
> the same time? Or are there possibly still edge cases where 2.4.44 with
> the patch are still broken? I did a test run of the upgrade in my dev
> environment, including the staged rollout with temporarily mixed
> versions, but it doesn't really have the same load and variety of access
> patterns that production sees.
The fix for #8432 only prevents the redundant mod from being processed on a
particular node. If other nodes are still accepting the redundant op then yes,
it will continue to propagate. So yes, you need the patched code on all nodes.
> Thanks...
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 8 months
need to recover slapd password and upgrade openldap
by Dan Hyatt
My admin openLDAP 2.2 password became corrupt in the last week and I
cannot log in as admin.
I was hoping there was an easy recovery such as lunix has shutting down
slapd, removing the hashed password, bringing it back up and resetting
the blank password using slappasswd. I can't take a chance unless I know
for sure.
I have searched Google and read the admin manual. I inherited a system
using open ldap server on an old redhat, and the slapd password was
corrupted (or locked out by another admin????).
this is openldap 2.2 on an old redhat box.
I cannot risk having a group of users locked out for more than an hour
because LDAP is down.
What I need to do today is recover (reset) the slapd password so I can
log into the database.
I found some instructions which seem simple risky and no backout
strategy. Simply running
http://techiezone.rottigni.net/2011/12/change-root-dn-password-on-openldap/
After recovery of root. I was planning on
1. shutting down server, making a P2V copy for a hypervisor, then
creating another ldap master and slave servers on redhat6 with
openldap2.4 once I have this password issue resolved.
Having the LDAP on two separate hyper visors (with local disks) to avoid
the storage/authentication chicken/egg
Is there a better upgrade plan
I have the log files, is there a way to backout to last week without the
admin password (which became corrupt last week).
6 years, 8 months
Re: sizelimit
by Maily Peng
> You have to define the limit for the binddn you use in your syncrepl
> definition ( 'cn=user,ou=login,cn=system' here), or change this binddn
> to be the one for which you have an unlimited sizeLimit.
Thanks for the advice Emmanuel.
I finally put these lines on the global limits :
/sizelimit size.soft=unlimited size.hard=1000//
//timelimit time.soft=unlimited time.hard=5
/Tell me if i'm wrong but the hard limit is the absolute time /size the
server will spend processing the request.
6 years, 8 months
openldap 2.4.44 + ITS 8432 patch still infinitely replicates
by Paul B. Henson
I upgraded one of the nodes of a four node MMR delta syncrepl openldap
system today to 2.4.44 + the backported ITS 8432 patch (the other three
nodes were still running 2.4.41, which all four had been running for
quite some time with no issues) and within a few hours they started blowing
up with the infinite replication issue referred to in ITS 8432, all the
accesslogs were filled with the same modification repeated over and
over. I ended up having to slapcat the db, restore the upgraded node to
2.4.41, and then reload the db on all of them to recover.
>From what I understand the bug was supposed to have existed in versions
before 2.4.44, but I had never seen it in 2.4.41, and backing out
to that version seems to have restored stability. I remember seeing
another ITS regarding an issue even with the 8432 patch applied if
you're using the memberOf overlay (although that number escapes me at
the moment), but I thought that only applied if you were updating group
memberships and the change that blew up my system was a password change.
Is it possible updating one node to the fixed version somehow triggered
the bug in one of the other nodes? Do I need to upgrade all the nodes at
the same time? Or are there possibly still edge cases where 2.4.44 with
the patch are still broken? I did a test run of the upgrade in my dev
environment, including the staged rollout with temporarily mixed
versions, but it doesn't really have the same load and variety of access
patterns that production sees.
Thanks...
6 years, 8 months
openldap back-sql mysql wait_timeout
by Simon Ryf
Dear members,
I have timeout issues with back-sql using mysql as backend (read-only).
I could successfully setup open-ldap with back-sql querying from a mysql db.
However there is a wait_timeout in mysql and if no query is being made for > then wait_timeout the slapd breaks and I have to restart it to connect to mysql again.
http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html
As a workaround I could implement a cron-job to execute a query every x hour (depending on wait_timeout). However I would much more like that back-sql is able to (auto-)reconnect.
I'm not a developer and have no idea how this can be done - maybe this is in the sql-wrap.c code?
executing an ldap query after "wait_timeout" returns slapd.log:
Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_get_db_conn()
Jul 20 17:22:53 STAG-BCC slapd[2054]: <==backsql_get_db_conn()
Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_attrlist_add(): adding "objectClass" to list
Jul 20 17:22:53 STAG-BCC slapd[2054]: ==>backsql_dn2id("dc=bbn,dc=ch") matched expected
Jul 20 17:22:53 STAG-BCC slapd[2054]: backsql_dn2id("dc=bbn,dc=ch"): id_query "SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?"
Jul 20 17:22:53 STAG-BCC slapd[2054]: backsql_dn2id("dc=bbn,dc=ch"): error executing query ("SELECT id,keyval,oc_map_id,dn FROM ldap_entries WHERE dn=?", "dc=bbn,dc=ch"):
Jul 20 17:22:53 STAG-BCC slapd[2054]: Return code: -1
Jul 20 17:22:53 STAG-BCC slapd[2054]: nativeErrCode=2006 SQLengineState=08S01 msg="[MySQL][ODBC 5.1 Driver][mysqld-5.5.49-0+deb8u1]MySQL server has gone away"
Jul 20 17:22:53 STAG-BCC slapd[2054]: <==backsql_dn2id("dc=bbn,dc=ch"): err=80
Any suggestions are most welcome
Br
Simon
I'm using the following setup:
-----------------------------
Debian Jessie x86_64 (up to date)
Openldap-2.4.44 compiled from source with ./configure --enable-sql
libmyodbc 5.1.10-3
mysql 5.5.49-9
odbc.ini:
[ldapds]
Driver = MySQL
Description = BCC MySQL DB
SERVER = 127.0.0.1
PORT = 3306
USER = ldap
Password = ldap
Database = prov_ldap
SOCKET = /var/lib/mysql/mysql.sock
odbcinst.ini:
[MySQL]
Description = ODBC for MySQL
Driver = /usr/lib/x86_64-linux-gnu/odbc/libmyodbc.so
Setup = /usr/lib/x86_64-linux-gnu/odbc/libodbcmyS.so
FileUsage = 1
slapd.conf:
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/SIP.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
loglevel any
database sql
suffix "dc=bbn,dc=ch"
rootdn "dc=bbn,dc=ch"
rootpw ldap
dbname ldapds
dbuser ldap
dbpasswd ldap
subtree_cond "ldap_entries.dn LIKE CONCAT('%',?)"
insentry_stmt "INSERT INTO ldap_entries (dn,oc_map_id,parent,keyval) VALUES (?,?,?,?)"
has_ldapinfo_dn_ru no
#cachesize 0
6 years, 8 months
is there a bug with SSSD
by Kaveh Ehsani
I have tried using SSSD to switch between ldap provider and consumer.
I have:
ldap_uri = provider.example.com
ldap_backup_uri = consumer.example.com
It works fine, until I stop the provider to see if the clients will look at the consumer. They don't.
I set ldap_uri = consume.example.com and clear the cache both via sss_cache -E and deleting all the files in /var/lib/sss/db and restart sssd.
Even though it starts fine, I have ldap_uri = provider.example.com inside the journalctl -xe file and complains that can not contact the ldapserver., which is intentionally switched off. Looks like ldap_uri is hard coded some where the first time it is set.
I have opened a bug report, but no replies to it at the moment. This is the link for the bug report in case anyone is interested.
https://bugs.centos.org/view.php?id=11174
6 years, 8 months
using mdb backend on centos 7
by Kaveh Ehsani
I am trying to load the module for openldap mdb backend which is suppose to be located in /usr/lib64/openldap but it is not there. I am trying this ldif;
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib64/openldap
olcModuleload: back_mdb
ldapadd -Y EXTERNAL -H ldap:/// -f mod-mdb.ldif
Of course there re no back_bdb or back_hdb, do I not need to load the module first !? I am using centos 7, Thank you.
6 years, 8 months
