Description of problem:

Currently IPA implements a number of plugins for 389ds that are involved in processing various LDAP operations eg LDAP bind. These plugins can fail specific operations based on their internal logic and state but provide no visibility in terms or logging and tracing that they fail specific operations and why they fail them. They also provide incorrect and misleading LDAP result codes to LDAP clients, making for a high complexity troubleshooting and high support costs.

For example ipa-extop-pwd plugin has pre bind hook that default to LDAP_INVALID_CREDENTIALS result code and sending LDAP result by itself (instead of letting 389ds do it) which can silently fail any bind op with "invalid credentials" response even tho the real reason for pre bind fail in this plugin is IPA's ipauserauthtype not configured for password auth. Such failure leaves no useful information in the server logs (even at the highest level of logging/tracing) and misleads end users and support wrt the real cause of the failure.

Another example is schema compat plugin which again has bind hooks and will return LDAP_INVALID_CREDENTIALS result code and LDAP result by itself even tho the real reason for the failure is that it is impossible to perform a bind against mapped entries. Again, such failure leaves no useful information in the server logs (even at the highest level of logging/tracing) and misleads end users and support wrt the real cause of the failure.

The only information available in the logs is the fact that those plugins are being invoked so it is possible to isolate them one by one and pinpoint where the failure is coming from and then take a guess as to why.

Expected results:

These plugins should:

1) Return a more appropriate LDAP result codes eg UNWILLING_TO_PERFORM, accompanied by a meaningful error message to tell LDAP client what went wrong.

2) Log messages to the server logs eg at PLUGIN level so that such failures (and successes as well) can be traced if needed.

3) If feasible avoid sending LDAP results directly and rely on the server to send them instead as this should result in better plugin level tracing/logging on the server side.

Additional info:

The 2 plugins above are just examples as they related to bind operations. I'm sure there are others related to different operations that can benefit from similar tracing/logging improvements so the scope here should not be limited to these 2 and bind ops specifically.