Bug 268101

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

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

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

Per bug council on 08/31/2007 - setting screened+ flag

per bug council on 08/31/2007, setting target DS8.0

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?

I am able to reproduce this issue by doing a replace of the userpassword
attribute using ldapmodify with no password policy defined.

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.

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.

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