1 Securing Logon Manager

This chapter describes how to securely deploy Logon Manager.

1.1 Deploying Logon Manager in Directory Environments

You have the choice to deploy Logon Manager in a directory environment, such as Active Directory, AD LDS (ADAM), Oracle Internet Directory, and many third-party LDAP-compliant directories, which enables the delivery of single sign-on capability to any machine on the network through central storage of application credentials, templates, and policies. Users synchronize with the directory to download these items and update their credential stores with new or changed usernames and passwords.

Adding Logon Manager to your existing directory environment provides the following benefits:

  • Logon Manager leverages the existing user accounts, groups, and native directory permissions (ACLs) without the need to manage these items separately or synchronize them with another directory or database.

  • Logon Manager data is automatically protected by your existing backup, failover, and disaster recovery plans.

  • No dedicated servers or server-side processes are required; Logon Manager's scalability and performance depend solely on the capacity and robustness of your existing directory infrastructure.

  • Administrators are not burdened with additional administrative tasks or the need to learn new tools or concepts. Delegated administration of Logon Manager is achieved through the native capabilities of the directory.

A directory also enables the organization of Logon Manager templates and policies into a highly visual hierarchy. While you can use a flat model if your environment calls for it, a properly set-up hierarchy can help maintain top directory, Agent, and network performance, as well as simplify Logon Manager administration and improve data security by permitting more efficient access control.

1.1.1 How Logon Manager Extends Your Active Directory Schema

Before Logon Manager can store data in Active Directory, you must instruct Logon Manager to extend your Active Directory schema. The schema extension consists of adding four object classes and setting the appropriate permissions so that objects of those types can be created, read, modified, and deleted. Existing classes and attributes are not modified in any way. If you decide to allow Logon Manager to store application credentials under user objects (a recommended best practice), Logon Manager will also apply the permissions required by this feature.

1.1.2 How Logon Manager Synchronizes with Active Directory

The Logon Manager Agent uses the Active Directory synchronizer plug-in to communicate with Active Directory. When properly configured, synchronization occurs whenever one of the following events takes place:

  • The Logon Manager Agent starts.

  • Application credentials are added, modified, or deleted by the end-user.

  • The machine running the Agent acquires an IP address or its existing IP address changes. (if Logon Manager is configured to respond to these events).

  • The auto-synchronize interval elapses (if configured).

  • The user initiates synchronization via Logon Manager's "Refresh" function.

  • A script initiates synchronization using a command-line parameter.

During synchronization, the Logon Manager Agent traverses the Logon Manager tree and loads the contents of the sub-containers to which the current user has been granted access; it also synchronizes any credentials that have been added, modified, or deleted since the last synchronization.

1.1.3 How Logon Manager Handles and Stores Application Credentials

Logon Manager encrypts application credentials using a unique key generated when the user completes the First-Time Use (FTU) wizard. The credentials remain encrypted at all times, including in the Agent's local cache, the directory, and while in transit over the network. Logon Manager only decrypts credentials (to memory, never to disk) when a configured application requests logon, and wipes the target memory location as soon as the logon request completes. The amount of data Logon Manager stores per enabled application and per user is trivial (measurable in bytes and small kilobytes).

1.1.4 Further Reading

An in-depth discussion of the Logon Manager software architecture is beyond the scope of this guide. To obtain Oracle white papers containing additional information, contact your Oracle representative.

1.2 Designing the Logon Manager Directory Sub-Tree

Logon Manager gives you the freedom to set up the directory structure to best fit the needs of your organization. Specifically, you have the choice to store your data in a flat model, or create a hierarchy. While a flat model works fine for small deployments, growing and large deployments should utilize a hierarchy from the very beginning. The exact structure of your sub-tree will depend on the following factors:

  • Number of users

  • Number of applications you want Logon Manager to support

  • Robustness of the existing infrastructure

  • Structure of your organization

Always follow Microsoft's best practices for Active Directory design and implementation described in the following article:

http://technet.microsoft.com/en-us/library/bb727085.aspx

1.2.1 Guidelines for Structuring the Sub-Tree

Oracle recommends that you set up your sub-tree as a hierarchy by following the guidelines below:

  • Use OUs to group templates and policies by category, such as department or division, according to the structure of your organization.

  • Control access at the OU level.

  • Disable inheritance and grant no user rights at the root of the Logon Manager sub-tree, unless your environment dictates otherwise.

