[
https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930315#comment-15930315
]
Nick Couchman commented on GUACAMOLE-243:
-----------------------------------------
Just to follow up a little more on the Novell LDAP implementation...if you want
to follow referrals, in addition to setting up the aforementioned option, you
also have to set the setReferralHandler() option and implement one of the two
possible LDAPReferralHandler options: LDAPAuthHandler or LDAPBindHandler. If
you do not, the Novell LDAP java class defaults to anonymous binds in order to
follow the referrals, and, particularly if you're using AD (or any other LDAP
directory server configured to disallow anonymous binds), you're going to run
into problems.
So, for this particular extension, it means implementing the configuration
options for following LDAP referrals, and also a class or two that implement
one or both of the above abstract referral handler classes. Here are some
links to documentation that will help with this:
https://www.novell.com/documentation/developer/jldap/jldapenu/api/com/novell/ldap/LDAPReferralHandler.html
(Comments at the top of the following document are most helpful as it describes
the behavior of the class and the various ways to handle referrals):
https://www.novell.com/documentation/developer/samplecode/jldap_sample/SearchUtil.java.html
It'd be nice if the Novell LDAP class referral following defaults to using your
existing configuration rather than just anonymous - that is, if you've
configured it to bind as a certain user, it'll bind as that user, if you're
using anonymous, it'll do anonymous, etc. But, no such luck...at least the
LDAPBindHandler class will have to be implemented, if not both that and
LDAPAuthHandler.
> 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)
