[
https://issues.apache.org/jira/browse/GUACAMOLE-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Jumper updated GUACAMOLE-244:
-------------------------------------
Description:
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}
was:
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.
> Allow Configuration of 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: Nick Couchman
> 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)