When set up this way, a hierarchy provides the following benefits:

  • Highly visual and self-documenting tree structure. When you view your sub-tree in a directory browser, the sub-tree structure is self-descriptive and easy to follow.

  • No unwanted inheritance of rights. Users will not natively inherit rights to sub-OUs you don't want them to access. This eliminates the need to explicitly deny unwanted access rights that are being passed down the tree.

  • Robust network, Agent, and directory performance. Typically, users who download large numbers of templates and policies generate more network traffic and a higher load on the directory than users who only download items relevant to their jobs. Grouping conserves your environment's resources and improves Agent response time.

  • Distributed administrative tasks. Your templates are organized into easily controllable sets, and access rights determine who can manage which templates. You also have the ability to implement rights-based version control of your templates.

  • Low administrative overhead. Controlling access at the template level requires setting permissions for each individual template via the Logon Manager Administrative Console; controlling access at the OU level is achieved via delegated administration using Microsoft and third-party management tools.

In our sample scenario, users from the Portland division do not need access to applications used by the Sacramento division, and vice versa; therefore, each division's templates and policies live in dedicated sub-OUs under the root and one division cannot access another division's sub-OU. In the end, your environment will dictate the specifics of your implementation.

Figure 1-1 depicts a sample Logon Manager sub-tree whose design reflects the above best practices.

Figure 1-1 Recommended Logon Manager sub-tree design

Surrounding text describes Figure 1-1 .

Note:

Oracle highly recommends that you store templates and policies in individual OUs. To do this, you must enable the use of configuration objects as described in Use Configuration Objects (Active Directory Only).

If you are starting out with a flat model, but expect the number of users and provisioned applications to grow, create a sub-container under the root and use it to store your templates and policies as a flat file until you are ready to transition to a hierarchy. Monitor the performance of your environment as you add more users and provision more applications, and transition to a hierarchy sooner rather than later to minimize the required effort.

1.3 Achieving a Secure Configuration of Logon Manager

The behavior of the Logon Manager Agent, including its interaction with the directory, is governed by settings configured and deployed to the end-user machine by the Logon Manager administrator using the Administrative Console. The settings fall into one of the following categories:

  • Global Agent settings are the "local policy" for the Agent; they are stored in the Windows registry on the end-user machine and are included in the Logon Manager MSI package to provide the Agent with an initial configuration during deployment. Global Agent settings are stored in HKEY_LOCAL_MACHINE\Software\Passlogix (32-bit systems) or HKEY_LOCAL_MACHINE\Wow6432Node\Software\Passlogix (64-bit systems).

  • Administrative overrides take precedence over the global Agent settings stored in the Windows registry and constitute the "domain" policy for the Agent. Overrides are downloaded from the central repository by the Agent during synchronization and stored in the Agent's encrypted and tamper-proof local cache, which makes them immune to end-user alterations. When role/group security is enabled, administrative overrides can be applied on a per-user or per-group basis; they can also be applied enterprise-wide to enforce configuration consistency for all users.

    Note:

    Be conservative when planning your administrative overrides. Fewer overrides mean less data to store and transfer, and thus more efficient synchronization with the central repository. Reducing the number of overrides also simplifies troubleshooting by eliminating unknowns, as administrative overrides cannot be viewed on the end-user machine.

Global Agent settings together with administrative overrides constitute the complete configuration policy for the Agent. This guide describes settings recommended by Oracle to achieve a secure deployment of Logon Manager and complements the information found in other Logon Manager documentation.

WARNING:

Settings such as domain names and user object paths should always be thoroughly tested before deployment and not deployed as administrative overrides unless absolutely necessary.
A simple mistake, such as a mistyped domain name, can render end-user workstations unable to synchronize with the directory, in which case you will not be able to propagate a correction through the Administrative Console - changes will have to be made to user machines using other tools.

1.3.1 Recommended Global Agent Settings

This section lists the global Agent settings mandated by Oracle to achieve a secure Logon Manager configuration.

1.3.1.1 SSL Support

Logon Manager repository synchronizers ship with SSL support enabled and Oracle highly recommends that you do not disable it. Your environment should always utilize SSL for all connections to the Logon Manager and other repositories for maximum security.

Note: You must configure your domain controllers to use SSL before deploying Logon Manager. For instructions, see the following MSDN article:

http://msdn.microsoft.com/en-us/library/aa364671(VS.85).aspx

Located in: Global Agent Settings >Live > Synchronization > [Synchronizer Name]

