[Shib-Users] Releasing AD group memberships from the IDP
Wessel, Keith William
I'm tryingto find some way to release a user's full list of group memberships in Active Directory, both inherited memberships and otherwise.
I've combed the wiki and consulted Google and found nothing about this topic. If I'm missing something already out there, please point me in the right direction.
We've had several requests lately to provide a user's AD group memberships to SPs. Of course, Microsoft doesn't make this easy. If we just want to release memberOf from Active Directory, that's no problem, but it won't include inherited group memberships.
I've discovered that, to use the tokenGroups attribute that solves this problem, I must (1) change my search scope to base and set the search base to the user's specific node in AD, (2) decode the binary SSID values returned for the tokenGroups attribute, and (3) do a query on those SSIDs to find the group DNs that they correspond to in AD. Woosh!
Has anyone found a way to make this happen through the IDP, or found some other way to accomplish the same end result? Am I better off putting Grouper in the middle to help with this magic?
Thanks,
Keith
Jim Fox
My AD guy says this is possible. Following is the thread.
Up to you to extract the relevent details.
We, on the other hand, use a group webservice call, much like your proposed grouper solution.
Jim
> From bark...@washington.edu Tue May 3 15:13:00 2011
> Date: Tue, 3 May 2011 15:13:11 -0700
> From: Brian Arkills <bark...@washington.edu>
> To: "Jim Fox (f...@uw.edu)" <f...@uw.edu>
> Subject: FW: [ActiveDir] Search filter to find all distribution groups that a user is a member of.
>
>
>
> The 2nd ldap filter below is an example of the nested group membership search
> for AD.
>
>
>
> From: actived...@mail.activedir.org
> [mailto:actived...@mail.activedir.org] On Behalf Of Gil Kirkpatrick
> Sent: Tuesday, August 18, 2009 3:42 PM
> To: acti...@mail.activedir.org
> Subject: RE: [ActiveDir] Search filter to find all distribution groups that a
> user is a member of.
> Importance: High
>
>
>
> Yes, yes, and yes. See
> http://msdn.microsoft.com/en-us/library/cc223370(PROT.10).aspx and
> http://msdn.microsoft.com/en-us/library/aa746475(VS.85).aspx. It was new in
> WS08.
>
>
>
> -g
>
>
>
> From: actived...@mail.activedir.org
> [mailto:actived...@mail.activedir.org] On Behalf Of Dan Holme
> Sent: Wednesday, August 19, 2009 4:51 AM
> To: acti...@mail.activedir.org
> Subject: RE: [ActiveDir] Search filter to find all distribution groups that a
> user is a member of.
>
>
>
> Gil. I can’t believe I’ve never heard of the “in chain” matching rule… does
> this really enum nested memberships? Is there an “in chain” for memberOf as
> well? Does this work for dist *and* sec groups?
>
>
>
> Dan
>
> Dan Holme
>
> Intelliem (www.intelliem.com)
>
> 808.573.0726 Land Line
>
> 808.463.4858 iPhone
>
>
>
> From: actived...@mail.activedir.org
> [mailto:actived...@mail.activedir.org] On Behalf Of Gil Kirkpatrick
> Sent: Tuesday, August 11, 2009 12:51 AM
> To: acti...@mail.activedir.org
> Subject: RE: [ActiveDir] Search filter to find all distribution groups that a
> user is a member of.
>
>
>
> The query string you have is trying to return things that have
> objectCategory=group AND objectClass=user. I’m pretty sure there aren’t any such
> objects in your AD.
>
>
>
> I think what you want is more like this:
>
>
>
> (&(objectCategory=group)(grouptype:1.2.840.113556.1.4.804:=2)(member=CN=Usernam
> e,OU=someOu,DC=someDomain,DC=com))
>
>
>
> That would return all the groups that CN=Username is a direct member of.
>
>
>
> If you want all the groups that CN=Username is a member of, directly or
> indirectly, you can use the “in chain” matching rule.
>
>
>
> (member:1.2.840.113556.1.4.1941:= CN=Username,OU=someOu,DC=someDomain,DC=com)
>
>
>
> -gil
>
>
>
> From: actived...@mail.activedir.org
> [mailto:actived...@mail.activedir.org] On Behalf Of Alex Gomez
> Sent: Tuesday, August 11, 2009 7:21 PM
> To: acti...@mail.activedir.org
> Subject: [ActiveDir] Search filter to find all distribution groups that a user
> is a member of.
>
>
>
> Hi everyone,
>
> I wish to find all the distribution groups that a user is a member of. Thus far,
> I have the the following ldap search filter but unfortunately it's returning 0
> results. I guess the search filter is wrong in some way.
>
>
> (&(&(objectcategory=group)(sAMAccountType=268435457)(grouptype:1.2.840.113556.1
> .4.804:=2))(objectClass=user)(cn=testUser))
>
>
>
>
>
> Any sort of help would be appreicated. Thanks again.
>
>
>
> Ryan
>
>
>
>
> ________________________________________________________________________________
>
>
> Windows Live Messenger: Thanks for 10 great years-enjoy free winks and
> emoticons. Get Them Now
>
>
Daniel Fisher
configured in the attribute resolver to perform recursive lookups.
--Daniel Fisher
Martin B. Smith
> I've discovered that, to use the tokenGroups attribute that solves this problem, I must (1) change my search scope to base and set the search base to the user's specific node in AD, (2) decode the binary SSID values returned for the tokenGroups attribute, and (3) do a query on those SSIDs to find the group DNs that they correspond to in AD. Woosh!
Hi William,
We've looked at doing this via tokenGroups (we expose non-recursive
groups through LDAP now, as a full DN so it can't be partially spoofed
by the same group name in another OU). We have been trying to push down
everything related to attribute-resolution in to the database layer, so
all of my examples are proof-of-concept Perl or Oracle stored
procedures. Ping me if you want to see any of those.
Unfortunately, we quickly discovered that recursive groups in our AD
implementation (where OU control is often delegated to local
departments) yields a *HUGE* size for the final DN attribute (think
CLOB, not VARCHAR), and the result is also unwieldy to match against.
We've even discussed a situation where groups can opt-in to being
exposed through our Shibboleth implementation, though I think we're
basically on hold for now.
On 05/04/2011 10:26 AM, Daniel Fisher wrote:
> If Jim's solution doesn't work for you, a SearchResultHandler can be
> configured in the attribute resolver to perform recursive lookups.
I'd love an example of using a SearchResultHandler to perform recursive
look up (and some stats on how many iterations, on average, that it
takes to terminate!). We looked at tokengroups because it was faster
than possibly doing 5-10 recursive calls, but then we were stuck with
the problem of converting LDAP results that were SIDs back to group
names in the IdP.
After all of the above, you can see why we tended towards hiding as much
of the complexity as possible in our attribute database.
Hope some of this helps; cheers,
--
Martin B. Smith
smi...@ufl.edu - (352) 273-1374
CNS/Open Systems Group
University of Florida
Wessel, Keith William
So far, the query Jim suggested hasn't worked for us when I substitute in the proper values. I'll keep working with it, but I have some performance concerns about that route as it means a potentially heavy AD query for every Shib login. We'll see, though, if the right indexing on AD can help with this.
Daniel, I'd love to see an example of configuring recursive searches on the IDP as that's what I originally had in mind, and I didn't know it was possible. It'd be interesting to perform the time and AD server load for that method compared to Jim's suggestion.
Martin, unfortunately, AD is currently authoritative for these groups. That may not be the case down the road, but it won't be changing any time soon. I'm trying to keep this simple, and your solution sounds a bit more complex than what I'm looking for right now. Honestly, if this route doesn't pan out, the next step is Grouper, and that's going to take some persuading right now with our current resource constraints in my department.
Thanks again, everyone, I really appreciate it.
Keith
Jim Fox
A concern of ours when adding memberOf attributes to our IdP
was the excessive overhead of the effective membership queries.
Considering that the vast majority of logins do not result in any
memberOf attributes being sent, i.e. to google.com, this seemed
intolerable. Possibly other sites send memberships to most SPs
and this is less of an issue.
Our solution was a custom attribute resolver which, in addition to
retrieving effective memberships, maintains a list of SP entity ids
for which it will be activated. For all others it does nothing,
thus no overhead for 95% of logins. If you go the route of
extending the ldap resolver with a RecursiveSearchResultHandler,
you might consider adding an activation capability.
A final consideration, if you intend to release all
memberships to some SPs, and you use 'name-spaced' group names,
e.g. urn:mace:incommon:uiuc.edu:groups:etc:etc, your attribute
value strings can get really long. We recently had a case where
the connection from apache to tomcat broke because of this.
Jim
On Wed, 4 May 2011, Wessel, Keith William wrote:
> Date: Wed, 4 May 2011 12:48:06 -0700
> From: "Wessel, Keith William" <kwe...@illinois.edu>
> To: "shibbole...@internet2.edu" <shibbole...@internet2.edu>
> Reply-To: shibbole...@internet2.edu
> Subject: RE: [Shib-Users] Releasing AD group memberships from the IDP
Daniel Fisher
<kwe...@illinois.edu> wrote:
> Daniel, I'd love to see an example of configuring recursive searches on the IDP as that's what I originally had in mind, and I didn't know it was possible. It'd be interesting to perform the time and AD server load for that method compared to Jim's suggestion.
I'll probably need some guidance on the schema since we don't use AD,
but here's what I was thinking:
<dc:LDAPProperty name="edu.vt.middleware.ldap.searchResultHandlers"
value="edu.vt.middleware.ldap.handler.FqdnSearchResultHandler,
edu.vt.middleware.ldap.handler.EntryDnSearchResultHandler,
edu.vt.middleware.ldap.handler.BinarySearchResultHandler,
edu.vt.middleware.ldap.handler.RecursiveSearchResultHandler{{searchAttribute=memberOf}{mergeAttributes=memberOf}}"/>
Here's the javadoc:
http://vt-middleware.googlecode.com/svn/vt-ldap/javadoc/vt-ldap-3.3.2/edu/vt/middleware/ldap/handler/RecursiveSearchResultHandler.html
and if this class doesn't meet your needs, you can always write your
own implementation. Note that the vt-ldap distro ships with some shell
scripts that can make testing this easier. See the ldapsearch script
and use the -searchResultHandlers param.
--Daniel Fisher