When SecureLogin configurations (scripts, settings, policy etc) are deployed to the user community, they are typically applied to a container object and all the users underneath inherit the script info from this location.

This works great, but inevitably there is a need for some “one off” users to have different configuration than the general population. This could be because they are admins, or perhaps an application is used differently by one user then all the others. Or maybe there is a need to pilot a script to a small group prior to a full deployment.

One solution to these “one offs” situations is to apply the change directly to the individual user object. But this can be difficult to administrate and even more difficult to maintain. There is no easy way to deploy these changes and no way to check what users have these none standard configurations.

A better way to handle this is to use corporate redirection. Corporate redirection can be set from the advanced tab in a SecureLogin administration tool. Here you can point the user to any directory object. Once set, when this user starts SecureLogin, the configuration information will be obtained from this object rather than the user id parent object.

As an example of using this feature say you want to pilot a new script for application App1.exe to 10 users and let them test it prior to deploying it to the general community. In this example all your current SecureLogin scripts and settings are applied to OU=Users and inherited by all users beneath it.

To pilot the script with cooperate redirection the steps would be;

1- Create OU=Pilot beneath OU=Users.
2- Copy all current SecureLogin configuration from OU=Users to OU=pilot.
3- In OU=pilot put the App1.exe script you want to pilot
4- On the 10 users you want to pilot point the corporate redirection to OU=Pilot,ou=Users.

These 10 users will now have the same SecureLogin configuration as all other users except for the App1.exe script being tested. When the pilot is complete you can copy the app1.exe script to OU=Users and remove the corporate redirection from these user objects.

One of the big advantages of using corporate redirection for these types of “one off” settings is, due to the type of attributes that holds the data, these settings can be searched and modified via ldap.

If you want to search for users who have corporate redirection set, you can use ldapsearch;

ldapsearch -h host -D cn=admin,ou=users,o=corp -w password protocom-sso-profile=* protocom-sso-profile


If in the example above you want to update the 10 users pilot quickly, or expand the pilot to 100 users, you can create an ldif file like the one below. This way you can update the users quickly and accurately.

dn: cn=JohnDoe,ou=users,o=corp
changetype: modify
replace: protocom-SSO-Profile
protocom-SSO-Profile: ou=pilot,ou=users,o=corp#0#

When you are done with the pilot and want to remove corp redirection from these users use the ldif sample below to do this quickly. You can also have this ldif file ready at the start of the pilot. That way if you need to quickly back out the change you are ready.

dn: cn=JohnDoe,ou=users,o=corp
changetype: modify
delete: protocom-SSO-Profile

Notes:

-If a user is using corporate redirection they no longer inherit information from the parent. All desired settings need to be placed directly on the redirection object.

-With eDirectory the object a user points to for redirection should be in the same partition as the user object.

-With eDirectory to use the ldap suggestions above the SecureLogin schema mapping must be done to the host server ldap_group object. This is done by running the ldapschema tool that comes with SecureLogin.