How to integrate Keycloak to LDAPS

[Raymond Abargos]

Do anyone has experience integrating Keycloak with LDAPS server?

I previously integrated my own Keycloak service (Docker container) to a sample LDAP server, and it was working as expected. I was able to sync users from test LDAP server to Keycloak, using simple bind operation.

Now I need to integrate an existing LDAPS server to Keycloak. The test connection works, but the test authentication failed, even the simple bind credentials are correct.

I check the server.log for more details, and I get the java.security.cert.CertificateException error.

With this, I requested for the SSL certificate of the LDAPS server and it was installed on the machine where Keycloak is running. I also install the SSL certificate using Java keytool utility, but the error still persist.

Now I am stuck with this issue. If anyone has experienced this or resolved this, please advise. Thanks!

[valsaraj pv]

<spi name="truststore">
    <provider name="file" enabled="true">
        <properties>
            <property name="file" value="path to your .jks file containing public certificates"/>
            <property name="password" value="password"/>
            <property name="hostname-verification-policy" value="WILDCARD"/>
            <property name="disabled" value="false"/>
        </properties>
    </provider>
</spi>

Ref: https://www.keycloak.org/docs/7.0/server_installation/

Did you try this?

Thanks!

--
You received this message because you are subscribed to the Google Groups "Keycloak User" group.
To unsubscribe from this group and stop receiving emails from it, send an email to keycloak-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/e10b929a-2b3a-4e03-9573-4dcb420b990eo%40googlegroups.com.

--

Life is like this: "Just when we get all the answers of life.... God changes the question paper....

Valsaraj Viswanathan

[raymond...@gmail.com]

Not yet. Good thing I asked in this group. I'll try and see if it worked on my end.

Thanks!

[raymond...@gmail.com]

I edited the standalone.xml, and added this spi section, but now Keycloak instance won't start. Any ways to solve this?

[Jan Lieskovsky]

Hello Raymond,

  besides editing the standalone.xml file (as suggested above) if you don't need the truststore to be included permanently

(each time Keycloak is started), you can achieve the secure SSL / TLS connection not to fail due to unknown

certificate by supplying the "-Djavax.net.ssl.trustStore=" and "-Djavax.net.ssl.trustStorePassword=" CLI properties

/ arguments to the Keycloak start command.

Given you have the x509 certificate from the LDAP server stored to "server.truststore":

     $ keytool -import -alias ldap_server -file ldap_server.cert -storetype JKS -keystore server.truststore

where "ldap_server.cert" is the actual certificate from the LDAP server

you can then launch Keycloak as follows:

     $ ./standalone.sh \

       -Djavax.net.ssl.trustStore=../../../../../../server.truststore \

       -Djavax.net.ssl.trustStorePassword=changeme

Just replace the "../../../../../../server.truststore" with the real path to the truststore location,

you created earlier (containing the x509 cert from the LDAP server), and replace the "changeme"

above with the real password, specified when generating the truststore via keytool command.

If the provided LDAP server certificate was correct, upon Keycloak launch, configuring the LDAP identity provider and clicking
the "Test authentication" button, the SSL/TLS connection should work (you should get "Success" message upon button click).

Btw. you can always debug SSL/TLS issues by adding "-Djavax.net.debug=all" property to Keycloak launch to see

more verbose error output.

HTH

Regards, Jan
--

Jan iankko Lieskovsky / Keycloak / RH-SSO Team

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/a98b46e2-fbc9-4594-aaf9-ae4f633c9155n%40googlegroups.com.

[raymond...@gmail.com]

Hi Jan,

I appreciate your reply. I tried editing the standalone.xml but Keycloak isn't starting properly, so I left it to default settings.

I also tried creating the server.truststore using the exported LDAP certificate installed on my machine.

I still get the error of
2020-08-04 10:41:10,962 ERROR [org.keycloak.services] (default task-3) KC-SERVICES0055: Error when authenticating to LDAP: simple bind failed: <ldap-ip-address>:636: javax.naming.CommunicationException: simple bind failed: <ldap-ip-address>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address <ldap-ip-address> found]

