[
https://issues.apache.org/jira/browse/AMQ-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hadrian Zbarcea updated AMQ-4685:
---------------------------------
Fix Version/s: 5.9.1
> 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
> Fix For: 5.9.1, 5.10.0
>
> 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.2#6252)
