From users-return-30117-apmail-activemq-users-archive=activemq.apache.org@activemq.apache.org Thu Feb 2 21:38:27 2012
Return-Path:
X-Original-To: apmail-activemq-users-archive@www.apache.org
Delivered-To: apmail-activemq-users-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id ECFCD9306
for ; Thu, 2 Feb 2012 21:38:26 +0000 (UTC)
Received: (qmail 90190 invoked by uid 500); 2 Feb 2012 21:38:26 -0000
Delivered-To: apmail-activemq-users-archive@activemq.apache.org
Received: (qmail 90117 invoked by uid 500); 2 Feb 2012 21:38:25 -0000
Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: users@activemq.apache.org
Delivered-To: mailing list users@activemq.apache.org
Received: (qmail 90107 invoked by uid 99); 2 Feb 2012 21:38:25 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2012 21:38:25 +0000
X-ASF-Spam-Status: No, hits=-0.7 required=5.0
tests=RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of mattrpav@gmail.com designates 209.85.213.171 as permitted sender)
Received: from [209.85.213.171] (HELO mail-yx0-f171.google.com) (209.85.213.171)
by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 02 Feb 2012 21:38:16 +0000
Received: by yenq6 with SMTP id q6so1465819yen.2
for ; Thu, 02 Feb 2012 13:37:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=message-id:date:from:user-agent:mime-version:to:subject:references
:in-reply-to:content-type:content-transfer-encoding;
bh=0BKD81DEwYdymFwmip1lOvK7LGPVITiNva/AC6+qwzE=;
b=DQMzSLuudNZSKr+Rgmz8+98gO7UBKpTxEonY4RBOEPToNIt/PFsyek66HzBzEkQZ3q
+lh/rJJTPaL+lxHkYnfmxIV5cV50f93vDyOG6CSKwfY6K97b8Wgf9eg2lMMzvcyYeADQ
FDKSE9SngV8ySfmekasRfzQDn7MuHUBPmxMc4=
Received: by 10.236.79.37 with SMTP id h25mr7247122yhe.76.1328218675794;
Thu, 02 Feb 2012 13:37:55 -0800 (PST)
Received: from macbookpro-2.mediadriver.com ([75.103.13.13])
by mx.google.com with ESMTPS id r68sm5666324yhm.18.2012.02.02.13.37.54
(version=SSLv3 cipher=OTHER);
Thu, 02 Feb 2012 13:37:55 -0800 (PST)
Message-ID: <4F2B0232.9090506@gmail.com>
Date: Thu, 02 Feb 2012 15:37:54 -0600
From: Matt Pavlovich
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: users@activemq.apache.org
Subject: Re: LDAPAuthorizationMap and Active Directory
References:
In-Reply-To:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
Chris-
This is one of the major flaws in LDAP. There are a number of
conventions for handling group membership, and no strictly followed
"standard". Listing of common names, such as CN values, or listing full
DNs. Then, there is the model of dynamic groups, where the user entry
has the group listing, vs the group having the user listing. Confused yet?
There are a couple of member-related attributes: member, memberOf and a
couple other attributes that are used for membership. I'm not an expert
in AD, but I believe I have seen instances where they use both the DN
list on the group and the dynamic group model, where the groups are
listed on the users. I think it may depend on how many "upgrades" that
AD instance has been through.a
A patch may make sense, but it would need to be consider all the weird
LDAP grouping models.
Matt Pavlovich
On 2/2/12 3:13 PM, Chris Robison wrote:
> Has anyone been able to use the LDAPAuthorizationMap successfully with
> Active Directory? In my investigation, I don't think it will ever work in
> its current state. When looking at the code, it is making the assumption
> that the value of the member attribute (or what ever attribute you are
> using) is always going to be in the form "{0}={1}" (a RDN). But, according
> to the OpenLDAP spec, the member attribute value is a distinguished name.
> That means values are a comma delimited list of RDNs. So, for example I
> have AD groups that represent MQ roles. Here's one I use:
> "CN=MQUser,OU=Groups,OU=ActiveMQ,DC=cdr,DC=corp". The LDAPAuthorizationMap
> considers the name of the
> role "MQUser,OU=Groups,OU=ActiveMQ,DC=cdr,DC=corp". Is this by design? I
> would be happy to submit a patch to change this behavior. Thoughts?
>
> Chris Robison
>