Can you enlighten me more on how to integrate LDAPS on Keycloak?

By the way, I am using a Windows VM, using standalone.bat (plus the mentioned Java arguments)

Thanks!

[Jan Lieskovsky]

Hello Raymond,

  thank you for the follow up.

On Tue, Aug 4, 2020 at 12:45 PM raymond...@gmail.com <raymond...@gmail.com> wrote:

Hi Jan,

I appreciate your reply. I tried editing the standalone.xml but Keycloak isn't starting properly, so I left it to default settings.

I also tried creating the server.truststore using the exported LDAP certificate installed on my machine.

I still get the error of
2020-08-04 10:41:10,962 ERROR [org.keycloak.services] (default task-3) KC-SERVICES0055: Error when authenticating to LDAP: simple bind failed: <ldap-ip-address>:636: javax.naming.CommunicationException: simple bind failed: <ldap-ip-address>:636 [Root exception is javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative names matching IP address <ldap-ip-address> found]

There's some progress since last email (the truststore got recognized & the corresponding certificate was loaded / attempted

to be used). But the hostname verification failed this time. IOW the specified "Bind DN" value, used when creating the Keycloak LDAP federation provider is not listed in the subject alternative names field of the provided CA certificate. Thus the certificate validation

procedure couldn't verify the hostname of the remote host, Keycloak is trying to connect to, is truly trusted.

To solve the issue:

•  Either add the IP address, specified as the argument of the "Bind DN" field of the Keycloak federation provider to the list of subject alternative names, the certificate you are using is valid for,
• Alternatively, find out the current CN field in the certificate and ensure the remote LDAP server is resolvable under this hostname from Keycloak (changing the hostname / routing information of the server, where the LDAP server is running as necessary),
• You can completely omit the hostname certificate verification by specifying another property, the
  

                 -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true

             one this time. This will instruct the connecting Java client from Keycloak not to perform hostname verification at all. But this

             setting is not recommended in production environments, since it effectively disables hostname verification, and allows

             the client to connect to a remote LDAP server, it otherwise wouldn't connect to. But it can be used for testing to confirm

             the LDAP over SSL connection truly fails just because the remote hostname, specified as the Bind DN argument doesn't match

             the CN field / subject Alternative Name(s) listed in the certificate. Once both hostnames (the Bind DN one, and the cert's CN /

             sAN one) are put it match, the ldaps:// connection will work.

 

Can you enlighten me more on how to integrate LDAPS on Keycloak?

By the way, I am using a Windows VM, using standalone.bat (plus the mentioned Java arguments)

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/81cda306-d025-4ee8-84dc-8cdac734cd4dn%40googlegroups.com.

[raymond...@gmail.com]

Hi Jan,

So I was preoccupied with my other tasks, now I get back to the Keycloak LDAPS integration again.

I tried to append the disableEndpointIdentification argument to the Keycloak run command, but I got another error:

2020-09-04 11:56:38,112 ERROR [org.keycloak.services] (default task-1) KC-SERVICES0055: Error when authenticating to LDAP: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090434, comment: AcceptSecurityContext error, data 52e, v4563 ]: javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090434, comment: AcceptSecurityContext error, data 52e, v4563 ]

at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3154)

at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3100)

at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2886)

at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2800)

at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:319)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)

at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)

at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)

at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)

at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116)

at org.jboss.as.naming.InitialContext.init(InitialContext.java:101)

at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)

at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:91)

at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:43)

at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684)

at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:313)

at javax.naming.InitialContext.init(InitialContext.java:244)

at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:154)

at org.keycloak.storage.ldap.idm.store.ldap.LDAPContextManager.createLdapContext(LDAPContextManager.java:77)

at org.keycloak.storage.ldap.idm.store.ldap.LDAPContextManager.getLdapContext(LDAPContextManager.java:91)

at org.keycloak.services.managers.LDAPConnectionTestManager.testLDAP(LDAPConnectionTestManager.java:76)

at org.keycloak.services.resources.admin.RealmAdminResource.testLDAPConnection(RealmAdminResource.java:945)

