4

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)

# 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

# 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.

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

!! Edit !!

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

[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

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.

user3464156
  • 39
  • 1
  • 5

2 Answers2

1

There are several possibly reasons for this but the most obvious is that you may have been logged as the OpenLDAP manager account, which bypasses all overlays. You need to create an admin or application account in the DIT with the appropriate permissions, and execute all further admin updates as that user. You will need to delete and re-add this test user that way too.

The Manager account is for OpenLDAP itself, not for applications or other users. Don't use it.

NB: You need to use the password-policy request control to be told about resets, required password changes, grace logins, quality or history failures, etc.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thanks EJP for the quick reply but actually I did that and you can check the user boss details above. He has the permissions to do anything on group people and the user test was created by him not by the rootDN user. – user3464156 Feb 04 '16 at 11:34
  • Hmm, let me take a closer look. I use `device` as the object class for policy entries. – user207421 Feb 05 '16 at 00:39
  • EJP, Would you please explain in more details what you mean in saying "extended operations to change the password" and "use the password-policy request control" and how to use them? what would objectclass "device" do for policy entries? – user3464156 Feb 05 '16 at 10:30
  • These are API questions and are answered by reading the API documentation. You don't even state what language you're using so it's impossible to be more specific even if it wasn't too broad for a comment, which it is. Using 'device' instead of 'person' wont fix this but it's more logical. A policy isn't w person. – user207421 Feb 05 '16 at 20:33
  • EJP, is there anything else beside the above configuration that I may check that can help figure what is going wrong? Or it just the OpenLDAP doesn't support the password policy as the proprietary LDAP server? – user3464156 Feb 07 '16 at 20:04
  • If it didn't support the ppolicy it wouldn't start, it would reject the configuration. I've looked at this a few times and I can't see anything wrong with it. But I'm not sure that any of the attributes ever gets added to a user until you actually *use* the ppolicy, and that is only done via the request control or the extended operations I mentioned. I posted some Java code for them here a while ago. – user207421 Feb 08 '16 at 05:22
  • If you need to test this independently, you can execute extended operations directly with the ldap*.exe client programs, and maybe attach request controls too, but I forget the details. All in the manual. – user207421 Feb 08 '16 at 23:10
  • Thanks @EJP for getting back to me. I'm trying to make it work for three weeks now and any keyword search on my google page gives me colored purple "visited" links :( so I would very much appreciate it if you can help me with links to test the things you said about extended operations and request controls. I used many LDAP clients from ldap* commands to ldap browsers -webmin, softerra and couple more- I even tried ldap* command with -e ppolicy and although I couldn't figure the relation, it never gave me an error, they just got run as should they do. – user3464156 Feb 09 '16 at 11:36
  • Looks like you found the *man* pages for the ldap*.exe commands, and you should already have found *man slapo-ppolicy,* preferably both at at openldap.org. You should also have a good look at the [Zytrax book](http://zytrax.com/books/ldap/). I haven't found anything else online of much use. – user207421 Feb 10 '16 at 00:41
-1

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.

user3464156
  • 39
  • 1
  • 5
  • 1
    Setting `pwdReset=TRUE` in the user object can be done via the API or an LDAP browser. It doesn't lock the object. – user207421 Dec 05 '16 at 07:16