Managing Corporate Scripts

Corporate scripts are normal scripts that are assigned to a Container object instead of to a User object. They reduce administrative tasks. You can create a container for corporate scripts, place a corporate script there, then point all users to that script. All users in or directed to that corporate script get their settings from that corporate script.

Corporate scripts differ from other scripts in two ways:

Windows Application, Web, Startup, and Terminal Launcher scripts can all be implemented as corporate scripts.


Where to Locate Corporate Scripts

In a corporate environment, all of the applications deployed to the users should match. You can ensure this by using Novell® ZENworks®. This means that the scripts for the applications will be identical. In a large tree, this could mean putting a copy of all of the scripts into each User container. You can copied these scripts, but only as a block. If you then need to update a single script you would have to copy all of the scripts to each container.

To eliminate this administrative overhead, you can point all of the users to a single corporate-scripts container. To make searching easy, you set this container relatively high in the tree, partition it, and replicate it to all user locations. Afterwards, when an application is introduced or modified, you need to add or modify only the script in one container. The script is then replicated out to all users.

Because they are automatically rolled out to all User objects held in the Container object, corporate scripts simplify implementing and administering SecureLogin single sign-on. By using this method, you don't have to configure applications for each individual user in your organization. All users read and use the same scripts.


Inheritance and Redirection

A corporate script is defined on a Container object. Objects within and below that container inherit the script.

After you create a corporate script, you can use the Read Corporate Scripts From edit box in ConsoleOne, MMC, or SecureLogin Manager to point to and use that script.


The Corporate Script Location edit box in ConsoleOne

If you leave the Read Corporate Scripts From edit box empty, SecureLogin by default does the following:

When you specify a context in this field, SecureLogin applies the settings of this context only and doesn't read any parent objects. The settings for the object are redirected from the context you specify in the Read Corporate Scripts From edit box to the object.

Scenario. The VMP company has 100 employees in the RDev department. VMP is a Container object, and RDev is a child Container object. Employees in the RDev department inherit settings from the VMP container.

Ten employees in the RDev department require special SecureLogin settings for the AZ application. You create a new Container object (RDevAZapps) under the VMP container. You log in as admin, select the RDevAZapps Container object, then select Properties > Novell SecureLogin > General Settings. You create a script for the application that the 10 employees will use.

Next, you select one of the 10 users and access the Advanced Settings tab. You browse to and select the new RDevAZapp container, then click OK. That user now gets settings for the AZ application from the script in the RDevAZapps container. The settings have been redirected from the RDev container to the RDevAZapps container. You redirect all 10 users.

Inheritance of SecureLogin data stops at the container or OU. Redirected containers or OUs don't inherit settings, enabled applications, or password rules that an Organizational Policy container or OU inherits from another container or OU.


Creating a Corporate Script: MMC or ConsoleOne

  1. Log in as Admin or an Admin equivalent.

  2. Navigate to the Container object where you want to create the corporate script.

  3. Right-click the Container object, then click Properties.

  4. Click Novell SecureLogin > General Settings > Applications > New.


    The Novell SecureLogin tab

    To use a prebuilt script, go to Step 5.

    To create a new script for an application, without using a prebuilt script, go to Step 6.

  5. (Optional) Add a prebuilt script to the application list.

    1. Click Select a Prebuilt Application, scroll to and select the desired application, then click OK.


      The radio button to select an application that has a prebuilt script

    2. In the Applications [application name] dialog box, save the script by clicking OK.

      After you click OK, you return to the Applications tab. Go to Step 7.

  6. (Optional) Add an application that doesn't have a script.

    1. From the New Application dialog box, click New Application.


      The radio button to add a new application

    2. Type a name in the first text field.

      For a Windows application, type the executable filename. For a Web application, type the URL. This name will display in the Description column on the Applications tab.


      The dialog box to enable a new application for single sign-on

    3. Select a type (for example, Java, Startup, Windows) from the drop-down list, then click OK.

  7. In the Applications tab, save the data by clicking Apply.

    The next time the selected application is launched, users will be prompted to enter their credentials.Whenever the application is subsequently launched, SecureLogin enters the users' credentials, as though the login process has been eliminated.

  8. Click the newly added application, click Edit, then click Script.

  9. Add or edit a script.

    For hands-on experience with basic scripting, work through the tutorial in the chapter, "Practicing Your Scripting Skills" in Nsure SecureLogin 3.51.2 Scripting Guide.

    For script commands, with accompanying example scripts and explanations, see chapter, "SecureLogin Commands"in Nsure SecureLogin 3.51.2 Scripting Guide.


Creating a Corporate Script: SecureLogin Manager

  1. Log in to the workstation as Admin or equivalent.

  2. Run SecureLogin.

  3. Launch SecureLogin Manager.

    Run slmanager.exe, found in the \securelogin\client\tools directory.

  4. Type the distinguished name of the object where you want to create a corporate script.


    The dialog box to access SecureLogin Manager

    You logged in to the workstation as Admin or equivalent, then accessed SecureLogin as that user. SecureLogin Manager uses the rights of the authenticated user to create the corporate script for the context or object that you specify.

    For AD and LDAP, use LDAP naming conventions (for example, cn=admin,cd=akranes). For eDirectory, use eDirectory conventions (for example, cn=admin.o=akranes).

  5. Click OK.


Exempting an Object from a Corporate Script

Local scripts take precedence over corporate scripts. Occasionally, you might want a particular user to use a script other than the corporate script. To do this, create a local script for the application at the User object level.

If you have a corporate script for an application, and you have a user who should not have that application single sign-on enabled, create a blank local script for the application at the User object level.

You can also use this procedure to exempt a Container object from corporate scripts inherited from Container objects that are higher in the directory tree.