Surrounding text describes image004.png.

To re-enable (if disabled): Deselect the check box.

1.3.1.2 Use Configuration Objects (Active Directory Only)

On Active Directory deployments, Oracle highly recommends that you use directory objects for storing user and configuration data, allowing hierarchical storage, as well as role/group-based access control for individual containers, templates, and policies as described in Guidelines for Structuring the Sub-Tree. (If you disable this feature, Logon Manager will store all template and configuration data as a single flat file under the tree root.)

Located in: Global Agent Settings > Live > Synchronization Surrounding text describes image006.png.

To enable: Select the check box, then select Yes from the drop-down list.

1.3.1.3 Select the Credentials to Use when Authenticating to the Directory

Use the Credentials to use option to select the credentials that Logon Manager should use when authenticating to the directory. Oracle recommends that you set this to Use local computer credentials only so that the user will not be prompted to reauthenticate if Logon Manager is unable to authenticate to the directory.

Note: Do not leave this at the default setting, Try local computer credentials; if it fails, use directory server account. Doing so will cause an authentication failure (and the re-authentication prompt to appear, unless disabled) if the directory and the end-user machine are not part of the same domain.

Located in: Global Agent Settings > Live > Synchronization > [Synchronizer Name] Surrounding text describes image007.png.

To set: Select the check box, then select the appropriate option from the drop-down list.

1.3.1.4 Store User Credentials Under Respective User Objects (Active Directory Only)

A major benefit of using Logon Manager with Active Directory is the ability to store user credentials under the respective user objects. Doing so simplifies administration as follows:

  • Locating and viewing the credentials of individual users is quick and intuitive.

  • Deleting a user from the directory automatically removes the user's application credential cache from under the respective user object.

Note:

This option will not work until you perform the necessary schema modification and permission assignment. For instructions, see the Logon Manager deployment guide for your repository.

