Bug 216522 - password change extop doesn't respect local pwp
password change extop doesn't respect local pwp
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Security - Password Policy (Show other bugs)
1.0.4
All All
high Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
Depends On:
Blocks: 152373 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2006-11-20 17:25 EST by Ulf Weltman
Modified: 2015-01-04 18:21 EST (History)
4 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 18:59:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CVS Diffs (3.26 KB, patch)
2008-11-21 17:12 EST, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Ulf Weltman 2006-11-20 17:25:18 EST
As reported by Philip Kime on fedora-directory-users, local pwp doesn't apply
for password change extended operation.

Effective policy is determined by new_passwdPolicy() which considers the
modification initiated by the password change extop to be internal and local
policy is not retrieved.
Comment 4 Nathan Kinder 2008-11-21 14:17:45 EST
To reproduce/verify:

- Setup a single DS instance.
- Perform the following modifications to enable password policies and add a
  test user:

  dn: cn=config
  changetype: modify
  replace: passwordCheckSyntax
  passwordCheckSyntax: on
  -
  replace: nsslapd-pwpolicy-local
  nsslapd-pwpolicy-local: on
  -
  replace: passwordStorageScheme
  passwordStorageScheme: CLEAR

  dn: uid=user1,dc=example,dc=com
  changetype: add
  uid: user1
  objectclass: inetorgperson
  cn: user 1
  sn: 1
  userPassword: Secret12

- Add the local policy container:

  /usr/lib/dirsrv/slapd-example/ns-newpwpolicy.pl -w <DM password> -U \
  "uid=user1,dc=example,dc=com"

- Adjust to local policy to require passwords of at least 10 characters:

  dn: cn="cn=nsPwPolicyEntry,uid=user1,dc=example,dc=com",
   cn=nsPwPolicyContainer,dc=example,dc=com
  changetype: modify
  replace: passwordCheckSyntax
  passwordCheckSyntax: on
  -
  replace: passwordMinLength
  passwordMinLength: 10
  -
  replace: passwordChange
  passwordChange: on

- Attempt to make an illegal password change using ldapmodify:

  [nkinder@localhost tests]$ ldapmodify -Y DIGEST-MD5 -U user1 -w Secret12 -h \
  localhost -p 389
  SASL/DIGEST-MD5 authentication started
  SASL username: user1
  SASL SSF: 128
  SASL data security layer installed.
  dn: uid=user1,dc=example,dc=com
  changetype: modify
  replace: userPassword
  userPassword: Secret23

  modifying entry "uid=user1,dc=example,dc=com"
  ldap_modify: Constraint violation (19)
        additional info: invalid password syntax - password must be at least 10
        characters long

- Attempt to make an illegal password change using ldappasswd:

  [nkinder@localhost tests]$ ldappasswd -Y DIGEST-MD5 -U user1 -w Secret12 -h \
  localhost -p 389 "uid=user1,dc=example,dc=com" -s Secret23
  SASL/DIGEST-MD5 authentication started
  SASL username: user1
  SASL SSF: 128
  SASL data security layer installed.

The password change using ldapmodify will fail, as it should since it violates the minimum length requirement in the local policy.  The same password change made with ldappasswd will suceed, even though it should fail, since it is incorrectly using the global policy which allows 8 character passwords.
Comment 5 Nathan Kinder 2008-11-21 17:12:12 EST
Created attachment 324353 [details]
CVS Diffs

When choosing between the global and local password policies, we should always choose the local policy if one applies, regardless of the operation being internal or not.  This fix simply makes us check for local policies for internal operations.

A change was needed with where we fetch the policy when we are returning a result.  We used to always fetch a policy, even though we only needed it when we were dealing with an error 49.  This was causing us to infinitely recurse with the above change for fetching local policies for internal operations.  The password policy code would perform an internal search for the local policy container, which would trigger the policy to be looked up again when we return the result for the internal operation.  Since we only need to fetch the policy at result time for an error 49, I changed the code to only fetch the policy in this case.  This case will never be true for an internal operation since we don't need to provide a bind DN or password.
Comment 6 Nathan Kinder 2008-11-24 12:17:22 EST
Checked into ldapserver (HEAD).  Thanks to Noriko for her review!

Checking in ldap/servers/slapd/pw.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/pw.c,v  <--  pw.c
new revision: 1.19; previous revision: 1.18
done
Checking in ldap/servers/slapd/result.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/result.c,v  <--  result.c
new revision: 1.17; previous revision: 1.16
done
Comment 7 Jenny Galipeau 2009-03-19 08:57:40 EDT
fix verified - RHEL 5 - DS 8.1

[root@jennyv2 jenny]# ldapmodify -Y DIGEST-MD5 -U user1 -w Secret12 -h `hostname` -p 389
SASL/DIGEST-MD5 authentication started
SASL username: user1
SASL SSF: 128
SASL installing layers
dn: uid=user1,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: Secret23 

modifying entry "uid=user1,dc=example,dc=com"
ldapmodify: Constraint violation (19)
	additional info: invalid password syntax - password must be at least 10 characters long

[root@jennyv2 jenny]# ldappasswd -Y DIGEST-MD5 -U user1 -w Secret12 -h `hostname` -p 389 "uid=user1,dc=example,dc=com" -s Secret23
SASL/DIGEST-MD5 authentication started
SASL username: user1
SASL SSF: 128
SASL installing layers
Result: Constraint violation (19)
Additional info: Failed to update password
Comment 8 Chandrasekar Kannan 2009-04-29 18:59:36 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html

Note You need to log in before you can comment on or make changes to this bug.