title: ORASSO: Going beyond the default user container link: https://onemoretech.wordpress.com/2011/02/10/orasso-going-beyond-the-default-user-container/ author: lembobro description: post_id: 69 created: 2011/02/10 12:49:46 created_gmt: 2011/02/10 12:49:46 comment_status: open post_name: orasso-going-beyond-the-default-user-container status: publish post_type: post

ORASSO: Going beyond the default user container

We’ve been using OID (Oracle Internet Directory) user entries lying outside the default “cn=users,dc=example,dc=com” container for administrative purposes for some time. Recently someone needed to be able to log in via ORASSO using one of these. This resulted in a mad scramble through the product documentation. Reconfiguratiion notes after the jump.

So here’s what we had:

Most user entries were set up in the default “cn=users,dc=example,dc=com” container.

A few admin accounts that we needed to exempt from the default password policy were created in a “cn=special users,dc=example,dc=com” container.

Now we needed to let the users under that “special users” container log in using ORASSO (Oracle 10g Application Server SSO).

The documentation outlined the steps.

Basically the default user search base for applications had to be changed from “cn=users,dc=example,dc=com” to what the doc writers call the “Lowest Common User Search Base”, in our case “dc=example,dc=com” — the realm root.

To make all that happen we had to:

1. Apply the appropriate access control instructions (aci) to our “special users” container. I did that by grabbing the acis from the “cn=users” container and stripping out the pwdpolicysubentry attribute before applying to my new container, since I didn’t want a password policy to apply to the entries underneath.

ldapsearch -x -LLL -h oid.example.com -D "cn=orcladmin" -W -b "cn=users,dc=example,dc=com" -s base "objectclass=*" orclaci orclentrylevelaci >useracl.ldif.

Once I had my LDIF dump of the access controls I just had to add a “changetype: modify” and the “add: orclentrylevelaci” and “orclaci” statements in the right places.

I won’t reproduce the whole thing here, but this snippet should help:

dn: cn=Special Users, dc=example,dc=com
changetype: modify
add: orclaci
orclaci: access to entry by group="cn=UserProxyPrivilege, cn=Groups,cn=OracleC
 ontext,dc=example,dc=com" (browse, proxy)

As near as I can tell the only acl necessary to make SSO work is the one that allows the UserProxyPrivilege group to browse the subcontainer, but because I had to allow my admin personnel to unlock and change passwords for these special accounts, I left in most of the acis that were found covering “cn=users”. If you really wanted to lock things down you’d remove everything but the first aci shown or remove any “add”, “delete”, “write” or “selfwrite” directives.

2. Go into the Delegated Administration Service (DAS) console as a realm admin (e.g. orcladmin), click on the Configuration tab and change the “User Search Base” to the realm base dn, “dc=example,dc=com”. This will change the orclcommonusersearchbase in “cn=Common,cn=OracleContext,dc=example,dc=com” from “cn=Users,dc=example,dc=com” to “dc=example,dc=com”.

3. Refresh ORASSO. The doc links to the steps for this, which are

(a) Go to $ORACLE_HOME/sso/admin/plsql/sso and connect to the infrastructure database as the ORASSO schema user. Once in, execute the ssoreoid script.

sqlplus ORASSO/[orasso password from OID]@infradbservicename SQL > @ssoreoid

(b) Restart OSSO. I just did an opmnctl stopall and then opmnctl startall as the system user (with the SSO environment already sourced).

Copyright 2004-2019 Phil Lembo