at org.keycloak.services.resources.admin.RealmAdminResource.testLDAPConnection(RealmAdminResource.java:958)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

at java.lang.reflect.Method.invoke(Method.java:498)

at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:138)

at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:535)

at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:424)

at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:385)

at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:356)

at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:387)

at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:356)

at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:150)

at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:110)

at org.jboss.resteasy.core.ResourceLocatorInvoker.invokeOnTargetObject(ResourceLocatorInvoker.java:141)

at org.jboss.resteasy.core.ResourceLocatorInvoker.invoke(ResourceLocatorInvoker.java:104)

at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:440)

at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)

at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)

at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:356)

at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)

at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)

at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)

at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)

at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:590)

at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)

at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)

at org.keycloak.services.filters.KeycloakSessionServletFilter.doFilter(KeycloakSessionServletFilter.java:91)

at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)

at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)

at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)

at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)

at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)

at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)

at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at io.undertow.servlet.handlers.RedirectDirHandler.handleRequest(RedirectDirHandler.java:68)

at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)

at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)

at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)

at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)

at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)

at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)

at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)

at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)

at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:269)

at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:78)

at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:133)

at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:130)

at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)

at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)

at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)

at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)

at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)

at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)

at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1541)

at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:249)

at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:78)

at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)

at io.undertow.server.Connectors.executeRootHandler(Connectors.java:370)

at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)

at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)

at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)

at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)

at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)

at java.lang.Thread.run(Thread.java:748)

Any idea on what causes this new error?

[Jan Lieskovsky]

Hello Raymond,

On Fri, Sep 4, 2020 at 2:00 PM raymond...@gmail.com <raymond...@gmail.com> wrote:

Hi Jan,

So I was preoccupied with my other tasks, now I get back to the Keycloak LDAPS integration again.

I tried to append the disableEndpointIdentification argument to the Keycloak run command, but I got another error:

2020-09-04 11:56:38,112 ERROR [org.keycloak.services] (default task-1) KC-SERVICES0055: Error when authenticating to LDAP: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C090434, comment: AcceptSecurityContext error, data 52e, v4563 ]:

Per LDAP wiki, LDAP error code 49 (52e) happens when username is valid, but password / credential is invalid:

  https://ldapwiki.com/wiki/LDAP_INVALID_CREDENTIALS

Can you verify, both the bind DN & provided password are correct & retry?

HTH

Thank you && Regards, Jan

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/29bdb56b-cf02-418e-ab10-b19cb13c0690n%40googlegroups.com.

[raymond...@gmail.com]

Hi Jan,

I can confirm that I had the wrong password on my end. Can't tell the difference between small L and capital i :/

Anyways, thanks for your patience and support! I can now authenticate properly to the LDAPS server:

Now I tried to sync all users, but I got 0 users:

I added a Custom User LDAP Filter of (objectClass=user) but the sync is still having 0 users.

Any thoughts on this?

[Jan Lieskovsky]

Hello Raymond,

On Mon, Sep 7, 2020 at 12:29 PM raymond...@gmail.com <raymond...@gmail.com> wrote:

Hi Jan,

I can confirm that I had the wrong password on my end. Can't tell the difference between small L and capital i :/

Anyways, thanks for your patience and support! I can now authenticate properly to the LDAPS server:

Glad to hear you managed to get it working!

 

Now I tried to sync all users, but I got 0 users:

I added a Custom User LDAP Filter of (objectClass=user) but the sync is still having 0 users.

Any thoughts on this?

This can happen when values of "Username LDAP attribute" and / or "Users DN" fields, specified in the LDAP User

Federation provider doesn't correspond to the actual LDAP directory tree [*]

Can you list the users (their returned count != 0) if you try to list the directory (sub)tree content using the

identical searchbase using some other tool (e.g. ldapsearch or JXplorer)?

Unsure, if in previous discussion you already mentioned the flavour / vendor of the remote LDAP server used,

but taking the internal example of the ApacheDS testing LDIF file (the embedded ApacheDS directory server

needs to be started via: "[iankko@localhost utils]$ mvn exec:java -Pldap" command first [**]), if:

