-
Notifications
You must be signed in to change notification settings - Fork 36
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
LDAP Bind #86
Comments
Hi @shep2644 , As the wiki for Generate Unique Value Activity mentions, "All queries are executed under the context of the FIMService account." So unless the director allows access to MIMService account (unlikely if the Directory does not support AD authentication) or anonymous access (which would be unlikely for a production system), this is not going to work. |
Our directory does support anonymous bind. Also, our dev, which is the same as prod, can connect to the directory. That's what's so odd. |
Anonymous bind does not mean anonymous access to search anything in the directory. This thread may be helpful https://community.oracle.com/thread/2011892 |
Thank you Nilesh. I appreciate your assistance. We got it figured out. We compiled a custom version of MIMWAL that hardcoded the ldap credentials for the bind. Again, thank you for your assistance. |
Hardcoding is a bad idea. You should look at updating the UI and the activity to take in the creds like RunPowerShell activity does and then send a pull request for MIMWAL. |
Definitely recommend doing as Nilesh says. You'll not only be able to support MIM easier internally as no developer changes will be required when your creds get changed, plus you'll also have the benefit of being able to update your MIMWAL as we release new versions. |
We have two instances of MIM using MIMWAL. One instance is dev and one is prod. The dev system, when making an anonymous bind to SunDS, will perform a bind and search the directory. On the other hand, the production system will not.
What we see is an error in our production MIM that states "The username or password are incorrect" . When using Wire Shark, we don't even see a bind. Below are the results from wireshark. Both instances of MIM are running version 2.19..0112.0
The text was updated successfully, but these errors were encountered: