Created On: 23 September 10
Problem:
We have created an ES/MSS region. It is configured so that the JES Program Path is a network drive M:\\loadlib where M is mapped as \\\\ipaddress\\share
When a job is run it fails with an S806 although all the appropriate GNTs are present on M:\\loadlib.
If we copy M:\\loadlib to the local machine and change the config of JES Program Path then it works fine, so we know the GNTs are ok.
When a job is run it fails with an S806 although all the appropriate GNTs are present on M:\\loadlib.
If we copy M:\\loadlib to the local machine and change the config of JES Program Path then it works fine, so we know the GNTs are ok.
Resolution:
This is working as designed. The key bit to remember is that when you start from the Admin page you're running the server as "System" and not your userid. When this is done then the network shares are not visible because the network shares are assigned to your userid.
Some users are surprised to discover that when they deploy a COBOL application as a Web Service or an EJB, it can no longer open files across the network using drive mappings or UNC paths (file pathnames of the form \\\\server\\share\\path\\to\\file). This is the result of Windows working the way it was designed to, and there is no simple "fix" that is satisfactory for every application.
When a program opens a file on another computer (the file server) using a UNC path, Windows uses that program's current security information to try to authenticate it to the server and obtain authorization from the server for access to the file. If the file server does not accept the program's security credentials, the program cannot open the file. These credentials include user login information (the equivalent of a username and password) and other technical details - including whether the credentials can be used for network access at all.
If an interactive user runs a program from the desktop or command line, that process runs with the user's credentials. Should the program attempt to open a file on a file server, the user's credentials are what gets checked for access.
Drive mappings are slightly more complicated. When a drive letter is mapped to a network share, and then used to open a file, Windows uses the same mechanism as for UNC paths. However, the drive letter mapping generally applies only to a specific user. A different user on the same computer may have that drive letter mapped to a different share, or not mapped at all.
That means that UNC paths mean the same file for every program, no matter what user account the program is running under, though not all users may have access to the file; but drive letter mappings may not mean the same thing, so they're even less likely to work when a program is run by different users. (In general, it's better to use UNC paths for filenames that are stored in programs or saved somewhere, and leave drive letter mappings for interactive use.)
When a COBOL program runs as a service under ES, it inherits its security credentials from the COBOL Application Server Manager process which started the Service Execution Process which is running the actual COBOL application code. The COBOL Application Server Manager, in turn, is started by the "casstart" program. casstart can be run from the command line by an interactive user, in which case COBOL service programs will use that user's security credentials, but it's more common to start ES using the Micro Focus Enterprise Server Administration console.
The ES Administration console, in turn, is part of the MFDS (Micro Focus Directory Server) process, and it usually runs as a Windows system service (it's listed as "Micro Focus Directory Server" in the Services control panel, or the output from the "net start" command). Windows system services run under the user account specified in their startup options, which can be viewed and changed using the Services control panel.
When Net Express or Application Server is installed, MFDS is installed as a system service using the "Local System" user account, with the "Allow service to interact with the desktop" option selected. This has two benefits:
- MFDS is started when Windows boots. No one has to log into the system to start MFDS. This is necessary if you want ES to be started automatically when Windows starts up, rather than having to log in and start it manually. Any system service can be set to start up when Windows boots, regardless of what user account it runs under.
- Running MFDS under the "Local System" account is necessary to use the "Allow service to interact with desktop" option. No other user account has this option. It's necessary for ES to display the "Enterprise Server Console Daemon" window when ES is running. If ES is running as a service and "Allow service to interact" is not selected (which will be the case if MFDS uses any user account other than Local System), then the Console Daemon window will not be displayed. Note that the console can still be viewed through the Micro Focus Enterprise Server Administration console.
However, the Local System account does not have privileges for network file access. That means that COBOL service programs which are running in an ES that was started through MFDS, using the default configuration, will not be able to open network files.
Customers who need network file access from their COBOL service programs have a few options:
1. Log into Windows and start ES from the command line using the "casstart" command, rather than using the Administration console. COBOL service programs will use the logged-in user's network credentials, so they can open any files that the logged-in user has authorization for. The disadvantages of this method are that it must be done manually; ES must be stopped manually (using the "casstop" command) rather than through the Administration console; ES cannot be started automatically when Windows boots; and ES will be shut down if the user logs off.
2. Disable MFDS in the Services control panel, then start it from the command line while logged in as a user who has the appropriate network file access. If ES is started from the Administration console, it will inherit MFDS's user credentials. Disadvantages are similar to the ones above, though the Administration console can be used to start and stop ES in this case.
3. Change the user account for the MFDS service. If you have the MFDS service run under a user account that has the appropriate network file access, your COBOL service programs will be able to open those files. (Note that they will probably need to use UNC paths, and not drive mappings, to reliably open network files.) The chief disadvantage of this method is that ES will not be able to display its Console Daemon window. However, this actually improves the security of ES, since access to the local desktop is a security risk. Also, 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 much more secure. Generally this is the best choice.
Our recommendation for Enterprise Server on Windows, whether or not COBOL service programs need network file access, is to create a user account specifically for ES and the COBOL service programs running under it. Set the permissions on this account appropriately (don't grant it any permissions that the COBOL programs don't need). For additional security, you can set ACLs to grant or deny access to particular objects (directories, files, registry keys) for this user to further control what COBOL service programs can do.
Some users are surprised to discover that when they deploy a COBOL application as a Web Service or an EJB, it can no longer open files across the network using drive mappings or UNC paths (file pathnames of the form \\\\server\\share\\path\\to\\file). This is the result of Windows working the way it was designed to, and there is no simple "fix" that is satisfactory for every application.
When a program opens a file on another computer (the file server) using a UNC path, Windows uses that program's current security information to try to authenticate it to the server and obtain authorization from the server for access to the file. If the file server does not accept the program's security credentials, the program cannot open the file. These credentials include user login information (the equivalent of a username and password) and other technical details - including whether the credentials can be used for network access at all.
If an interactive user runs a program from the desktop or command line, that process runs with the user's credentials. Should the program attempt to open a file on a file server, the user's credentials are what gets checked for access.
Drive mappings are slightly more complicated. When a drive letter is mapped to a network share, and then used to open a file, Windows uses the same mechanism as for UNC paths. However, the drive letter mapping generally applies only to a specific user. A different user on the same computer may have that drive letter mapped to a different share, or not mapped at all.
That means that UNC paths mean the same file for every program, no matter what user account the program is running under, though not all users may have access to the file; but drive letter mappings may not mean the same thing, so they're even less likely to work when a program is run by different users. (In general, it's better to use UNC paths for filenames that are stored in programs or saved somewhere, and leave drive letter mappings for interactive use.)
When a COBOL program runs as a service under ES, it inherits its security credentials from the COBOL Application Server Manager process which started the Service Execution Process which is running the actual COBOL application code. The COBOL Application Server Manager, in turn, is started by the "casstart" program. casstart can be run from the command line by an interactive user, in which case COBOL service programs will use that user's security credentials, but it's more common to start ES using the Micro Focus Enterprise Server Administration console.
The ES Administration console, in turn, is part of the MFDS (Micro Focus Directory Server) process, and it usually runs as a Windows system service (it's listed as "Micro Focus Directory Server" in the Services control panel, or the output from the "net start" command). Windows system services run under the user account specified in their startup options, which can be viewed and changed using the Services control panel.
When Net Express or Application Server is installed, MFDS is installed as a system service using the "Local System" user account, with the "Allow service to interact with the desktop" option selected. This has two benefits:
- MFDS is started when Windows boots. No one has to log into the system to start MFDS. This is necessary if you want ES to be started automatically when Windows starts up, rather than having to log in and start it manually. Any system service can be set to start up when Windows boots, regardless of what user account it runs under.
- Running MFDS under the "Local System" account is necessary to use the "Allow service to interact with desktop" option. No other user account has this option. It's necessary for ES to display the "Enterprise Server Console Daemon" window when ES is running. If ES is running as a service and "Allow service to interact" is not selected (which will be the case if MFDS uses any user account other than Local System), then the Console Daemon window will not be displayed. Note that the console can still be viewed through the Micro Focus Enterprise Server Administration console.
However, the Local System account does not have privileges for network file access. That means that COBOL service programs which are running in an ES that was started through MFDS, using the default configuration, will not be able to open network files.
Customers who need network file access from their COBOL service programs have a few options:
1. Log into Windows and start ES from the command line using the "casstart" command, rather than using the Administration console. COBOL service programs will use the logged-in user's network credentials, so they can open any files that the logged-in user has authorization for. The disadvantages of this method are that it must be done manually; ES must be stopped manually (using the "casstop" command) rather than through the Administration console; ES cannot be started automatically when Windows boots; and ES will be shut down if the user logs off.
2. Disable MFDS in the Services control panel, then start it from the command line while logged in as a user who has the appropriate network file access. If ES is started from the Administration console, it will inherit MFDS's user credentials. Disadvantages are similar to the ones above, though the Administration console can be used to start and stop ES in this case.
3. Change the user account for the MFDS service. If you have the MFDS service run under a user account that has the appropriate network file access, your COBOL service programs will be able to open those files. (Note that they will probably need to use UNC paths, and not drive mappings, to reliably open network files.) The chief disadvantage of this method is that ES will not be able to display its Console Daemon window. However, this actually improves the security of ES, since access to the local desktop is a security risk. Also, 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 much more secure. Generally this is the best choice.
Our recommendation for Enterprise Server on Windows, whether or not COBOL service programs need network file access, is to create a user account specifically for ES and the COBOL service programs running under it. Set the permissions on this account appropriately (don't grant it any permissions that the COBOL programs don't need). For additional security, you can set ACLs to grant or deny access to particular objects (directories, files, registry keys) for this user to further control what COBOL service programs can do.
Incident #2153104
Old KB# 31772
#MFDS
#EnterpriseDeveloper
