Bug 268101 - modifiername always 'cn=server,cn=plugins,cn=config' in Directory Server
modifiername always 'cn=server,cn=plugins,cn=config' in Directory Server
Status: CLOSED CURRENTRELEASE
Product: Red Hat Directory Server
Classification: Red Hat
Component: Directory Server (Show other bugs)
7.1
All Linux
high Severity medium
: DS8.0
: ---
Assigned To: Nathan Kinder
Viktor Ashirov
: FutureFeature
Depends On:
Blocks: 240316
  Show dependency treegraph
 
Reported: 2007-08-30 13:16 EDT by Issue Tracker
Modified: 2016-05-06 10:34 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-06 10:34:14 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 (9.31 KB, patch)
2007-10-05 18:25 EDT, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Issue Tracker 2007-08-30 13:16:25 EDT
Escalated to Bugzilla from IssueTracker
Comment 1 Issue Tracker 2007-08-30 13:16:27 EDT
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:

Always.

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 13:16:28 EDT
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
Engineering]
 issue 130125
Comment 3 Issue Tracker 2007-08-30 13:16:29 EDT
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
Engineering]
 issue 130125
Comment 4 Chandrasekar Kannan 2007-09-04 09:27:06 EDT
Per bug council on 08/31/2007 - setting screened+ flag
Comment 5 Chandrasekar Kannan 2007-09-04 09:40:16 EDT
per bug council on 08/31/2007, setting target DS8.0
Comment 6 Nathan Kinder 2007-10-04 13:34:38 EDT
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 16:52:28 EDT
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 18:16:56 EDT
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 18:25:03 EDT
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 19:31:44 EDT
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
done
Checking in pblock.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/pblock.c,v  <--  pblock.c
new revision: 1.11; previous revision: 1.10
done
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
done
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
done
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
done
Checking in ssl.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/ssl.c,v  <--  ssl.c
new revision: 1.14; previous revision: 1.13
done

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