[SOLVED] Openldap ppolicy overlay is not working

gresso · 02-05-2016, 09:40 AM

I have been trying to configure openldap to use ppolicy overlay but non of the procedures found online have worked. I tried tens of problems discussed in the forums but to no avail. So I would be so grateful if someone can check my configuration and pin the problem.

I'm using the olc (cn=config) configuration on debian jessie. Openldap version is 2.4.40

here is the ldapsearch of -b cn=config excluded the schemas contents of (core, cosine, inetorgperson and ppolicy)

Code:

# extended LDIF
#
# LDAPv3
# base <cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# config
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcLogLevel: none
olcPidFile: /var/run/slapd/slapd.pid
olcToolThreads: 1

# module{0}, config
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb
olcModuleLoad: {1}ppolicy.la

# {0}mdb, config
dn: olcBackend={0}mdb,cn=config
objectClass: olcBackendConfig
olcBackend: {0}mdb

# {-1}frontend, config
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to * by
 dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
 ,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read olcSizeLimit: 500

# {0}config, config
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by
 dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
 by * break
olcRootDN: cn=admin,cn=config
olcRootPW: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=

# {1}mdb, config
dn: olcDatabase={1}mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: {1}mdb
olcDbDirectory: /var/lib/ldap
olcSuffix: dc=home,dc=me
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by
 anonymous auth by * none
olcAccess: {1}to attrs=loginShell,gecos by dn="cn=admin,dc=home,dc=me"
 write b y self write by * read
olcAccess: {2}to dn.sub="ou=people,dc=home,dc=me" by
 dn="cn=boss,ou=people,dc=home,dc=me" write by self write by * read
olcAccess: {3}to dn.base="" by * read
olcAccess: {4}to * by * read
olcLastMod: TRUE
olcRootDN: cn=admin,dc=home,dc=me
olcRootPW: {SSHA}mVopmqq0XwfC7WVwqlOnJgx5ouKNNAoQ
olcDbCheckpoint: 512 30
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbMaxSize: 1073741824

# {0}ppolicy, {1}mdb, config
dn: olcOverlay={0}ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=home,dc=me
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: FALSE
olcPPolicyForwardUpdates: FALSE

# search result
search: 2
result: 0 Success

# numResponses: 14
# numEntries: 13

Here is the ldapsearch of the -b dc=home,dc=me

Code:

# extended LDIF
#
# LDAPv3
# base <dc=home,dc=me> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# home.me
dn: dc=home,dc=me
objectClass: top
objectClass: dcObject
objectClass: organization
o: home.me
dc: home

# admin, home.me
dn: cn=admin,dc=home,dc=me
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

# people, home.me
dn: ou=people,dc=home,dc=me
ou: people
objectClass: organizationalUnit

# boss, people, home.me
dn: cn=boss,ou=people,dc=home,dc=me
cn: boss
objectClass: simpleSecurityObject
objectClass: organizationalRole

# policies, home.me
dn: ou=policies,dc=home,dc=me
ou: policies
objectClass: organizationalUnit

# passwordDefault, policies, home.me
dn: cn=passwordDefault,ou=policies,dc=home,dc=me
objectClass: pwdPolicy
objectClass: person
objectClass: top
cn: passwordDefault
sn: passwordDefault
pwdAttribute: userPassword
pwdCheckQuality: 0
pwdMinAge: 0
pwdMaxAge: 0
pwdMinLength: 8
pwdInHistory: 5
pwdMaxFailure: 3
pwdFailureCountInterval: 0
pwdLockout: FALSE
pwdLockoutDuration: 0
pwdAllowUserChange: TRUE
pwdExpireWarning: 0
pwdGraceAuthNLimit: 0
pwdMustChange: TRUE
pwdSafeModify: FALSE

# test, people, home.me
dn: uid=test,ou=people,dc=home,dc=me
uid: test
objectClass: account
objectClass: posixAccount
cn: test
uidNumber: 1020
gidNumber: 1020
homeDirectory: /home/test
loginShell: /bin/bash

# search result
search: 2
result: 0 Success

# numResponses: 8
# numEntries: 7

When I created the user test, none of the default password policy attributes got attached to it. I haven't been forced to change the password after the first login even when I added the pwdReset to the user test, I only got denied from logging-in.

PS: I created an admin account, cn=boss,ou=people,dc=home,dc=me, in the DIT with the appropriate permissions, and created the user test as that user. I've read many threads and all stated that OpenLDAP manager account, bypasses all overlays.

I tried these configuration on Ubuntu, Debian and CentOS and none of them worked. Any help please!

gresso · 02-08-2016, 10:21 AM

Anyone?!

gresso · 02-11-2016, 04:35 PM

No one?! That's really weird!

gresso · 02-13-2016, 02:11 PM

After I added pwdpolicysubentry to the newly created users and send pwdReset to them, users got denied from logging-in and here is what it is shown in the journalctl

Code:

[5e18f8] <authc="poor"> ldap_result() failed: Insufficient access: Operations are restricted to bind/unbind/abandon/StartTLS/modify password
Feb 13 19:17:47 debian-jessie nslcd[614]: [5e18f8] <authc="poor"> uid=poor,ou=people,dc=home,dc=me: Insufficient access
Feb 13 19:17:47 debian-jessie nslcd[614]: [5e18f8] <authc="poor"> uid=poor,ou=people,dc=home,dc=me: Password must be changed
Feb 13 19:17:47 debian-jessie sshd[2496]: pam_ldap(sshd:auth): Authentication failure; user=poor
Feb 13 19:17:49 debian-jessie sshd[2496]: Failed password for poor from 192.168.5.7 port 45534 ssh2

So, it worked but can't get the user to change the password himself/herself. I think I'm getting so close to get it to work properly and hope that someone would help me do it.

gresso · 03-10-2016, 06:09 AM

Unfortunately there is no straight way to make the Password Policy Overlay meet my requirements which one of them is to force a user to change his/her password on the first login.

But, now, I'm able to do so by combining the ppolicy overlay with shadowAccount object class using its shadowLastChange attribute and make it equal to zero (Both shadowAccount object class and shadowLastChange attribute are added to the user account). The ppolicy will handle the rest. (I tried shadowAccount by its own and it didn't work).

This work around, if I may say, worked on Debian only. Even CentOS client systems didn't comply to the ppolicy forced by the LDAP server on Debian. Debian and Ubuntu clients worked.

pwdReset attribute: This attribute does lock the account and does require the password to be changed but it can only be done through the command ldappasswd and not at login. The value of this attribute overrides the setting of pwdMustChange.