#620 Better logging of error messages for 389-ds-base
Closed: Fixed None Opened 6 years ago by nkinder.

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]:

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?

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.

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

2 years ago

Login to comment on this ticket.

Metadata