OS ESM Module

The OS ESM Module lets users sign in to ESF-protected systems (ES regions and MFDS) using their operating system username and password. (Currently OS ESM is supported only on Windows.) When OS ESM is used, users sign on to MFDS, ESMAC, and/or MTO (depending on your security configuration) with their Windows username and password.

By default OS ESM first tries to sign a user on locally; if that fails, it does a search in the default domain (in the domain forest, on Windows 2003 and later) and tries again in the first domain where it finds the user. You can specify a different domain to try initially in the security manager configuration (see the configuration section below).

Note, though, that OS ESM is limited to what Windows normally allows; it cannot verify a user in a domain that is not trusted by the local system. Basically, you should be able to sign on to any domain that's listed in your Windows sign-on dialog.

The OS ESM itself has support for domain\username syntax and UPN usernames (username@domain.tld), but the sign-on screens for MFDS and MTO do not currently support them, so they cannot be used in this version of ES.

The OS ESM supports ESF Passtokens, which can be used to automatically pass credentials between MFDS and ESMAC, if both MFDS and ES are configured to use OS ESM.

Resource Access Control

OS ESM only supports the Verify operation (user sign-on). It does not do any resource access control (the Auth and XAuth operations), so if you want to control access to resources for signed-on users, you will need to configure another ESM module for that purpose.

This is called stacking ESM modules. For each ESF request, the modules are called in turn until one of them handles the request. If you stack the OS ESM module first and another ESM module, such as the MLDAP ESM module, after it, then Verify (sign-on) requests will be handled by OS ESM. But since OS ESM doesn't handle Auth (resource access) requests, those will go through to the second ESM module.

To stack the OS ESM with another ESM module, use the MFDS administration GUI to update your security configuration. First create two Security Managers, one for each ESM module, if you don't already have them. Then edit the appropriate security configuration (the Default ES Security, the MFDS Security, or the security configuration for a specific ES region) and add both of your security managers to it. Make sure the OS ESM security manager is first in the list; if not, use the arrow buttons to change the order of the managers in the list.

Module Configuration

Because OS ESM uses the operating system to authenticate user credentials, it doesn't have many configuration parameters.

To select the OS ESM Module for a Security Manager, set the Module field to osesm. If the Enabled checkbox is unchecked, ESF Manager will not load or use this security configuration. The other fields are not used with OS ESM.

OS ESM Module Custom Configuration Information

The OS ESM Module also supports some additional configuration that can be set by editing the text in the Configuration Information area. Text in this area is organized into sections which begin with a "tag" in square brackets, followed by lines in the form name=value.

Here are the various configuration sections, and the options that can be set in each section.

[Operation] section

domain=domain

: Set the default domain for checking the user's credentials. By default this is ".", which means to try to log the user on to the local system.

type=network | interactive

: Set the type of logon to use. Windows supports a number of logon types. Servers typically use the network logon to verify user credentials, as it is supposed to be faster and use less resources. However, it requires that the user have the "Use this computer over a network" right, which some user accounts may not have. Also, it does not work in some situations where the user should be able to log on, for example when a Windows XP system is trying to verify a domain user who does not have a local account. If you find users cannot log on using their correct domain usernames and passwords, try setting this to interactive, which will perform a full Windows interactive logon.

: The default is network.

[Passtoken] section

enable=none | self | any

Set the passtoken creation and use privileges:

none disables passtokens.
self allows the creation and use of self-only passtokens (users can use passtokens to transfer their credentials between MFDS and ESMAC, for example).
any allows the creation of self and surrogate passtokens. This is a security risk: an attacker who learns how to forge surrogate passtokens could use them to sign on to any facility that accepts surrogate passtokens. (Currently ES does not use surrogate passtokens, but they might be used in the future for inter-region transaction routing, for example.)

: The default is none. Set it to self if you want to be able to move between MFDS and ESMAC without signing on twice.

secret=string

: Set the secret data which will serve as the key for the Message Authentication Code (MAC) in ESF Passtokens generated by the ESM Module. This data prevents attackers who do not know it from forging passtokens. Note that any setting here will obviously not be secret from anyone who can read the MFDS repository. If this value is set, it must be set the same for all security domains (MFDS and ES regions) that will exchange passtokens.

secret file=path

: Set the path to a file that contains the secret data for the passtoken MAC. This is more secure than setting the secret data directly in the configuration. If SecretFile is set, any Secret directive is ignored. (If neither is set, a built-in default is used.)

duration=seconds

: Set the duration for passtokens. A token will be valid for this length of time after it's generated; after that it will be rejected. The default is 60 (one minute).