When user credentials are stored under respective user objects and use of credential objects is enabled, you do not need to use the Locator object. (The Locator is a pointer object that tells Logon Manager where in the directory to look for templates, credentials, and other objects when using a flat directory model. For more information, see the Logon Manager deployment guide for your repository.

Located in: Global Agent Settings > Live > Synchronization > ADEXT

Surrounding text describes image009.png.

To enable: Select the check box, then select Under respective directory user objects from the drop-down list.

1.3.2 Recommended Administrative Overrides

This section lists the administrative overrides mandated by Oracle to achieve a secure Logon Manager configuration.

1.3.2.1 Store User Settings in a Secure Location (Active Directory Only)

Starting with version 11.1.2.0.0, when deployed on Microsoft Active Directory, Logon Manager configuration policies are now being stored in a secure, encrypted location in the repository. Oracle highly recommends that you migrate to this new settings storage schema by enabling the Use secure location for storing user settings option.

WARNING:

When upgrading from a previous version of Logon Manager, only deploy this override once all instances of Logon Manager have been upgraded to at least version 11.1.2.0.0; otherwise, once Logon Manager 11.1.2.0.0 or above synchronizes with the repository, all previous versions will no longer be able to synchronize with the repository for that user.

Located in: Global Agent Settings > Live > Synchronization > ADEXT Surrounding text describes image011.png.

To set: Select the check box, then select Yes from the drop-down list.

1.3.2.2 Select the Primary Authenticator for End-Users

Oracle highly recommends that you select and configure the primary authenticator in the following scenarios:

  • If you want users to authenticate only via the selected primary authenticator,

  • If you want to disable the FTU wizard, as described in the next section.

For information on configuring specific authenticators, see the Administrative Console help.

Note:

If this setting is left blank and the FTU wizard is disabled, the first installed logon method (in descending alphabetical order) is automatically selected by default. To view the list of installed authenticators, temporarily enable the setting and examine its drop-down list.

Located in: Global Agent Settings > Live à User Experience > Setup Wizard Surrounding text describes image012.png.

To set: Select the check box, then select the desired logon method from the drop-down list.

Note:

The original WinAuth (also known as WinAuth v1) authenticator has been deprecated and only remains in the product to enable upgrading from previous versions.Do not select it here unless explicitly instructed to do so by Oracle Support.

1.3.2.3 Use the Default Encryption Algorithm

Do not change the default encryption algorithm (AES (MS CAPI)) that Logon Manager uses to encrypt application credentials to retain compatibility with all supported operating systems. Not all algorithms supported by Logon Manager function with all operating systems.

WARNING:

All encryption algorithms except for AES (MS CAPI) have been deprecated and only remain in the product to enable upgrading from previous versions. Do not change the encryption algorithm unless explicitly instructed to do so by Oracle Support.

Located in: Global Agent Settings > Live à Security Surrounding text describes image013.png.

To reset to default (if changed): Deselect the check box.

1.3.2.4 Create and Set the Company Password Change Policy

By default, Logon Manager ships with an inadequate default password change policy that must be replaced with a new policy which meets the security requirements of your organization. Include the name of your organization in the policy name to indicate that it is not a built-in policy. You must create this policy before setting this option; for instructions on creating a password change policy, see the Console help.

Located in: Global Agent Settings > Live > User Experience > Password Change Surrounding text describes image015.png.

To set: Select the check box, then select the desired policy from the drop-down list.

Note:

The policy set as the default password change policy is in effect enterprise-wide.

1.3.2.5 Force Reauthentication when Revealing Masked Fields

To prevent unauthorized access to stored application passwords, configure Logon Manager to prompt the user to authenticate when the "reveal masked fields" feature is invoked within the Agent. Configuring this policy as an administrative override will also prevent a rogue administrator from manually adding the setting to the local machine's registry and gaining unauthorized access to the local user's passwords if the setting is left unconfigured during initial deployment.

Located in: Global Agent Settings > Security Surrounding text describes image016.png.

To set: Select the check box, then select Yes from the drop-down list.

1.4 Configuring Secondary Authentication for Logon Manager

In order to authenticate a user and grant access to stored credentials, Logon Manager offers a number of authentication methods implemented as authenticator plug-ins, with the most common method being a user name and password. On Active Directory environments, Logon Manager supports this authentication method through its Windows Authenticator v2 (WinAuth v2) plug-in.

When the user enrolls with Logon Manager for the first time, Logon Manager uses the user's unique authentication factors to secure access to their credential store. When deployed with WinAuth v2, Logon Manager, by default, will also prompt the user for a passphrase (unless explicitly configured otherwise) - this passphrase provides a means of secondary authentication to Logon Manager in case primary authentication fails.

1.4.1 Secondary Authentication via Interactive Passphrase Prompt

The interactive passphrase mechanism requires the user to provide an answer to a question presented during initial enrollment with Logon Manager and is the default and recommended secure secondary authentication method. (The question is defined by the administrator.) The user must supply the passphrase answer in order to authenticate to Logon Manager each time any of the factors used to encrypt the authenticator key have changed. The key advantages of this method are:

  • Acts as "second password" to the credential store. The passphrase can be used to regain access to the credential store in the event the user's Windows password is no longer functional or accessible.

  • Prevents rogue administrator attacks. A rogue administrator could potentially change a user's password, log on as that user, and gain access to the user's credential store; however, with a passphrase in place, the rogue administrator will not be able to gain access to the stored credentials without providing the passphrase answer.

Oracle highly recommends that your organization enforces the same cryptographic strength policy for passphrase answers as it does for passwords.

1.4.2 Secondary Authentication via Other Methods

WinAuth v2 also provides the following secondary authentication methods which you may choose to use instead of the passphrase method if your environment so requires:

  • Custom secondary authentication library - WinAuth v2 provides a secondary authentication API which allows the passphrase answer to be programmatically supplied by an external secondary authentication library without the need for user interaction. While this API allows you to have complete control over the way the secondary key is delivered to Logon Manager during recovery, you are fully responsible for ensuring the security of the credential store key at all points during the recovery process.

    Note:

    For more information on the API, see the Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide.

  • User's Active Directory SID - silently supplies the Active Directory SID of the currently logged on user as the passphrase answer to WinAuth v2. The encrypted SID is stored in the Agent's local cache. This secondary authentication method "follows" (roams with) the user on the network.

  • Secure random key - silently supplies a randomly generated key as the passphrase answer to WinAuth v2. This random key is stored in encrypted form within the user's Logon Manager credential store in Active Directory. Unauthorized access to the key is automatically restricted via Active Directory ACLs that are in effect for the user's credential store container.

  • Windows Data Protection - delegates secondary authentication to the Windows Data Protection service through the Windows Data Protection API (DPAPI). Since secondary access to the user's credential store is securely handled by DPAPI (locally to the user's workstation), it can be used as another "silent" secondary authentication method. However, since DPAPI's functionality is confined to the user's workstation, this secondary authentication method is not portable, as it will not "roam with" the user on the network and the user will not be able to use it if they log on to another workstation.

