Thanks Milt.
I am still struggling with getting the method Marvin mentioned to work. I am
hoping he will be able to respond back and give me some pointers that will lead
me to a solution.
Thanks though for the suggestion you gave as a workaround. I would like to
avoid that route but if necessary, it does look like it I could make it work
for our situation.
Doug
> Date: Mon, 12 Jan 2015 13:16:21 -0600
> From: [email protected]
> To: [email protected]
> Subject: RE: [cas-user] CAS 4.0 w/ OpenLDAP won't return memberOf attribute
>
> Doug,
>
> Did you ever get this working?
>
> We were trying to do the same thing (we're also using OpenLdap), and
> ran into what sounds like the same problem. We did get something
> similar working, but we had to do some additional configuration on our
> LDAP server and use a different attribute name. I'm not clear on all
> the details, but our LDAP admin gave me this as a general reference:
>
> http://blog.oddbit.com/2013/07/22/generating-a-membero/
>
> He said the key point was having to use a different attribute name,
> since memberOf is an operational attribute.
>
> I'll add that there were some issues with this new setup on our master
> server, it conflicted with something else, so we had to disable it
> there.
>
> If you do get this working, using the PersonAttributeDao as Marvin
> suggested, or something else, I'd appreciate hearing about it. But
> maybe this info will help you get it going similar to how we did it.
>
> Milt Epstein
> Applications Developer
> Graduate School of Library and Information Science (GSLIS)
> University of Illinois at Urbana-Champaign (UIUC)
> [email protected]
>
>
> On Sat, 10 Jan 2015, Doug Campbell wrote:
>
> > Thanks Marvin for the response.
> >
> > <bean id="attributeRepository"
> >
> > class="org.jasig.cas.persondir.LdapPersonAttributeDao"
> >
> > p:connectionFactory-ref="searchPooledLdapConnectionFactory"
> >
> > p:baseDN="${ldap.resolver.baseDn}"
> >
> > p:searchControls-ref="searchControls"
> >
> > p:searchFilter="uid={0}">
> >
> > Believe I see the problem. The security context of this search is either
> > anonymous or using a service credential; in either case it's not the
> > security context of the authenticating user needed for the overlay. In
> > other words it's not visible to you. I think I am not seeing this though.
> > If I use the manager account that is used to search the directory or the
> > credentials of the use who is logging in with ldapsearch, as long as I
> > explicitly request the memberOf attribute it gets returned.
> > You should be able to use the additionalAttributes property of
> > LdapAuthenticationHandler to fetch attributes and add them to the principal
> > at authentication time. In that case you're bound as the user, which should
> > satisfy the overlay. Then you'll need to use a static PersonAttributeDao to
> > simply define stub properties for the attributeRepository. The real values
> > come from the principal. That's advanced configuration that is not
> > documented anywhere, but most of the difficulty is with PersonDirectory
> > components, not CAS ones per se. I have a StaticPersonAttributesDao
> > component I can share with you if you get stuck, but it's pretty easy to
> > implement PersonAttributesDao.
> > Okay. I think I am beginning to understand. Are you saying that I should
> > put all my attributes that I want returned here: <bean
> > id="ldapAuthenticationHandler"
> > class="org.jasig.cas.authentication.LdapAuthenticationHandler"
> > p:principalIdAttribute="uid"
> > c:authenticator-ref="authenticator">
> > <property name="principalAttributeMap">
> > <map>
> > <!--
> > | This map provides a simple attribute resolution mechanism.
> > | Keys are LDAP attribute names, values are CAS attribute
> > names.
> > | Use this facility instead of a PrincipalResolver if LDAP is
> > | the only attribute source.
> > -->
> > <entry key="ssoGUID" value="ssoGUID" />
> > <entry key="givenName" value="givenname" />
> > <entry key="sn" value="surname" />
> > <entry key="memberOf" value="memberOf" />
> > <entry key="uid" value="user" />
> > </map>
> > </property>
> > </bean> and also define a stub like this to use in place of <bean
> > id="attributeRepository"
> > class="org.jasig.services.persondir.support.StubPersonAttributeDao"
> > p:backingMap-ref="attrRepoBackingMap" /> <util:map
> > id="attrRepoBackingMap">
> > <entry key="uid" value="user" />
> > <entry key="ssoGUID" value="ssoGUID" />
> > <entry key="givenName" value="givenname" />
> > <entry key="sn" value="surname" />
> > <entry key="memberOf" value="memberOf" />
> > </util:map>
> > </bean> When I did this I end up getting back just the values I
> > specify in the stub, not the values of LDAP. It seems like I must be
> > getting close but I my understanding is lacking. I appreciate you
> > continuing to point me in the right direction. Thanks! Doug
> >
> > --
> > You are currently subscribed to [email protected] as:
> > [email protected]
> > To unsubscribe, change settings or access archives, see
> > http://www.ja-sig.org/wiki/display/JSG/cas-user
>
> --
> You are currently subscribed to [email protected] as:
> [email protected]
> To unsubscribe, change settings or access archives, see
> http://www.ja-sig.org/wiki/display/JSG/cas-user
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-user
