[ https://issues.apache.org/jira/browse/AMQ-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Claus Ibsen reassigned AMQ-4685: -------------------------------- Assignee: Claus Ibsen > LDAPLoginModule throws InvalidNameException when resolving LDAP aliases > ----------------------------------------------------------------------- > > Key: AMQ-4685 > URL: https://issues.apache.org/jira/browse/AMQ-4685 > Project: ActiveMQ > Issue Type: Bug > Components: Broker > Affects Versions: 5.x > Environment: OS Independent > OpenLDAP 2.4 > Reporter: Igor Podolskiy > Assignee: Claus Ibsen > Priority: Minor > Attachments: handle-ldap-aliases-v1.patch > > > Some LDAP servers allow you to define aliases for objects. For example, > consider the following LDAP directory layout: > {code} > dc=example,dc=com > ou=ActiveMQ > ou=Users > ou=Roles > ou=Destinations > ou=People > {code} > In this layout, accounts specific to ActiveMQ go under ou=Users,ou=ActiveMQ. > However, some accounts in ou=People should also be able to have access to the > ActiveMQ server. To avoid duplicating accounts, you can have the regular > account (objectClass=inetOrgPerson) in ou=People and create an LDAP alias > (objectClass=alias) for it in ou=People. The LDAP server then takes care > about the alias resolution. > The JNDI LDAP client supports LDAP alias dereferencing as well. However, the > search results for resolved aliases are different. For regular entries, > SearchResult.getName() returns a relative DN and SearchResult.isRelative() > returns true; for dereferenced aliases, SearchResult.getName() returns a full > LDAP URI with the DN of the alias target (for example, > 'ldap://localhost:389/uid=bob,ou=People,dc=example,dc=com') and > SearchResult.isRelative() returns false (as documented, for example, in [1]). > The code in o.a.a.jaas.LDAPLoginModule does not make this distinction. It > assumes that all returned names are RDNs and passes them to > NameParser.parse() which in turn raises a NamingException because an LDAP URI > is obviously not an LDAP (R)DN. > The attached patch resolved the problem at least for my configuration. If > isRelative() returns false, the name is parsed as an URI. Per definition of > LDAP URIs, the path component is the distinguished name, which is then taken. > Of course, this does not take care of multiple layers of aliases, aliases for > containers and so on - I just found it over the course of setting up LDAP > authentication in my system, which happens only to alias user accounts. It > works for me with the patch and seems not to make things worse :) If needed, > maybe I can do some further tests and/or correct the patch. > [1] http://docs.oracle.com/javase/jndi/tutorial/ldap/misc/aliases.html -- This message was sent by Atlassian JIRA (v6.1#6144)