[
https://issues.apache.org/jira/browse/GUACAMOLE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper reassigned GUACAMOLE-244:
----------------------------------------
Assignee: Michael Jumper (was: Nick Couchman)
> Allow configuration of LDAP alias dereferencing
> -----------------------------------------------
>
> Key: GUACAMOLE-244
> URL: https://issues.apache.org/jira/browse/GUACAMOLE-244
> Project: Guacamole
> Issue Type: Improvement
> Components: guacamole-auth-ldap
> Reporter: Nick Couchman
> Assignee: Michael Jumper
> Priority: Minor
> Fix For: 0.9.13-incubating
>
>
> Similar to referral following, it is useful in certain situations to allow
> the user to decide if aliases should be dereferenced or not:
> - An admin may want to create a separate area for users or connections and
> just alias the users rather than moving or creating them there.
> - Such areas in the LDAP tree might already exist, and might cause problems
> (e.g. duplicate users) if someone is querying an entire tree and
> dereferencing aliases.
> Further clarification from [[email protected]] in [the discussion for
> incubator-guacamole-client PR
> #131|https://github.com/apache/incubator-guacamole-client/pull/131#issuecomment-287660731]:
> {quote}
> ... in my past history of running LDAP servers, I've run into a couple of
> situations where the ability to configure how the LDAP client handled
> dereferencing of aliases was almost, if not, essential, to being able to use
> LDAP.
> Consider an LDAP tree where the main user account section is
> ou=People,dc=example,dc=com, and a separate section specifically for users
> with VPN access is ou=VPN_Users,dc=example,dc=com. The entries in the
> ou=VPN_Users section are aliases to the actual object in the ou=People
> section, allowing the tree to remain organized, but providing a separate
> section that can be queried specifically for users who need VPN access.
> Here are the following situations:
> * If you query the base of the tree, at dc=example,dc=com, alias
> dereferencing is enabled, you'll come away with duplicate objects - for
> example, cn=Nick Couchman,ou=VPN_Users,dc=example,dc=com will show up, as
> will cn=Nick Couchman,ou=People,dc=example,dc=com. For some LDAP clients that
> base their naming on the cn= property, for example, this will cause errors
> because of the duplicate accounts. Being able to turn off alias dereferencing
> in these situations is very useful, as it allows the tree to be organized and
> divided for certain applications but also searchable a the root level for
> others.
> * Conversely, if you wanted, for example, to allow access to Guacamole for
> the folks who are aliased in the ou=VPN_Users area, and not have to move
> their accounts, you would need alias dereferencing to be enabled and then
> you'd point the base of your search at the ou=VPN_Users,dc=example,dc=com
> part of the LDAP tree, and it would appear as if those users were in that
> location, even though they are simply linked to the real objects.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
