[
https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930099#comment-15930099
]
Nick Couchman commented on GUACAMOLE-243:
-----------------------------------------
So, I guess my first question here is this: is simply ignoring the error the
right thing to do? I understand the problem, particularly with AD (and it
helps me understand why I had to point my Guacamole instance at the GC port
:-), but it seems like it would probably be a more proper LDAP client
implementation if it did something with the failure to follow the referral.
For one thing, perhaps we should add a configuration item to the
guacamole.properties file that controls whether or not referrals are followed
at all, and then, based on whether that is configured or not and if this error
gets received, do something with the error. Ignoring it might be one possible
route to go (e.g. if you explicitly disabled following referrals), but you also
might want to do something else with the error if you expect the referral to be
followed and it isn't.
-Nick
> 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
>
> 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.3.15#6346)
