[prev in list] [next in list] [prev in thread] [next in thread]
List: forgerock-openam
Subject: [OpenAM] LDAP Repository forgetting parts of LDAP DN ?
From: jah () progress ! com (Jari Ahonen)
Date: 2011-10-25 18:55:25
Message-ID: F908222B8FF240489301FD889454065302C797E356 () PSCMAIL03 ! bedford ! progress ! com
[Download RAW message or body]
Thanks Peter,
I managed to find where this is all going wrong (LDAPv3Repo.java lines 5540-5655) and \
it looks like the workaround of clearing out the user container setting should work \
fine.
- Jari
-----Original Message-----
From: openam-bounces@forgerock.org [mailto:openam-bounces at forgerock.org] On Behalf \
Of Major P?ter
Sent: Tuesday, October 25, 2011 8:02 PM
To: Users
Subject: Re: [OpenAM] LDAP Repository forgetting parts of LDAP DN ?
IF you're not using the group container, then setting the basedn to simply \
ou=people,etc.. should be a good workaround, yes.
Peter
2011-10-25 19:50 keltez?ssel, Jari Ahonen ?rta:
> Hi Peter,
>
> Does this also imply that if I clear out the People container settings then \
> everything should work ? That would be an acceptable workaround until the real \
> issue gets fixed.
> - Jari
>
> -----Original Message-----
> From: openam-bounces at forgerock.org
> [mailto:openam-bounces at forgerock.org] On Behalf Of Major P?ter
> Sent: Tuesday, October 25, 2011 7:42 PM
> To: Users
> Subject: Re: [OpenAM] LDAP Repository forgetting parts of LDAP DN ?
>
> 2011-10-25 18:56 keltez?ssel, Jari Ahonen ?rta:
> > Okay so should I create a bug report for this in Bugster ?
>
> yes please
>
> > Is the root problem here that the IdRepo API ignores any LDAP \
> > containers/structure below the configured user account root container ?
>
> if the LDAP People container setting is used anything under the container will be \
> ignored..
> Peter
>
> >
> > - Jari
> >
> >
> > -----Original Message-----
> > From: openam-bounces at forgerock.org
> > [mailto:openam-bounces at forgerock.org] On Behalf Of Major P?ter
> > Sent: Tuesday, October 25, 2011 5:44 PM
> > To: Users
> > Subject: Re: [OpenAM] LDAP Repository forgetting parts of LDAP DN ?
> >
> > This is an old problem, just haven't been reported yet AFAIK/IIRC.
> >
> > Peter
> >
> > 2011-10-25 15:58 keltez?ssel, Jari Ahonen ?rta:
> > > Thanks Peter,
> > >
> > > Is this something that is already known (and possibly fixed) or are we looking \
> > > at a new problem ?
> > > - Jari
> > >
> > > -----Original Message-----
> > > From: openam-bounces at forgerock.org
> > > [mailto:openam-bounces at forgerock.org] On Behalf Of Major P?ter
> > > Sent: Tuesday, October 25, 2011 3:50 PM
> > > To: Users
> > > Subject: Re: [OpenAM] LDAP Repository forgetting parts of LDAP DN ?
> > >
> > > Hi,
> > >
> > > this is a bug in the IdRepo API, federation/realm settings are not related to \
> > > this.
> > > Peter
> > >
> > > 2011-10-25 15:44 keltez?ssel, Jari Ahonen ?rta:
> > > > Hi,
> > > >
> > > > Setting NameIDFormat to EmailAddress instead of Transient in the
> > > > SAML2 request causes similar error with following stack:
> > > >
> > > > libSAML2:10/25/2011 09:35:23:111 AM EDT: Thread[http-8443-4,5,main]
> > > > ERROR: IDPSSOFederate.doSSOFederate:
> > > >
> > > > Unable to do sso or federation.
> > > >
> > > > com.sun.identity.saml2.common.SAML2Exception: Plug-in
> > > > com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo:
> > > >
> > > > Unable to find entry: uid=xxx,ou=people,o=organization
> > > >
> > > > at
> > > > com.sun.identity.saml2.common.AccountUtils.getAccountFederation(Acc
> > > > o
> > > > u
> > > > n
> > > > tUtils.java:141)
> > > >
> > > > at
> > > > com.sun.identity.saml2.profile.IDPSSOUtil.getSubject(IDPSSOUtil.java:
> > > > 1
> > > > 416)
> > > >
> > > > at
> > > > com.sun.identity.saml2.profile.IDPSSOUtil.getAssertion(IDPSSOUtil.j
> > > > a
> > > > v
> > > > a
> > > > > 854)
> > > >
> > > > at
> > > > com.sun.identity.saml2.profile.IDPSSOUtil.getResponse(IDPSSOUtil.java:
> > > > 676)
> > > >
> > > > at
> > > > com.sun.identity.saml2.profile.IDPSSOUtil.sendResponseToACS(IDPSSOU
> > > > t
> > > > i
> > > > l
> > > > .java:360)
> > > >
> > > > at
> > > > com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOF
> > > > e
> > > > d
> > > > e
> > > > rate.java:837)
> > > >
> > > > at
> > > > com.sun.identity.saml2.profile.IDPSSOFederate.doSSOFederate(IDPSSOF
> > > > e
> > > > d
> > > > e
> > > > rate.java:123)
> > > >
> > > > at
> > > > org.apache.jsp.saml2.jsp.idpSSOFederate_jsp._jspService(idpSSOFeder
> > > > a
> > > > t
> > > > e
> > > > _jsp.java:112)
> > > >
> > > > It seems that the system can't resolve the correct user account
> > > > when it is trying to retrieve the NameID attribute from LDAP. It
> > > > all worked first with SAML2 IdP because the assertion was done with transient \
> > > > NameID.
> > > > I'm pretty sure I had this all working when I had everything in the "/"
> > > > realm. Note that the LDAP server that has the accounts is only
> > > > configured on this realm, not in the "/" realm.
> > > >
> > > > - Jari
> > > >
> > > > *From:*openam-bounces at forgerock.org
> > > > [mailto:openam-bounces at forgerock.org] *On Behalf Of *Jari Ahonen
> > > > *Sent:* Tuesday, October 25, 2011 2:33 PM
> > > > *To:* Users
> > > > *Subject:* Re: [OpenAM] LDAP Repository forgetting parts of LDAP DN ?
> > > >
> > > > Setting debug mode on federation components produces this stack
> > > > trace when the IdP can't find the user account:
> > > >
> > > > libWSFederation:10/25/2011 08:15:49:915 AM EDT:
> > > > Thread[http-8443-4,5,main]
> > > >
> > > > WSFedServlet.doGet: Can't process action
> > > >
> > > > com.sun.identity.wsfederation.common.WSFederationException: Plug-in
> > > > com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo: Unable to find entry:
> > > > uid=xxx,ou=people,o=organization
> > > >
> > > > at
> > > > com.sun.identity.wsfederation.plugins.DefaultIDPAccountMapper.getNa
> > > > m
> > > > e
> > > > I
> > > > D(DefaultIDPAccountMapper.java:117)
> > > >
> > > > at
> > > > com.sun.identity.wsfederation.servlet.IPSigninRequest.sendResponse(
> > > > I
> > > > P
> > > > S
> > > > igninRequest.java:334)
> > > >
> > > > at
> > > > com.sun.identity.wsfederation.servlet.IPSigninRequest.process(IPSig
> > > > n
> > > > i
> > > > n
> > > > Request.java:177)
> > > >
> > > > at
> > > > com.sun.identity.wsfederation.servlet.WSFederationServlet.doGet(WSF
> > > > e
> > > > d
> > > > e
> > > > rationServlet.java:74)
> > > >
> > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
> > > >
> > > > at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
> > > >
> > > > - Jari
> > > >
> > > > *From:*openam-bounces at forgerock.org
> > > > <mailto:openam-bounces at forgerock.org>
> > > > [mailto:openam-bounces at forgerock.org]
> > > > <mailto:[mailto:openam-bounces at forgerock.org]> *On Behalf Of *Jari
> > > > Ahonen
> > > > *Sent:* Tuesday, October 25, 2011 12:44 PM
> > > > *To:* Users
> > > > *Subject:* Re: [OpenAM] LDAP Repository forgetting parts of LDAP DN ?
> > > >
> > > > I did some more testing and I can succesfully access a SAML2 IdP
> > > > configured in the same realm so this looks like some kind of bug in
> > > > the WS-Fed IdP implementation. Both SAML2 and WS-Fed IdP are
> > > > configured to send email address in the assertion so this problem
> > > > shouldn't be related to the actual assertion content.
> > > >
> > > > Any ideas ?
> > > >
> > > > - jah
> > > >
> > > > *From:*openam-bounces at forgerock.org
> > > > <mailto:openam-bounces at forgerock.org>
> > > > [mailto:openam-bounces at forgerock.org]
> > > > <mailto:[mailto:openam-bounces at forgerock.org]> *On Behalf Of *Jari
> > > > Ahonen
> > > > *Sent:* Tuesday, October 25, 2011 12:13 PM
> > > > *To:* openam at forgerock.org<mailto:openam at forgerock.org>
> > > > *Subject:* [OpenAM] LDAP Repository forgetting parts of LDAP DN ?
> > > >
> > > > Hi,
> > > >
> > > > I've ran into a strange issue with OpenAM 9.5.3.
> > > >
> > > > I have configured a realm "Employees" with an LDAP repository that
> > > > has user accounts in various OUs under structure like this:
> > > >
> > > > uid=user1, ou=region1, ou=employees, ou=people, o=organization
> > > >
> > > > uid=user2, ou=region1, ou=employees, ou=people, o=organization
> > > >
> > > > uid=user3, ou=region2, ou=employees, ou=people, o=organization
> > > >
> > > > uid=user4, ou=region2, ou=employees, ou=people, o=organization
> > > >
> > > > .
> > > >
> > > > uid=usern, ou=regionn, ou=employees, ou=people, o=organization
> > > >
> > > > In other words the user accounts in LDAP are divided into OUs based
> > > > on the region and role. This structure is there to make it easier
> > > > to distinguish between different types of accounts.
> > > >
> > > > Now what happens is that if I login as a user everything goes fine
> > > > and I get a session with universal ID like
> > > > "id=userx,ou=user,o=employees,ou=services,dc=opensso,dc=java,dc=net".
> > > >
> > > > However, when I now try to access a local WS-Fed IdP I get an
> > > > IdRepo exception when user attributes need to be retrieved from LDAP:
> > > >
> > > > ERROR: IdRepoDataStoreProvider.getAttribute(1): IdRepo exception
> > > >
> > > > Message:Plug-in com.sun.identity.idm.plugins.ldapv3.LDAPv3Repo:
> > > > Unable to find entry: uid=userx,ou=people,o=organizatoin
> > > >
> > > > It seems the system now tries to look for the account only in the
> > > > configured user container (People Container settings in the LDAP
> > > > repository properties) and ignores the entire OU structure below it.
> > > >
> > > > Is this some kind of misconfiguration on my part or is this some
> > > > kind of a problem/limitation with the user DN handling in OpenAM ?
> > > > Also, how can I troubleshoot this further to find out where exactly
> > > > the middle components of the DN are forgotten ? Setting IdRepo
> > > > debug to message level did not reveal much more than what I already
> > > > knew (that the system is using wrong DN for fetching account attributes).
> > > >
> > > > Thanks.
> > > >
> > > > - Jari
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > OpenAM mailing list
> > > > OpenAM at forgerock.org
> > > > https://lists.forgerock.org/mailman/listinfo/openam
> > > _______________________________________________
> > > OpenAM mailing list
> > > OpenAM at forgerock.org
> > > https://lists.forgerock.org/mailman/listinfo/openam
> > > _______________________________________________
> > > OpenAM mailing list
> > > OpenAM at forgerock.org
> > > https://lists.forgerock.org/mailman/listinfo/openam
> > >
> > _______________________________________________
> > OpenAM mailing list
> > OpenAM at forgerock.org
> > https://lists.forgerock.org/mailman/listinfo/openam
> > _______________________________________________
> > OpenAM mailing list
> > OpenAM at forgerock.org
> > https://lists.forgerock.org/mailman/listinfo/openam
> >
> _______________________________________________
> OpenAM mailing list
> OpenAM at forgerock.org
> https://lists.forgerock.org/mailman/listinfo/openam
> _______________________________________________
> OpenAM mailing list
> OpenAM at forgerock.org
> https://lists.forgerock.org/mailman/listinfo/openam
>
_______________________________________________
OpenAM mailing list
OpenAM at forgerock.org
https://lists.forgerock.org/mailman/listinfo/openam
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic