bind is doing a search for the entry post bind, which fails because we don't enable password policy chaining by default. I think in this case, we should not look up password policy, because if the remote is AD or some other non-389 server, we can't use the password policy information. We should instead rely on the remote server to evaluate the password policy.
This code should not run if using a remote_db:
/* * There could be a race that bind_target_entry was not added * when bind_target_entry was retrieved before be_bind, but it * was in be_bind. Since be_bind returned SLAPI_BIND_SUCCESS, * the entry is in the DS. So, we need to retrieve it once more. */ if (!bind_target_entry) { bind_target_entry = get_entry(pb, slapi_sdn_get_ndn(sdn)); ...
That is
if (! slapi_be_is_flag_set(be, SLAPI_BE_FLAG_REMOTE_DATA)) {
I think this problem is a regression introduced by 4fc53e1 and 4f11606
The user reported that doing {{{ ldapmodify ... <<EOF dn: cn=config,cn=chaining database,cn=plugins,cn=config changetype: modify add: nsActiveChainingComponents nsActiveChainingComponents: cn=password policy,cn=components,cn=config EOF }}} was able to work around the problem. But we should not be doing the search at all for a remote db.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1219990
git patch file (adminserver master) -- a diff provided by Rich (Thank you!!) 0001-Ticket-48183-bind-on-db-chained-to-AD-returns-err-32.patch
I think I'm eligible to set "ack"? :)
And is this setting to be configured by default? https://fedorahosted.org/389/ticket/48183#comment:1
Can we have a reproducer? Is it "must" to send a bind request from a Windows machine?
Pushed to master: 513393b..eb46e6f master -> master commit eb46e6f
Pushed to 389-ds-base-1.3.3: 9ba030f..03bee0a 389-ds-base-1.3.3 -> 389-ds-base-1.3.3 commit 03bee0a
Pushed to 389-ds-base-1.3.2: 31f7311..46242d8 389-ds-base-1.3.2 -> 389-ds-base-1.3.2 commit 46242d8
Pushed to 389-ds-base-1.2.11: fd427d1..164cb24 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit 164cb24
Metadata Update from @nhosoi: - Issue set to the milestone: 1.2.11.33
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/1514
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.