Portal LDAP permission problems: Login causing "Insufficient access"
387135Dec 10 2004 — edited Feb 2 2005Hello,
We have OID / Portal / 10gAS version 9.0.4.1 in development and production. We are using the 10gAS as a J2EE webapp server and the OID server as an LDAP server. Portal was working, but we had to make modifications to the default ACP's in OID for our DIT to be secure.
Bottom line:
Logging in as a user to portal yields:
" Unexpected error encountered in wwsec_app_priv.process_signon (User-Defined Exception) (WWC-41417)
An exception was raised when accessing the Oracle Internet Directory: 50: Insufficient access
Details
Operation: dbms_ldap_utl.get_group_membership. (WWC-41743)
"
Looking back at the ACL trace yields the following:
BEGIN
2004/12/10:08:57:25 * ServerWorker:4 * ConnID:31 * OpId:1 * OpName:search
gslsfbiDumpSubscribedGroups: Op. ID: <1> Subscribed Orclprivilege Groups for the user DN: <orclapplicationcommonname=portal.040405.1647,cn=portal,cn=products,cn=oraclecontext>
08:57:25 * Op. ID: <1> Group0 for the user DN:<cn=authenticationservices,cn=groups,cn=oraclecontext>
08:57:25 * Op. ID: <1> Group1 for the user DN:<cn=userproxyprivilege,cn=groups,cn=oraclecontext>
08:57:25 * Op. ID: <1> Group2 for the user DN:<cn=oracledascreateuser,cn=groups,cn=oraclecontext>
08:57:25 * Op. ID: <1> Group3 for the user DN:<cn=oracledascreategroup,cn=groups,cn=oraclecontext>
08:57:25 * Op. ID: <1> Group4 for the user DN:<cn=common group attributes,cn=groups,cn=oraclecontext>
08:57:25 * Op. ID: <1> Group5 for the user DN:<cn=oracledasconfiguration,cn=groups,cn=oraclecontext,dc=tekelec,dc=com>
08:57:25 * Op. ID: <1> Group6 for the user DN:<cn=authenticationservices,cn=groups,cn=oraclecontext,dc=tekelec,dc=com>
08:57:25 * Op. ID: <1> Group7 for the user DN:<cn=userproxyprivilege,cn=groups,cn=oraclecontext,dc=tekelec,dc=com>
08:57:25 * Op. ID: <1> Group8 for the user DN:<cn=oracledascreateuser,cn=groups,cn=oraclecontext,dc=tekelec,dc=com>
08:57:25 * Op. ID: <1> Group9 for the user DN:<cn=oracledascreategroup,cn=groups,cn=oraclecontext,dc=tekelec,dc=com>
08:57:25 * Op. ID: <1> Group10 for the user DN:<cn=common group attributes,cn=groups,cn=oraclecontext,dc=tekelec,dc=com>
08:57:25 * gslsfbiDumpSubscribedGroups: Op. ID: <1> Subscribed Orclacp Groups for the user DN: <orclapplicationcommonname=portal.040405.1647,cn=portal,cn=products,cn=oraclecontext>
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) Entry DN:(uid=saitken,cn=users,dc=tekelec,dc=com)
08:57:25 * gslfacZEvaluate_Filter: Operation id:(1) User DN: (orclapplicationcommonname=portal.040405.1647,cn=portal,cn=products,cn=oraclecontext)
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) Visiting ACP at: (cn=users,dc=tekelec,dc=com)
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) Filter Accees denied by ACP: (cn=users,dc=tekelec,dc=com)
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) User being Privileged group member, Evaluation continues
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) Visiting ACP at: (dc=tekelec,dc=com)
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) Visiting ACP at: (dc=com)
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) Filter Accees denied by ACP: (dc=com)
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) User being Privileged group member, Evaluation continues
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) Visiting ACP at: (cn=root)
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) Filter Accees denied by ACP: (cn=root)
08:57:25 * gslfacZEvaluate_Filter:Operation id:(1) User being Privileged group member, Evaluation continues
08:57:25 * gslfacZEvaluate_Filter: Op id:(1) Filter Access to entry (uid=saitken,cn=Users,dc=tekelec,dc=com) not allowed
08:57:25 * INFO: gslfrsDSendSearchEntry : Access to filter attributes not allowed
END
The interpretation of this is that the service account "(orclapplicationcommonname=portal.040405.1647,cn=portal,cn=products,cn=oraclecontext)" does not have sufficient privileges to "Op id:(1) Filter Access to entry" or, "Browse the entry" with the DN "uid=saitken,cn=Users,dc=tekelec,dc=com". This is the user I am attempting to log in as.
The current ACP entries against the "users" container that is causing the deny.. "Filter Accees denied by ACP: (cn=users,dc=tekelec,dc=com)" seems to be the problem.
The real issue is that "entry level" access should be possible by all users in the system. The ACP entries I have on the 'users' entry / container is as follows:
- orclaci: access to entry by self (browse)
- orclaci: access to entry filter=(objectclass=tekuser) by * (browse) by group="cn=service accounts,cn=groups,dc=tekelec,dc=com" (browse,delete) by group="cn=it - user admins,cn=groups,dc=tekelec,dc=com" (browse,delete)
- orclaci: access to entry filter=(objectclass=inetorgperson) by group="cn=oracledascreateuser, cn=groups,cn=OracleContext,dc=tekelec,dc=com" added_object_constraint=(objectclass=orcluser*) (browse,add) by group="cn=oracledasdeleteuser, cn=groups,cn=OracleContext,dc=tekelec,dc=com" (browse,delete) by group="cn=oracledasedituser, cn=groups,cn=OracleContext,dc=tekelec,dc=com" (browse) by group="cn=UserProxyPrivilege, cn=Groups,cn=OracleContext,dc=tekelec,dc=com" (browse, proxy) by dn="orclApplicationCommonName=DASApp, cn=DAS, cn=Products,cn=oraclecontext" (browse,proxy) by self (browse, nodelete, noadd) by group="cn=Common User Attributes, cn=Groups,cn=OracleContext,dc=tekelec,dc=com" (browse)
All users under the "Users" container are of objectclass 'tekuser'. The last ACP point was massaged from the original install of Portal.
The real clincher that I don't understand is that the single entry "access to entry filter=(objectclass=tekuser) by * (browse)" should be allowing browse access to my entry to everyone! (Including the service account for portal!)
So, as I wind around this ball of wax, I deparately seek assistance. I understand the complexities of ACP's and know of a few problems, but nothing that would cause this.
Does anyone have any insight? Any feedback is greatly appreciated!
The best thing that I could have right now would be a spec (or requirements) of permission configuration against an LDAP server (or OID) for Portal to perform it's normal tasks. Unfortunately, I have yet to find any docos on ACL requirements of Portal. :(
-Sean