[
https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Couchman reassigned GUACAMOLE-243:
---------------------------------------
Assignee: Nick Couchman
> LDAP auth fails when search results include an LDAP referral
> ------------------------------------------------------------
>
> Key: GUACAMOLE-243
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-243
> Project: Guacamole
> Issue Type: Bug
> Components: guacamole-auth-ldap
> Reporter: Adam Thorn
> Assignee: Nick Couchman
> Fix For: 0.9.14-incubating
>
>
> The ldap search in
> extensions/guacamole-auth-ldap/src/main/java/org/apache/guacamole/auth/ldap/user/UserService.java
> to find the DN of the user who is logging in (i.e. inside getUserDNs() )
> fails if the LDAPSearchResults include an LDAP referral, because
> LDAPSearchResults.next() throws an LDAPReferralException:
> https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPSearchResults.html#next()
> This particularly affects Active Directory, where typically the LDAP
> implementation has separate partitions for DNS zones and Configuration (see
> e.g.
> http://stackoverflow.com/questions/32989159/ldapsearch-entire-active-directory-without-refldap-returns
> for an example of the three LDAP referrals that AD returns). Empirically,
> against my AD, even when an ldap search for (sAMAccountName=$USERNAME)
> correctly returns the dn for the searched-for $USERNAME , I still also get
> the three ldap referrals mentioned in that stackoverflow post. Thus, even
> though the first result in the LDAPSearchResults has the correct dn for the
> user logging in, results.next() then throws an exception when it encounters
> the referral and the login fails.
> This only happens when ldap-user-base-dn is set to the base dn of my AD (i.e.
> with dc=example,dc=com I get referrals, but with ou=Users,dc=example,dc=com
> as the search base I do not). The structure of my AD requires me to set the
> base dn as the search base, though.
> N.B. A possible workaround is to explicitly query the Global Catalog (by
> setting ldap-port: 3268). However, that performs a forest-wide search rather
> than just a domain-wide search, which might not be desired.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
