Hi,
Depending on the implementation of your LDAP server, 'uid' is most likely the
unique identifier so not once should there be two LDAP entries with the same value.
If you're searching based on your uuid which most likely set to 'uid', then
other conditions shouldnt matter as only one can return anyway.
Remove 'uid' from your baseDN could fix your issue.
Even better to help you out, could you send your LDAP federation config? Leave out all the
information that you may consider sensitive such as passwords.
- Kevin
On 8 Feb 2017 10:46 am, Salvatore Incandela <salvatore.incandela(a)redhat.com>
wrote:
This is what is see from log files:
*2017-02-08 10:36:41,667 TRACE
[org.keycloak.federation.ldap.idm.store.ldap.LDAPIdentityStore] (default
task-44) Found ldap object and populated with the attributes. LDAP Object:
LDAP Object [ dn: uid=example,ou=People,dc=example,dc=it , uuid: example,
attributes: {uid=[example], userPassword=[[B@6ba1b2f0],
mail=[example(a)example.it <example(a)example.it>], givenName=[example],
sn=[example], title=[disabled], modifyTimestamp=[20170207194557Z],
createTimestamp=[20170207114007Z]}, readOnly attribute names: [givenname,
sn, userpassword, mail, uid, modifytimestamp, title, createtimestamp] ]*
Why in the case of UUID search the Custom User LDAP Filter is ignored?
On Wed, Feb 8, 2017 at 9:03 AM, Marek Posolda <mposolda(a)redhat.com> wrote:
On 07/02/17 16:12, Salvatore Incandela wrote:
> Hi Guys, I'm configuring keycloak 7.0 with Ldap Federation, I put a custom
> query in the *Custom User LDAP Filter* parameter ("(title=enabled)"), but
> this seems to be ignored.
> Looking on the LDAPIdentityStore.fetchQueryResults method. It seems that
> once an EqualsCondition was found this one is considered and the others
> ignored.
>
> *if (condition instanceof EqualCondition) {*
> .
> .
> return results;
> }
>
Nope, if you look at the code more deeply, you can find that this one is
used just for the special case when you query by UUID.
Maybe it can help to enable TRACE logging for the class
org.keycloak.storage.ldap.idm.store.ldap.LDAPIdentityStore in your
standalone.xml . With this enabled, you should be able to see some
additional logging messages in server.log like:
TRACE Using filter for LDAP search: ...
you can see in which DN you're searching and how exactly your LDAP filter
looks like. Hopefully this can help to figure what is wrong.
Marek
> I'm sure that I'm doing something wrong, some ideas?
>
>
--
Salvatore Incandela
Middleware Consultant
------------------------------
Red Hat -
www.redhat.com<http://www.redhat.com>
Via Andrea Doria 41M
00192 Roma (Italy)
Mobile +39 349 6196615
Fax +39 06 39728535
E-mail salvatore.incandela(a)redhat.com
_______________________________________________
keycloak-user mailing list
keycloak-user(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-user