• The "Users DN" is set to "ou=People,dc=keycloak,dc=org",
• The "Username LDAP attribute" is kept to its default value ("uid"),
• The "Bind DN" is set to "uid=bwilson,ou=People,dc=keycloak,dc=org", and
• "password" is used as the "Bind Credential"

after clicking the "Synchronize all users" button, you should see two users to be imported. Hopefully you

can try this as an example, and once got it working, then modify the "Users DN", "Username LDAP attribute",

and "Bind DN" values, so they would match your environment.

HTH

Thank you && Regards, Jan

--

Jan iankko Lieskovsky / Keycloak / RH-SSO Team

[*] Actually, it can happen if other fields / settings of the LDAP federation provider are misconfigured / mistyped too,

of course, but IMHO misconfiguration of these two is the fault in majority of the cases.

 

[**] The above example command isn't using LDAPS to connect to the ApacheDS server, since it's

just an example how to identify the proper LDAP bind DN / searchbase to use. But LDAPS for the

internal ApacheDS is available too. See the implementation for the available options if interested.

To view this discussion on the web visit https://groups.google.com/d/msgid/keycloak-user/1ec20251-e5a7-4e7f-b14a-8be0075748e5n%40googlegroups.com.

[raymond...@gmail.com]

Hi Jan,

So I further investigated on this matter, and the previous Users DN that was provided to me was wrong, thus no users synced.

Upon discovering the correct users path after binding to our LDAPS server, user sync was successful (there are errors because some entries are group [not people] I think).

Anyways, I think this closes the issues I encountered on this thread. I'll make notes of the details and experiences I taken care of and maybe share the knowledge to those in need.

Thank you so much!

[Romit Mehta]

Hello Raymond, Jan and Keycloak community,
I've been trying to setup LDAPS in Keycloak and my LDAP server is none other than Google workspace.
I've done the basic configuration but I end up getting the message 
"ERROR [org.keycloak.storage.ldap.idm.store.ldap.LDAPOperationManager] (executor-thread-33) Could not query server using DN [ou=Users,dc=suremdm,dc=com] and filter [(&(objectclass=inetOrgPerson)(objectclass=organizationalPerson))]: javax.naming.NoPermissionException: [LDAP: error code 50 - Insufficient Access Rights]; remaining name 'ou=Users,dc=xxxx,dc=com'"
I am not sure what could be wrong here?
I've updated my keystore with ldap server pem files. I am able to confirm from thet logs while KeyCloak can establish a secure connection to ldaps://ldap.google.com:636 (as evidenced by the successful TLS handshake), it lacks the necessary permissions to perform the search operation on the specified DN. Any help on this would be appreciated

Thanks!

[Romit Mehta]

Hi all,

Could it be related to mappers or something like that?

Thanks,

Romit Mehta

You received this message because you are subscribed to a topic in the Google Groups "Keycloak User" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/keycloak-user/06VTCNslXgY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to keycloak-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/keycloak-user/da394f30-f27f-4e52-9226-2a41e5095f1bn%40googlegroups.com.

[Joel McLean]

One thing I did when I set up Keycloak to my LDAPS back ends was install ldaputils on my application servers, and replicate the kinds of calls that Keycloak needed to make using the ldaputils command lines. It helped me rule out the Keycloak configuration problems I suspected, and found root cause problems with how LDAPS in java’s keystore demands not only a valid certificate matching the hostname, but for the signing CA to be in the ca-certificates of the application server’s operating system.

 

LDAPutils will give you much more usable output than Keycloak will.

e.g.

ldapwhoami -v -H ldaps://your.ldapsserver.hostname:636 -D 'cn=username,ou=Group Name,dc=Contoso,dc=local' -x -W

 

Kind Regards,

Joel

Now I tried to sync all users, but I got 0 users:

 

I added a Custom User LDAP Filter of (objectClass=user) but the sync is still having 0 users.

Any thoughts on this?

 

To view this discussion visit https://groups.google.com/d/msgid/keycloak-user/CAB__fcrLRK8_YxLfxEK_tcU74Ha3iNcsUUEQOj3jOEjtsi5ekQ%40mail.gmail.com.