Bug 734267

Summary: upgradednformat failed to add RDN value - subtree and user account lockout policies implemented?
Product: Red Hat Enterprise Linux 6 Reporter: Noriko Hosoi <nhosoi>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: high Docs Contact:
Priority: urgent    
Version: 6.1CC: amsharma, benl, jgalipea, jwest, msauton, nhosoi, shaines
Target Milestone: rcKeywords: ZStream
Target Release: 6.2   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.2.9.8-1.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 732153 Environment:
Last Closed: 2011-12-06 17:56:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 732153    
Bug Blocks: 434915, 734945    

Description Noriko Hosoi 2011-08-29 23:22:14 UTC
+++ This bug was initially created as a clone of Bug #732153 +++

Description of problem:

Unless I am missing something, it seem not possible to add a subtree or user account lockout policies in 8.2, is it supposed to be an implemented feature, or I am missing some steps?

Not documented in
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_the_Password_Policy-Configuring_the_Account_Lockout_Policy.html

But the directory console allows a right click context menu selection to manage subtree or user, so it seem to be available, (was it working in 8.0?)

When using the directory console, when editing a subtree or user level account lockout policy, the save button stays grey, or if there are some change to the passwords policy, then it is possible to click on the Save button, but a popup error window appears with message "Operation not allowed on RDN", 
with access log:
[19/Aug/2011:22:45:25 -0700] conn=10 op=96 MOD dn="cn=cn\5c3DnsPwPolicyEntry\5c2Cou\5c3Dpeople\5c2Cdc\5c3Dexample\5c2Cdc\5c3Dcom,cn=nsPwPolicyContainer,ou=people,dc=example,dc=com"
[19/Aug/2011:22:45:25 -0700] conn=10 op=96 RESULT err=67 tag=103 nentries=0 etime=0

The QE tests at
http://mach1.idm.lab.bos.redhat.com/tet/testcases/DS/6.0/accPolicy/libs_accPolicy.sh
http://mach1.idm.lab.bos.redhat.com/tet/data/DS/6.0/accPolicy/
and
http://mach1.idm.lab.bos.redhat.com/tet/testcases/DS/6.0/testplans/accPolicy/AccntPolicy_TestPlan.html
seem to run global policy, no account lockout on subtree or user level fine grained policies.


Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux Server release 5.7 (Tikanga)
Linux ca1.example.com 2.6.18-274.el5 #1 SMP Fri Jul 8 17:36:59 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux
redhat-ds-base-8.2.6-1.el5dsrv


How reproducible:
always

Steps to Reproduce:
1. already have a global password policy, can have subtree and user level password policies
2. use either cli or directory console
3. with directory console, "Directory | example | people | right click | Manage Password policy | For subtree... | Account Lockout | check Accounts may be locked out | Lockout account after 10 login failures | Reset failure account after 10 minutes"
-> cannot save, button stays grey
4. select Passwords tab, change something, go back to "Account Lockout" tab, click Save
  
Actual results:

after step 3:
cannot save, button stays grey

after step 4:
popup window with title "Error Updating Directory" with message "Operation not allowed on RDN - OK"


Expected results:
subtree and user fine grained level for account lockout in nsPwPolicyContainer not just global in cn=config?
 

Additional info:

==> /var/log/dirsrv/slapd-ca1/access <==
[19/Aug/2011:22:45:25 -0700] conn=10 op=96 MOD dn="cn=cn\5c3DnsPwPolicyEntry\5c2Cou\5c3Dpeople\5c2Cdc\5c3Dexample\5c2Cdc\5c3Dcom,cn=nsPwPolicyContainer,ou=people,dc=example,dc=com"
[19/Aug/2011:22:45:25 -0700] conn=10 op=96 RESULT err=67 tag=103 nentries=0 etime=0


From an older test and notes I seem to have it working with 8.0, may have been cli only, not sure if the console was used:

# entry-id: 26
dn: cn="cn=nsPwPolicyEntry,ou=People,dc=mstest2",cn=nsPwPolicyContainer,dc=mst
 est2
