Description of problem: When getting rejected based on replicated password policy, better logging would make troubleshooting the issue a lot easier.
Steps to Reproduce: 1. Setup 2 masters 2. Enable password lockout and set "passwordIsGlobalPolicy: on" on only one master. 3. Attempt to bind with an invalid password on the master that has passwordIsGlobalPolicy set to on.
Actual results: The replicated update of of the password retry counter will be rejected by the receiving side with an "unwilling to perform" error. Replication level logs will not indicate anything more helpful.
Expected results: The logs should say something more helpful, such as "Rejecting replicated password policy operation. To allow these changes to be accepted, set passwordIsGlobalPlocy to 'on'."
Your fix on the logging looks good. I have one question regarding the returning error message. The following message is returned to each client? Assuming it, the ordinary user is not allowed to do the operation to "set passwordIsGlobalPolicy to 'on' in cn=config"... Also, the information might look a bit tricky to share among end users... Maybe, more generic "ask administrator" type of message would be preferable? {{{ 66 int op_shared_is_allowed_attr (const char attr_name, int replicated_op) 66 int op_shared_is_allowed_attr (const char attr_name, int replicated_op, char errtxt) 67 67 { [...] 106 106 / this attribute is not allowed / 107 *errtxt = "Rejecting replicated password policy operation. To " 108 "allow these changes to be accepted, set " 109 "passwordIsGlobalPolicy to 'on' in cn=config."; }}}
Replying to [comment:4 nhosoi]:
Your fix on the logging looks good. I have one question regarding the returning error message. The following message is returned to each client? Assuming it, the ordinary user is not allowed to do the operation to "set passwordIsGlobalPolicy to 'on' in cn=config"... Also, the information might look a bit tricky to share among end users... Maybe, more generic "ask administrator" type of message would be preferable?
Good point, in fact maybe we should just leave the client message empty(like it was), and only report the message in the error log. Clients should not be trying to do this anyway, and that message is only reported in a replication session. So I guess it's really not needed in the client result. Thoughts?
{{{ 66 int op_shared_is_allowed_attr (const char attr_name, int replicated_op) 66 int op_shared_is_allowed_attr (const char attr_name, int replicated_op, char errtxt) 67 67 { [...] 106 106 / this attribute is not allowed / 107 *errtxt = "Rejecting replicated password policy operation. To " 108 "allow these changes to be accepted, set " 109 "passwordIsGlobalPolicy to 'on' in cn=config."; }}}
Replying to [comment:5 mreynolds]:
I agree that the client message is not really needed. It's probably best to just log it on the system where the config change is needed.
revision 0001-Ticket-620-Better-logging-of-error-messages-for-389-.patch
Agreed, client message removed. Pushed
git merge ticket620 Updating ac8ceb9..a4c4daa Fast-forward ldap/servers/slapd/modify.c | 46 ++++++++++++++++++++++++++---------------- 1 files changed, 28 insertions(+), 18 deletions(-)
git push origin master Counting objects: 11, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 1.25 KiB, done. Total 6 (delta 4), reused 0 (delta 0) To ssh://git.fedorahosted.org/git/389/ds.git ac8ceb9..a4c4daa master -> master
Metadata Update from @mreynolds: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.1
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/620
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.