389-ds-base

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

Closed: wontfix
Reopen Issue

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 4fc53e1a and 4f11606b

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 eb46e6f1975b19956bb38d5e070e6eb5159200b4

Pushed to 389-ds-base-1.3.3:
9ba030f..03bee0a 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 03bee0a0d4dbe313bca88cfafc605f6cb01b9fdc

Pushed to 389-ds-base-1.3.2:
31f7311..46242d8 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 46242d88b62716d99641eceac26476a9c842c149

Pushed to 389-ds-base-1.2.11:
fd427d1..164cb24 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 164cb2460538d63ee2b2cde3e28323e51dc9741c

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.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)
Metadata
None
None
None
None
Normal
ack
Community
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.