Currently (as of version 2.0.0.M7), EmbeddedLdapAutoConfiguration isn't properly setting the base information from LdapContextSource using the value from spring.ldap.embedded.base-dn.
Because of that, we can't test our @repository classes using an embedded LDAP server without overriding this bean unless if we want to set the whole path for each @Entry.
I would suggest the following change inside of org.springframework.boot.autoconfigure.ldap.embedded.EmbeddedLdapAutoConfiguration#ldapContextSource:
@Bean
@DependsOn("directoryServer")
@ConditionalOnMissingBean
public ContextSource ldapContextSource() {
LdapContextSource source = new LdapContextSource();
if (hasCredentials(this.embeddedProperties.getCredential())) {
source.setUserDn(this.embeddedProperties.getCredential().getUsername());
source.setPassword(this.embeddedProperties.getCredential().getPassword());
}
source.setBase(this.embeddedProperties.getBaseDn()); // Add this line.
source.setUrls(this.properties.determineUrls(this.environment));
return source;
}
This issue was already reported in the issue #10443 which was closed without fixing the problem.
Comment From: snicoll
This issue was already reported in the ticket #10443 which was closed without fixing the problem.
That's inaccurate. #10443 has been closed as a duplicate of #10444 and the latter has been declined.
Comment From: vdubus
Ok, so because PR #10444 was made to fix Issue #10443, you closed the issue as a duplicate of the PR. Then, you closed PR #10444 which isn't progressing since then. And now you closed this ticket which report back the problem as a bug. Meaning that there isn't even an opened ticket to signal the bug.
Would you mind reopening at least one ticket so that someone could find it and try working on it? Unless there is another opened ticket of which I am unaware?
Comment From: snicoll
Then, you closed PR #10444 which isn't progressing since then.
It hasn't progressed because the proposal was unsatisfactory. But you're right, looking back at the history, we could use a report for this. Let's use this one then.
Comment From: tgeens
The original change proposed here no longer cleanly applies after the changes in https://github.com/spring-projects/spring-boot/pull/11764/files - EmbeddedLdapProperties.getBaseDn() now returns a list, while LdapContextSource.setBase(base) expects a string
Comment From: eddumelendez
LdapContextSource supports just one base so I think the support for multiple base should be handle manually. It means create more LdapContextSource and LdapTemplate.
Comment From: snicoll
As discussed at length in the PR, I don't see any good solution to handle this as we support multi-base DNs. And configuring the base if one is set is asking for trouble IMO as it would change the behaviour as soon as you add a second base (which is a use case we support now). If I've misunderstood something, we can reevaluate this if someone as another proposal for this issue (PR welcome).
Comment From: ncgisudo
Dredging up a dead thread, but I thought I'd try this first before raising it as a separate new issue because I think the issues that this one links to has/explains valuable history. Please say if you'd rather I did start a new thread.
The issues described in this thread, plus all the linked/associated threads, have never actually gotten fixed. With regards to the multi-base DNs, I would say that supporting the "basic" scenario of a single base DN would likely support the majority of use cases (people using it in unit tests, against representations of their domains that likely only have one base DN).
At any rate - as it stands right now I believe there is still an issue either way because the application properties documentation states that this property exists yet it is actually ignored: https://docs.spring.io/spring-boot/docs/current/reference/html/application-properties.html#application-properties.data.spring.ldap.embedded.base-dn
Comment From: philwebb
At any rate - as it stands right now I believe there is still an issue either way because the application properties documentation states that this property exists yet it is actually ignored:
@ncgisudo The spring.ldap.embedded.base-dn should be read and passed to InMemoryDirectoryServerConfig (see EmbeddedLdapAutoConfiguration). If you're having a problem with that could you please open a new issue and provide a sample application that shows the problem.
Comment From: ncgisudo
It is indeed passed to InMemoryDirectoryServerConfig in class EmbeddedLdapAutoConfiguration,
However this class (or rather, the inner class class EmbeddedLdapContextConfiguration) provides the matching LdapContextSource Bean. It is in this bean that the DN is not set, which means that all operations against this context do not include the base DN.
Comment From: ncgisudo
I won't be able to do it today, but I'll get a sample app made and a new ticket raised and link it back here.