Note:

For detailed requirements and instructions on deploying Logon Manager with WinAuth v2, see the Oracle Enterprise Single Sign-On Suite Plus Administrator's Guide.

1.4.3 Understanding the Network Provider Component

The Network Provider service component of WinAuth v2 provides integration with the user authentication mechanism in the Windows operating systems. This integration provides the following advantages:

  • Eliminates the need for double authentication. Without this integration, the user would need to provide their Windows credentials twice - once to the operating system in order to log on, unlock the desktop, or exit a secure screensaver, and again to Logon Manager in order to access stored credentials.

  • Unlocking of the credential store is transparent to the user. Logon Manager automatically intercepts the user's Windows credentials during logon and unlocks the credential store so that the user does not need to authenticate to Logon Manager in order to use automatic single sign-on, unless Logon Manager has been configured otherwise.

1.5 Ensuring Secure Response to Applications

Once Logon Manager successfully detects an application's logon or password change form, it will respond by injecting and submitting credentials to the application. Depending on the design of the target application, Logon Manager can use one of the following methods to interact with the fields and controls in the target form.

1.5.1 Control IDs

This is the default and preferred form interaction method for most applications. This method uses the Windows API (Windows applications), the appropriate browser helper object (Web applications) or HLLAPI (mainframe applications) to identify and interact with the fields and controls within the form. In a Windows API-compliant application, each field and control exposes a unique Control ID to the operating system. The Agent detects these Control IDs and binds to them specific sign-on functions that signify the purpose of the object represented by the Control ID, such as the password field or the "submit" button.

Note:

If some or all of the Control IDs exposed by the application are non-unique or dynamic, the Agent can substitute ordinals - sequential ID numbers assigned to each item in the window from top to bottom, left to right - to uniquely identify the detected fields and controls.

If a field or control does not expose its Control ID, or if there are additional actions required to complete the sign-on event, such as selecting a check box or manually setting focus on a specific field, you may also have to use the "SendKeys" method, in tandem with Control IDs, to interact with the target form.

1.5.2 "SendKeys"

This method allows the Agent to interact with the target application by emulating user input, such as keystrokes and mouse clicks. Use this method if the Agent is unable to programmatically detect or interact with the target fields and controls. For example, if an application does not expose Control IDs for any of its fields and controls, you will need to send individual keystrokes to populate the fields, mouse clicks or Tab keystrokes to toggle between fields, and a final mouse click to engage the Logon button.

Note:

If you configure a form definition to use the "Control IDs" method and Logon Manager fails to inject credentials programmatically due to application incompatibility, by default Logon Manager will automatically fall back to the "SendKeys" method and retry injection. You can disable this fallback behavior by as described in the guide Configuring and Diagnosing Logon Manager Application Templates.

1.5.3 Control IDs with "SendKeys"

This method is a "best-of-both-worlds" combination of the two above methods and is the preferred way of solving sign-on scenarios that require actions that cannot be performed programmatically. Control IDs are used to interact with the form wherever possible, while keystrokes and mouse clicks are sent to accomplish tasks such as setting field focus, selecting a check box, and other actions that the Agent cannot perform programmatically within the target application.

Note:

To achieve this "mixed" mode, configure the form to initially use the "SendKeys" response method, then configure the desired "SendKeys" actions; while configuring the actions, enable the Inject directly into control option for actions that you wish to retain the "Control IDs" programmatic response method.

For example, if fields must be populated in a specific order due to cascading validation (i.e., the password field becomes active only once the user name field has been populated), you would use Control IDs to inject credentials into the fields, but send a Tab keystroke via "SendKeys" between each field injection to advance field focus.

1.5.4 Which Method to Use?

Because the "SendKeys" method emulates keystrokes, it is theoretically possible, with the right timing, for a user to switch focus to another application while Logon Manager is injecting credentials and thus capture them in plain text. For this reason, Oracle recommends using the Control ID injection method whenever possible and only falling back to the "SendKeys" method when programmatic injection is not feasible.

1.5.5 Configuring User Access at the Template Level

When configuring an application template, you can use its Security tab to limit which users and groups have access to single sign-on functionality for the target application. Oracle recommends assigning specific users to groups and then limiting access to applications via user groups rather than individual users to ensure a more robust administration model, unless your environment specifically requires per-user access control granularity.