Environment
Novell SecureLogin
NSL6.0.x
NSL6.1.x
iManager 2.7
SSO plugin from NSL6.1 fix 12
NSL6.0.x
NSL6.1.x
iManager 2.7
SSO plugin from NSL6.1 fix 12
Situation
Customer
wants to modify an application definition received through corporate
redirection for all users in a given container. Users in this
container should receive their applications and settings through
corporate redirection, EXCEPT for the one modified application which
they inherit from their own container.
It is currently not
possible to override corporate redirection by making a change at the
container level. Application definitions modified on user objects
will override corporate redirection, changes made at the container
level will not.
With corporate redirection set on a container,
all applications are received either from the container to which the
users have been redirected, or from the user's own eDirectory object.
Resolution
This is working as designed. Corporate redirection by definition
is meant to override settings made on the container.
Additional Information
Steps to duplicate:
1. Set corporate redirection on a container. For example, set redirection for OU=users to OU=NSL
2. Go into the applications tab of the SSO plugin for the redirected container (ou=users), and note the "source" column. All applications will show the redirection; source will be ou=NSL.
3. Modify an application definition that has come from ou=NSL. The source for that application will then show as ou=users as expected.
4. Open the sso plugin and browse to a user in the redirected container (cn=chuckles.ou=users). The source column for the application just edited will show as OU=NSL, not as ou=users.
5. Login as the user (chuckles.users) and launch securelogin. Open the “manage logins” utility on the workstation, and look at the application. The application definition received will be that from ou=NSL, not the one from ou=users.
6. Go back into iManager and open the applications tab of the sso plugin for the user (cn=chuckles.ou=users), and edit the desired application definition. Note the "source" column now shows that application coming from “chuckles.users.”
7. Re launch SecureLogin logged as user chuckles.usess. The application definition received will be that from cn=chuckles.ou=users, not the one from ou=NSL.
Conclusion: users in redirected containers will receive ALL applications and settings from the container to which they have been redirected, EXCEPT for changes made directly on the user object itself. Changes made on the users' container will not flow down to the user.
1. Set corporate redirection on a container. For example, set redirection for OU=users to OU=NSL
2. Go into the applications tab of the SSO plugin for the redirected container (ou=users), and note the "source" column. All applications will show the redirection; source will be ou=NSL.
3. Modify an application definition that has come from ou=NSL. The source for that application will then show as ou=users as expected.
4. Open the sso plugin and browse to a user in the redirected container (cn=chuckles.ou=users). The source column for the application just edited will show as OU=NSL, not as ou=users.
5. Login as the user (chuckles.users) and launch securelogin. Open the “manage logins” utility on the workstation, and look at the application. The application definition received will be that from ou=NSL, not the one from ou=users.
6. Go back into iManager and open the applications tab of the sso plugin for the user (cn=chuckles.ou=users), and edit the desired application definition. Note the "source" column now shows that application coming from “chuckles.users.”
7. Re launch SecureLogin logged as user chuckles.usess. The application definition received will be that from cn=chuckles.ou=users, not the one from ou=NSL.
Conclusion: users in redirected containers will receive ALL applications and settings from the container to which they have been redirected, EXCEPT for changes made directly on the user object itself. Changes made on the users' container will not flow down to the user.