Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D103A200BCD for ; Sun, 13 Nov 2016 03:11:05 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id CFA3F160B14; Sun, 13 Nov 2016 02:11:05 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 25FC4160B00 for ; Sun, 13 Nov 2016 03:11:05 +0100 (CET) Received: (qmail 92872 invoked by uid 500); 13 Nov 2016 02:11:04 -0000 Mailing-List: contact commits-help@guacamole.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@guacamole.incubator.apache.org Delivered-To: mailing list commits@guacamole.incubator.apache.org Received: (qmail 92862 invoked by uid 99); 13 Nov 2016 02:11:04 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Nov 2016 02:11:04 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 01AE118069B for ; Sun, 13 Nov 2016 02:11:04 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -7.019 X-Spam-Level: X-Spam-Status: No, score=-7.019 tagged_above=-999 required=6.31 tests=[KAM_LAZY_DOMAIN_SECURITY=1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.999] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id nYsGUDVXbrHp for ; Sun, 13 Nov 2016 02:11:01 +0000 (UTC) Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with SMTP id DE02F5F613 for ; Sun, 13 Nov 2016 02:11:00 +0000 (UTC) Received: (qmail 92776 invoked by uid 99); 13 Nov 2016 02:10:59 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 13 Nov 2016 02:10:59 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 9E8FF2C0276 for ; Sun, 13 Nov 2016 02:10:59 +0000 (UTC) Date: Sun, 13 Nov 2016 02:10:59 +0000 (UTC) From: "Michael Jumper (JIRA)" To: commits@guacamole.incubator.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (GUACAMOLE-70) Add option to restrict access to users within database MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Sun, 13 Nov 2016 02:11:06 -0000 [ https://issues.apache.org/jira/browse/GUACAMOLE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Jumper resolved GUACAMOLE-70. ------------------------------------- Resolution: Done > Add option to restrict access to users within database > ------------------------------------------------------ > > Key: GUACAMOLE-70 > URL: https://issues.apache.org/jira/browse/GUACAMOLE-70 > Project: Guacamole > Issue Type: Improvement > Components: guacamole-auth-jdbc > Reporter: Michael Jumper > Assignee: Michael Jumper > Fix For: 0.9.11-incubating > > > The LDAP and database authentication backends have been usable together since [GUAC-586|https://glyptodon.org/jira/browse/GUAC-586], but this still causes trouble in the case that only LDAP users that *also* exist within the database should have access. > There are cases where large deployments of Guacamole involve a large LDAP tree that contains many users, only a subset of which should be granted access to Guacamole. Restructuring the LDAP tree to ensure that only certain users can log in to Guacamole is not always feasible. Rather than universally granting access so long as LDAP accepts the credentials, the database authentication should provide an option to deny access to authenticated users if they do not also have associated data in the database. > It has been verified that extensions can indeed reject an otherwise positive authentication result from a different extension. -- This message was sent by Atlassian JIRA (v6.3.4#6332)