Enterprise Server Execution Control Under Windows

This topic describes the execution control of COBOL programs running as services and executables.

When a COBOL program runs as a Micro Focus service in an enterprise server instance, it inherits its security credentials from the server manager process that started the SEP.

Typically, enterprise server regions is started using the Micro Focus Enterprise Server Common Web Administration (ESCWA) user interface, the Web interface to the MF Directory Server. In this event, ESCWA runs as a Windows system service. It is listed as Micro Focus Directory Server in the Services control panel. Windows system services run under the user account specified in their Startup options. You can view and change the Startup options using the Services Control Panel.

If an enterprise server region is started using the casstart program, run from the command line by an interactive user, then COBOL service programs use that user's security credentials.

When Enterprise Server is installed, the MF Directory Server is installed as a system service using the Local System user account, with the Allow service to interact with the desktop option selected. With this option selected:

• The Directory Server is started when Windows boots up. You do not need to log into the system to start the Directory Server.
  Note: Any system service can be set to start up when Windows boots, regardless of the user account it runs under.
• Using this option allows the console daemon window to display when an enterprise server instance is running. User accounts other than the Local System user account cannot use the Allow service to interact with the desktop option.
• If the Allow service to interact with the desktop option is not selected, the console daemon window is not displayed. You can however still view the console daemon messages through the ESCWA user interface.

The Local System account does not have privileges for network file access. That means that COBOL service programs that are running in an enterprise server instance that was started through MFDS, using the default configuration, are unable to open network files. To enable network file access from your COBOL service programs, use one of these methods:

• Log in to Windows using an account with the network file access permissions that you want, and from the command line, start the enterprise server region using the casstart command.

  COBOL service programs use the logged-in user's network credentials and can access the files that the logged-in user has authorization for.

  The disadvantage of this method is that it must be done manually, that is, the enterprise server instance must be stopped manually, using the casstop utility, rather than through ESCWA.

• Disable MFDS in the Services control panel and then start it from the command line using the mfds command while logged in as a user who has the appropriate network file access. When an enterprise server region is started from ESCWA, it will inherit MFDS's user credentials.

  The disadvantages of this method are similar to the method above, though ESCWA can be used to start and stop enterprise server regions in this case.

• Change the user account for the MFDS service. If you have the MFDS service running under a user account that has the appropriate network file access, your COBOL service programs will be able to open those files.
  Note: Your programs will need to use UNC paths, that is, file path names of the form \\server\share\path-to-file\filename and not drive mappings, to reliably open network files.

  The main disadvantage of this method is that Enterprise Server cannot display the console daemon window. However, this does improve the security of the installation, since access to the local desktop is a security risk. Running COBOL application programs under a normal user account, if it has reduced privileges, rather than under the Local System account, which is equivalent to an Administrator account for local security purposes, is more secure.

Micro Focus recommends that for Enterprise Server on Windows, whether or not your COBOL service programs need network file access, you create a user account specifically for MFDS and the COBOL service programs running under it. Set the permissions on this account appropriately, that is, do not grant it any permissions that the COBOL programs does not need. For additional security, you can set ACLs to grant or deny access to particular objects, such as directories, files, registry keys, for this user to further control what COBOL service programs can do.