#48183 bind on db chained to AD returns err=32
Closed: wontfix None Opened 5 years ago by rmeggins.

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.

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

3 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

6 days ago

Login to comment on this ticket.

Metadata