This article was previously published under Q124184
This article has been archived. It is offered "as is" and will no longer be updated.
When an application is started using the system account, it logs on withnull credentials. If it attempts to access a remote Windows NT 3.5 serverresource (using a null session), it fails. Scheduler service scripts (ATcommand) and other service or application operations attempting to accessserver resources over the network receive errors such as the following:
Error 5: Access is denied.
When an application using the system account uses a UNC name to access ashared resource, the following error message is returned:
File Not Found
NOTE: Scheduler service script error messages can be caught by redirectingthe AT command to a file.
Services, including the Scheduler, use null session support when logged onas system account to interact with desktop.
Windows NT version 3.1 supports null sessions by default. However, WindowsNT version 3.5 does not provide this support unless specificallyconfigured to do so. This change was made in order to provide a higherdefault level of security.
When a process is running under the context of the system account, itattempts to use a null session for credentials to acquire a resourceaccess. AT scripts performing commands, such as NET USE, will default tothese credentials. A protocol analyzer trace reveals the null sessionrequest associated with the Server Message Block (SMB) Session Setup & Xin which no explicit credentials are passed.
Do not use the system account. Services, such as Scheduler, and customapplications can be configured using user-specific accounts. User-specificaccounts provide user level security based on a specific account andassociated password.
NOTE: For more information, see Chapter 15: Server Manager, Assigning aLogon Account to the Schedule Service in the "Windows NT Server 3.5 SystemGuide."
If you desire null session support, you can modify the registry of eachremote resource computer as follows.
A shared resource configured in this manner is not secure. Microsoft does not recommend this configuration if null session security is a consideration.
Using the Registry Editor incorrectly can cause serious, system- wide problems that may require you to reinstall Windows NT to correct them. Microsoft cannot guarantee that any problems resulting from the use of the Registry Editor can be solved. Use this tool at your own risk.
Start the registry editor, REGEDT32.EXE
From the HKEY_LOCAL_MACHINE subtree, go to the following key: