spring-ldap | Spring LDAP is a library to simplify LDAP | Application Framework library

Spring 3.2.0.RELEASE uses asm 4.0, which does not support Java 8 or higher.

Since Java 7 is not supported any more, you should upgrade Spring to the latest patch release:

• There is an issue with the second condition in the group search filter, it should be (uniqueMember={0}) (the cn= is part of the substituted dn). Also, the (cn=*) is not necessary because cn is a mandatory attribute for all groupOfUniqueNames entries.

• Since the context source url contains a base DN (dc=example,dc=org) used for searching and authenticating users, you don't need to set this part in the user/group search parameters (which are relative to that base).

• userSearchFilter() is not necessary when using userDnPatterns (@see this post)

OK. So after spending lot of times I got solutions.

First of all, there is nothing wrong with the code snippet mentioned above, reason of this error is-

Accroding to spring security doc under section 18.4.4, In case of active directory search, after authenticating the user successfully, the LdapAuthenticationProvider will attempt to load a set of authorities for the user by calling the configured LdapAuthoritiesPopulator bean. The DefaultLdapAuthoritiesPopulator is an implementation which will load the authorities by searching the directory for groups of which the user is a member (typically these will be groupOfNames or groupOfUniqueNames entries in the directory).

If you want to use LDAP only for authentication, but load the authorities from a difference source (such as a database) then you can provide your own implementation of this interface and inject that instead.

But I was ignoring the authorities which was returning after successfull authentication of the user, that is why I was getting this error.

There are few ways to solve the problem:

1st Way: using Context.REFERRAL to follow

Disadvantage: it will take lot of time to follow the referral and authenticate user

2nd Way: By implementing LdapAuthoritiesPopulator

CustomAuthoritiesPopulator.java

The solution in my case was the spring-boot-starter-version in pom.xml. This one had to be 2.3.12.RELEASE (https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-parent).

This takes what I've learned over the weekend and applies it as an answer to my own question. I'm still not an expert in this so I welcome more experienced answers or comments.

First, I still don't know for certain if I need the @EnableLdapRepositories annotation. I don't yet make use of those features, so I can't say if not having it matters, or if Spring Boot 2 is still taking care of that automatically. I suspect Spring Boot 2 is, but I'm not certain.

Second, Spring Boot's autoconfigurations all happen after any user configurations, such as my code configuring a second LDAP data source. The autoconfiguration is using a couple of conditional annotations for whether or not it runs, based on the existence of a context source or an LdapTemplate.
This means that it sees my "second" LDAP context source (the condition is just that a context source bean exists, regardless of what its name is or what properties it is using) and skips creating one itself, meaning that I no longer have that piece of my primary data source configured.
It will also see my "second" LdapTemplate (again, the condition is just that an LdapTemplate bean exists, regardless of what its name is or what context source or properties it is using) and skip creating one itself, so I again no longer have that piece of my primary data source configured.
Unfortunately, those conditions mean that in this case there is no in-between either (where I can manually configure the context source, for example, and then allow the autoconfiguration of the LdapTemplate to still happen). So the solution is to either make my configuration run after the autoconfiguration, or to not leverage the autoconfiguration at all and set them both up myself.

As for making my configuration run after the autoconfiguration: the only way to do that is to make my configuration an autoconfiguration itself and specify its order to be after Spring's built-in autoconfiguration (see: https://stackoverflow.com/a/53474188/3669288). That's not appropriate for my use case, so for my situation (because Spring Boot's setup does make sense for a standard single-source situation) I'm stuck forgoing the autoconfiguration and setting them both up myself.

Setting up two data sources is pretty well covered in the following two answers (though partly for other reasons), as linked in my question, but I'll also detail my setup here.
Can a spring ldap repository project access two different ldap directories?
Multiple LDAP repositories with Spring LDAP Repository

First up, the configuration class needs to be created, as one was not previously needed at all with Spring Boot 2. Again, I left out the @EnableLdapRepositories annotation partly because I don't use it yet, and partly because I think Spring Boot 2 will still cover that for me. (Note: All of this code was typed up in the Stack Overflow answer box as I don't have a development environment where I'm writing this, so imports are skipped and the code may not be perfectly compilable and function correctly, though I hope it's good.)

Well, sometimes it's more important to ask the right question than to have the right answer. It turns out that Spring Boot will not automatically detect XML configuration, and you have to do that manually. That's easy to do by adding the @ImportResource annotation to your main class. You change this:

This might have to do with you not using Generics with your java Collections

And that prints -> Central European Standard Time

Why are you doing this? "Calendar" as an API is broken and obsolete, do not use it. 'Central European Standard Time' is a weird concept that probably you don't want at all. It is a broken concept you need to get rid of.

The EU has already decided that the EU as a whole is going to ditch the concept of daylight savings time entirely, but there is no actual requirement for each EU country to go to the same time zone. This means a few things:

1. It's always been an idiotic standard; There is 'Central European Standard Time' (UTC+1), and 'Central European Summer Time' (UTC+2), which both shorten to CEST, but in common parlance, 'CEST' means summer time (UTC+2), and 'Central European Standard Time' is shortened to CET. Facepalm moment.

2. Both of these zones are going to mean something completely different soon. At best, we'll be left with 'Central European Time' (CET), but that may actually end up being UTC+2, so 'CET' now refers to UTC+1, but next year it may be reinterpreted to mean UTC+2, which is hell for computers, so the best option is not to buy into this CET/CEST malarky in the first place. Whichever one isn't chosen will then be an obsolete relic: A zone that no country is actually in.

3. Maybe CET/CEST will disappear entirely: Maybe western european countries adopt UTC+1, whereas eastern ones adopt UTC+2, to match their longitudes. In a vacuum, Poland should adopt UTC+2, The Netherlands should adopt UTC+1. Then there is no 'european central time' whatsoever.

4. You already HAVE the right answer in your code: Europe/Berlin. That is how you name time zones. Not with 3-letter or 4-letter acronyms that are nebulous, overloaded, and insufficient.

But in all cases the changes are overwritten and I get UTC when calling and endpoint.

That's the problem with global defaults. 'Do not use singletons' is a common maxim, and this is why: You run into deep problems.

Yes, something is overwriting it.

The best fix is that you shouldn't need to care what the 'global' timezone property is. Whatever code you have now that uses Calendar? Find it, replace it with code based on java.time.

reference: The deprecation notice on TimeZone's javadoc about TLA time zone IDs.

I suspect you are have version number clashing.

when creating a spring boot project i suggest you use the spring boot initializer. Here you can select what dependencies you want. Then they generate a project for you and when you look into the pom, you will se that there is a parent pom declared at the top.

That usually looks like this and contains the version for that release of spring boot: