[ https://issues.apache.org/jira/browse/GUACAMOLE-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15930047#comment-15930047 ]
Adam Thorn commented on GUACAMOLE-243: -------------------------------------- Pull request #129 made as a possible solution to this! > 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)