passwordMaxFailure: 2
passwordUnlock: on
passwordResetFailureCount: 60
passwordLockoutDuration: 120
passwordLockout: on
passwordStorageScheme: ssha
passwordChange: off
passwordMinAge: 0
passwordHistory: off
passwordExp: off
passwordMustChange: off
modifyTimestamp: 20090825221850Z
createTimestamp: 20090825221850Z
modifiersName: cn=directory manager
creatorsName: cn=directory manager
cn: "cn=nsPwPolicyEntry,ou=People,dc=mstest2"
objectClass: ldapsubentry
objectClass: passwordpolicy
objectClass: top
nsUniqueId: 2a2ef982-91c511de-ab1fbc42-a01af143


with 8.1 and 8.2, global account lockout configured:

ldapmodify -x -D "cn=directory manager" -w password -h 10.14.5.22 -p 389
dn: cn="cn=nsPwPolicyEntry,uid=guest2,ou=people,dc=example,dc=com",cn=nsPwPolicyContainer,ou=people,dc=example,dc=com
changetype: modify
add: passwordMaxFailure 
passwordMaxFailure: 2
-
add: passwordUnlock 
passwordUnlock: on
-
add: passwordResetFailureCount    
passwordResetFailureCount: 60
-
add: passwordLockoutDuration     
passwordLockoutDuration: 120
-
add: passwordLockout    
passwordLockout: on

modifying entry "cn="cn=nsPwPolicyEntry,uid=guest2,ou=people,dc=example,dc=com",cn=nsPwPolicyContainer,ou=people,dc=example,dc=com"
ldap_modify: Operation not allowed on RDN (67)


same for
cn="cn=nsPwPolicyEntry,ou=people,dc=example,dc=com",cn=nsPwPolicyContainer,ou=people,dc=example,dc=com

[...]

--- Additional comment from rmeggins on 2011-08-23 18:38:38 EDT ---

This is an 8.1 to 8.2 upgrade issue.  The problem is that with 8.1 (or earlier) the cn value was added with quotes, but that does not match the DN value which does not have double quotes:
dn: cn=cn\3DnsPwPolicyEntry\2Cou\3Dpeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPol
 icyContainer,ou=people,dc=example,dc=com
...
cn: "cn=nsPwPolicyEntry,ou=people,dc=example,dc=com"

The code in ldbm_back_modify attempts to see if a modify op has removed the RDN value.  It looks for a value of cn: cn=nsPwPolicyEntry,ou=people,dc=example,dc=com in the entry and doesn't find it because the value is actually double quoted in the entry.

The workaround is to use ldapmodify to add the value without quotes to the entry:

ldapmodify .... << EOF
dn: cn=cn\3DnsPwPolicyEntry\2Cou\3Dpeople\2Cdc\3Dexample\2Cdc\3Dcom,cn=nsPwPol
 icyContainer,ou=people,dc=example,dc=com
changetype: modify
add: cn
cn: cn=nsPwPolicyEntry,ou=people,dc=example,dc=com
EOF

--- Additional comment from msauton on 2011-08-25 19:07:16 EDT ---

the simple workaround works as expected.

--- Additional comment from nhosoi on 2011-08-25 21:37:43 EDT ---

Created attachment 520000 [details]
git patch file (master)

Description: Upgradedbformat utility converts old dn format to
new one.  It's called at the in-place upgrade time.  The utility
failed to check if the normalized RDN value is in the entry's
attribute list.  This patch properly checks it.  If the value
does not exist, it adds the normalized value to the entry.

--- Additional comment from rmeggins on 2011-08-29 14:54:54 EDT ---

Comment on attachment 520000 [details]
git patch file (master)

This seems quite complex - is there some reason you can't just use slapi_entry_add_rdn_values or extend/alter that function to suit your needs?

--- Additional comment from nhosoi on 2011-08-29 19:15:54 EDT ---

Created attachment 520483 [details]
git patch file (master)

Thanks to Rich for his comments.  By using the API slapi_entry_add_rdn_values, the patch could get simplified.

Comment 1 Noriko Hosoi 2011-08-30 17:32:53 UTC
For the steps to verify, see the upstream bug: 732153.

Comment 6 Amita Sharma 2011-09-22 10:40:36 UTC
As clone https://bugzilla.redhat.com/show_bug.cgi?id=732153 is Verified, marking this as VERIFIED.

Comment 7 errata-xmlrpc 2011-12-06 17:56:17 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHEA-2011-1711.html