New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bind on db chained to AD returns err=32 #1514
Comments
Comment from rmeggins (@richm) at 2015-05-09 03:10:01 The user reported that doing
was able to work around the problem. But we should not be doing the search at all for a remote db. |
Comment from nhosoi (@nhosoi) at 2015-05-09 04:46:09 Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1219990 |
Comment from nhosoi (@nhosoi) at 2015-05-11 04:16:37 git patch file (adminserver master) -- a diff provided by Rich (Thank you!!) |
Comment from nhosoi (@nhosoi) at 2015-05-11 04:22:34 I think I'm eligible to set "ack"? :) And is this setting to be configured by default? Can we have a reproducer? Is it "must" to send a bind request from a Windows machine? |
Comment from nhosoi (@nhosoi) at 2015-05-27 00:43:30 Pushed to master: Pushed to 389-ds-base-1.3.3: Pushed to 389-ds-base-1.3.2: Pushed to 389-ds-base-1.2.11: |
Comment from nhosoi (@nhosoi) at 2017-02-11 22:58:56 Metadata Update from @nhosoi:
|
Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/48183
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:
That is
I think this problem is a regression introduced by 4fc53e1 and 4f11606
The text was updated successfully, but these errors were encountered: