Thanks Clement and Guillaume for your reply.
This is my operational attributes for my user:
dn: cn=user1,ou=policies,dc=samle,dc=com
objectClass: pwdPolicy
objectClass: top
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
cn: user1
pwdAttribute: userPassword
sn: user1
uid: user1
pwdAllowUserChange: TRUE
pwdExpireWarning: 10
pwdLockout: TRUE
pwdMaxAge: 15
pwdMustChange: TRUE
Guillaume:
I know that my access configuration is dangereous but how I am testing I
just want to be sure don't block anything.
If I understood your concept I can't use pwdPolicy for unix account. Is
there any way to control password history with shadowAccount?..
Thanks!
On 08/29/2012 01:14 PM, Guillaume Rousse wrote:
Le 29/08/2012 17:39, cbulist a écrit :
Hi,
I got stuck with this problem. I'm able to change the user password
using shadowAccount objectClass but I can't do the same using pwdPolicy
objectClass.
It doesn't means anything: you don't change attributes using a object
class. Morevoer, you seem to be confusing two different concepts:
The shadowAccount object class is just a placeholder for unix-specific
attributes, that will get used client side by some specific ldap
clients, such as pam_ldap for instance. It is supposed to be used for
user entries, already instances of posixAccount object class.
The pwdPolicy object class is a placeholder for ldap-specifics
attributes, that will get honored on server side. It is supposed to be
the main class of a password policy entry, to be applied on user entries.
I set ppolicy attribute in order to get the password
expired message:
pwdExpireWarning 10
pwdMaxAge 15
pwdMustChange TRUE
pwdAllowUserChange TRUE
pwdLockout TRUE
On which object ?
slapd.conf:
include /etc/openldap/schema/ppolicy.schema
moduleload ppolicy.la
access to attrs=userPassword
by self write
by users read
by anonymous auth
This is a quite dangereous setting, and defeat the whole purpose of
shadow passwords: all users can read other users password hashes.
