Bug 268101

Summary: modifiername always 'cn=server,cn=plugins,cn=config' in Directory Server
Product: Red Hat Directory Server Reporter: Issue Tracker <tao>
Component: Directory ServerAssignee: Nathan Kinder <nkinder>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: high    
Version: 7.1CC: tao
Target Milestone: DS8.0Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-05-06 14:34:14 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 240316    
Description Flags
CVS Diffs none

Description Issue Tracker 2007-08-30 17:16:25 UTC
Escalated to Bugzilla from IssueTracker

Comment 1 Issue Tracker 2007-08-30 17:16:27 UTC
Description of problem:

A customer is using a Directory Server to store their user information. He wrote a perl script to allow one user to bind the DS with the user own identity and change his password.

The script operated successfully. But the "modifiername" field of the user in DS would become "cn=server,cn=plugins,cn=config". . Because the user would bind dn by his own identity, the customer expect the modifiername should be the uid of the user himself. 

And the customer said this behaviour is shown on his old LDAP server. 

How reproducible:


Steps to Reproduce:

1. Start a DS
2. Create a user in it
3. Use the customer's script to change the user password
4. Check the modifiername

Actual results:

modifiername is "cn=server,cn=plugins,cn=config"

Expected results:

modifiername should be the user id e.g."uid=xxx,ou=People,..."

Additional info:

I can understand this may be the current behaviour of DS. If yes, please explain why it is happened and why the customer expected way is feasible. Or provide workaround.
This event sent from IssueTracker by ble  [SEG - Directory Server Engineering]
 issue 130125

Comment 2 Issue Tracker 2007-08-30 17:16:28 UTC
The customer would like to know,
1. If he can disable all the password policy,
2. such that the modifiersname is the uid instead of cn=server?

I try to disable the password policy in the Admin console (unclick
"Enable fine-grained password policy"), but the modifiersname would
still be "cn=server..." when user change password. I wonder if ther are
some password policy I haven't disabled, or there are some policy that
can't be disabled by configuration.

This event sent from IssueTracker by ble  [SEG - Directory Server
 issue 130125

Comment 3 Issue Tracker 2007-08-30 17:16:29 UTC
I just run some tests in the lab. Disable all the password policy and use
ldapmodify command to change user password, the modifiername is still
"cn=server,cn=...". i think when the user changes their password, the
other operations are done via internal modify operations, which usually
use the cn=server "pseudo" user ID.
I will file a bug (RFE) for this issue.

This event sent from IssueTracker by ble  [SEG - Directory Server
 issue 130125

Comment 4 Chandrasekar Kannan 2007-09-04 13:27:06 UTC
Per bug council on 08/31/2007 - setting screened+ flag

Comment 5 Chandrasekar Kannan 2007-09-04 13:40:16 UTC
per bug council on 08/31/2007, setting target DS8.0

Comment 6 Nathan Kinder 2007-10-04 17:34:38 UTC
How is the password being changed?  Is the password extended modify operation
being used, or are you simply doing a replace of the userPassword attribute?

Comment 7 Nathan Kinder 2007-10-04 20:52:28 UTC
I am able to reproduce this issue by doing a replace of the userpassword
attribute using ldapmodify with no password policy defined.

Comment 8 Nathan Kinder 2007-10-05 22:16:56 UTC
The problem is caused by the password policy related attribute updates.

The password policy related attributes are handled by a separate internal modify
operation that happens after the actual password operation that is performed by
the user.  The problem is that an internal modify operation will always update
the modifiersname (and other related attributes) using the plugin's DN unless it
is a replicated operation.

It should also be noted that the password grace period attribute is always
reset, even when no grace period policy is being enforced.  This explains why
the issue was being seen with password policy disabled.

Comment 9 Nathan Kinder 2007-10-05 22:25:03 UTC
Created attachment 218131 [details]
CVS Diffs

The slapi_internal_modify_set_pb() function allows you to pass in operation
flags to set when the operation is created in the pblock.  This fix takes
advantage of this capability by defining a new operation flag to skip updating
the modified attributes (modifiersname, modifiedtimestamp, etc.).

I then added support for checking if this flag is set in slapi_pblock_get(). 
We will set this flag for the password policy related internal operations.  We
can then check if this flag is set in op_shared_modify() to avoid updating the
attributes.  This new operation flag may come in handy for other cases where we
want to preserve the modifiersname when performing internal modify operations.

Comment 10 Nathan Kinder 2007-10-05 23:31:44 UTC
Checked into ldapserver (HEAD).  Thanks to Rich and Noriko for their reviews!

Checking in modify.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/modify.c,v  <--  modify.c
new revision: 1.15; previous revision: 1.14
Checking in pblock.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/pblock.c,v  <--  pblock.c
new revision: 1.11; previous revision: 1.10
Checking in pw_retry.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/pw_retry.c,v  <--  pw_retry.c
new revision: 1.7; previous revision: 1.6
Checking in slapi-plugin.h;
/cvs/dirsec/ldapserver/ldap/servers/slapd/slapi-plugin.h,v  <--  slapi-plugin.h
new revision: 1.19; previous revision: 1.18
Checking in slapi-private.h;
/cvs/dirsec/ldapserver/ldap/servers/slapd/slapi-private.h,v  <--  slapi-private.h
new revision: 1.17; previous revision: 1.16
Checking in ssl.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/ssl.c,v  <--  ssl.c
new revision: 1.14; previous revision: 1.13