Skip to content

Elliott 8 Directory Structure and NTFS Rights

← Elliott Version 8
Revised: 04/19/2022
Version: 8.0 & above

In recent years, we have noticed many outbreaks of "ransomware," which first attacks one of the workstations on your LAN through e-mails.  Once the workstation is affected, the ransomware will encrypt various different files on the local computer, as well as the network drives that the user has access to.  It will leave "ransom messages" in each folder it attacks, and demand payment in order to receive decryption instructions so you can have your data back.

Elliott runs on a network drive and will be affected by ransomware. Many IT personnel have asked how to tie down the Elliott directory security so our system can be immune from ransomware. Also, IT is concerned that unsophisticated users may use various features in Windows Explorer -- such as drag and drop -- that will damage the contents of the Elliott folder.

You can tie down the NTFS security with Elliott V7.x, but it is complicated. You may refer to the following document <root>\DOC\PSQL85.pdf for details where <root> refers to the root directory of Elliott, such as "M:\Elliott7."  The main intention of this article is show you how to tie down the NTFS security within Elliott 8.x, which is a lot easier to implement than Eliott V7.x.

Elliott 7.x Directory Structure

To allow easy comparison and understanding of the directory structure in Elliott 8.x, we are providing this review of the Elliott 7.x directory structure:

  • <root>: System-level programs, registration files, USER#999.DAT and ULOG#999.DAT (for user licensing control) and some BTR files that are common to all DATA folders are in <root>. The BTR files include SYSPASS.BTR, SYUSERS.BTR and SYEVENT.BTR, which are non-company specific. In addition, when a new company DATA_?? folder is created; standard files will be copied from the <root> directory to the DATA_?? sub-folder.
  • <root>\Data: The Elliott primary company (01) that stores Elliott *.BTR data files, *.DAT data files, Spooled Reports and Log Files.
  • <root>\Data_02 …: The second company and onward like DATA directory.
  • <root>\Tutorial: This is a folder for a tutorial company, just like DATA. However, no Elliott security applies to this directory.
  • <root>\Programs: The Elliott application-level programs reside in this folder.
  • <root>\Help: This Elliott file accesses error messages and online help.
  • <root>\Doc: The Elliott electronic documentation in PDF format.
  • <root>\DDF: Database Definition Files (DDF) in V3.0 format for legacy application to interpret Elliott BTR file content.
  • <root>\DDF40DDF: Database Definition Files (DDF) in V4.0 format for ODBC access.
  • <root>\Forms: Elliott Laser Form Template files.
  • <root>\Payware: Elliott Credit Card Interface Support files.
  • <root>\Wave: Elliott sound files for ticklers and shipping verification.
  • <root>\:  Other misc. directories

Elliott 8.x Directory Structure

In Elliott V8.x, the directory structure has been rearranged to make it easier to configure NTFS security.

  • <root>: There are no programs in Elliott 8.x that reside under the <root> folder. All root folder program files have been moved to the <root>\Bin folder. 
  •  Elliott no longer creates temporary files like USER#999.DAT and ULOG#999.DAT in the root directory for user licensing control purposes.
  • Only BTR files continue to stay under the <root> directory. In addition to the same BTR files that exist in 7.x, a few BTR files have been added to the <root> folder: USERS.BTR (user licensing control), SYMNUHST.BTR, SYCSTMNU.BTR and SYCSTGRP.BTR (V8 Control Center).
  • <root>\Data: The Elliott primary company (01) that stores Elliott *.BTR data files, *.DAT data files. Spooled Reports and Log Files have been moved to the Reports and Log folder.
  • <root>\Data_02 …: The second company and onward like DATA directory.
  • <root>\Tutorial: This is a folder for a tutorial company, just like DATA. No Elliott security applies to this directory.
  • <root>\Bin: All <root> directory program files, DLL files, registration files and <root>\Programs directory program files have been moved to this folder. By moving program files away from the <root> directory, you only need to give minimum NTFS security to the <root> directory and enhance your Elliott application security.
  • <root>\Bin\ErrorMsg: This is the same as the <root>\Help folder in Elliott 7.x. It is renamed because this folder no longer contains online help files. It has been moved under the Bin folder to simplify the directory structure.
  • <root>\Bin\Doc: This is the same as the <root>\Doc folder in Elliott 7.x. It has been moved here to simplify the directory structure.
  • <root>\Bin\DDF40: This is the same as the <root>\DDF40 folder in Elliott 7.x. It has been moved here to simplify the directory structure. In Elliott 8.x, we do not need files in the <root>\DDF folder.
  • <root>\Bin\Forms: This is the same as the <root>\Forms folder in Elliott 7.x. It has been moved here to simplify the directory structure.
  • <root>\Bin\NewData: When you create a new company, the system used to copy standard files from the <root> to the DATA_?? sub-folder in 7.x. Now the system copies from the <root>\bin\NewData instead. This simplifies NTFS security requirements. The following is a list of these standard files: 
  •  X*.BTR: DYO Forms & Fields 
  • SYZIPCDS.BTR: Zip Code Cross Reference 
  • ARCOUNTY: County Cross Reference 
  • SYCITY: City Cross Reference 
  • WSORDHDR.BTR: Web Services Order Header
  • WSORDLIN.BTR: Web Services Order Line 
  • NWSMFORM.BTR: Laser Form Templates We used to copy <root>\*.DFF in 7.x to support certain legacy applications requiring DDF and BTR files in the same DATA_?? folder. We no longer do that in 8.x.
  • <root>\Bin\Payware: This is the same as the <root>\Payware folder in Elliott 7.x. It has been moved here to simplify the directory structure.
  • <root>\Bin\Wave: This is the same as the <root>\Wave folder in Elliott 7.x. It has been moved here to simplify the directory structure.
  • <root>\Reports: Spooled Reports used to reside under DATA folders. They have been moved to this folder to simplify the structure. The sub-directory structure under Reports is like <root>\Reports\<company>\<module>.
  • <root>\Log: The Log files used to reside under DATA folders. They have been moved to this folder to simplify the structure. The sub-directory structure under Log is like <root>\Log\<company>\<module>. Most Log files are saved in the Log folders and sub-folders, but there are some exceptions. Some may be saved in the Windows %Temp% directory. SimEvent.log file is the online credit card processing log file that is stored in the Bin folder.
  • <root>\Logo: This folder is introduced after Elliott 8.6. it stores your logo or address image files to be used by Elliott laser form template. 
  • <root>\other misc. directories
Note: The Bin folder above can be Bin85 or Bin86 depend on Elliott version.

NTFS Security in Elliott 8.x

The changes to the directory structure in Elliott 8.x make it easier to organize Elliott directories with NTFS security.

PSQL Mixed Mode

First, configure your PSQL engine to use mixed mode security. Starting in PSQL 8.5, the transaction engine (Btrieve) comes with three different modes to control security:
  • Classic: This is the old way (PSQL 8.0 or earlier version) that PSQL security works. If you need to read a Btrieve file, you will need to have the NTFS read security.  If you need to write a file, you will need to have the NTFS modify security.  Elliott has hundreds of tables, and thus hundreds of Btrieve files. It is almost impossible for IT to determine which users should have what NTFS rights for each table.  So with this kind of security model, we typically suggest that IT grants users the full rights to our DATA folder. As a result, the NTFS security for the DATA folder is wide open.  It's not a desirable situation, but this is the default mode when you install PSQL on a server for backward compatibility.
  • Mixed: This means the user does not need to have any NTFS rights to a table (i.e., a Btrieve file) in order to read and write to that table. The PSQL engine is running on the server with the "system" user privilege, which is like a local admin.  So the PSQL engine will not have any NTFS issue when accessing a Btrieve file.  By using this mode, we can restrict the NTFS right to the DATA folder.  Then you simply let the application (Elliott Business Software) control the security.  This is much better for security control purposes and is the mode we want to use.
  • Database: This mode means we need to login to a database user with a password in order to access the proper tables. This method is not applicable to Elliott Business Software.
To change PSQL from classic mode to mixed mode, bring up the PSQL Control Center on the server console. Go to Engines/your server/Databases. Right Click on DEFAULTDB and choose Properties.


Choose Security and then click on the Btrieve Security tab. Choose the Mixed option and click on Apply. Once you do this, the server will need to be rebooted for the changes to take effect. 


Once you have configured your PSQL engine to use mixed mode security, the user does not need to have NTFS rights to Elliott's database, which is stored in *.BTR files in the DATA folders.  This is the first step to tie down the Elliott folder NTFS security.

Apply NTFS Security to Elliott Folder and Sub-Folders

Throughout this document, we will provide screen shots to show you how to control NTFS security for the "Everyone" group and "Elliott_Admins" group. If all your users can access Elliott, then you can implement NTFS security through the "Everyone" group.  If only some of your users can access Elliott, then it is better to create a user group like "Elliott_Users" and implement NTFS security for the user group. Of course, for the user who needs to access Elliott, you need to add that user to that user group.

Tips for Applying NTFS Rights
The tips suggested here are provided due to the strange behavior with UAC in certain circumstances, and it may or may not be applicable to your particular environment.
  • When applying NTFS rights, logon to the PSQL server as "Administrator" instead of an Admin equivalent user.
  • When applying NTFS rights, apply the security to the local path, instead of the mapped dirve on the PSQL server.  For example, D:\Acct\Elliott7 is the local path and M:\Elliott7 is the mapped drive path.  Both of them point to the same location.  But you should apply the security to D:\Acct\Elliott7 instead of M:\Elliott7.

Elliott_Admins Group
By default, SYSTEM, Administrator or Administrators will have full access to your Elliott folder and sub folders. SYSTEM is the built-in account for applications like PSQL engine to access.  Administrator (user) and Administrators (group) are meant for the Admin users to have full access to the Elliott folder.  With the introducing of UAC (User Account Control) in Windows Vista and higher operating systems, it can be problematic even for Admin users to have full access to Elliott. We have noticed that this is especially common after Windows Server 2012, when the Admin equivalent users try to run Elliott on the PSQL server and have problems seeing the spooled reports even when they are logged in as Admin equivalent users. The reason for this has to do with the UAC filtering of the Administrator privileges when you try to access the local system. UAC filtering of Administrator privileges does not apply to remote access through the network share. So this problem is only applicable when you try to run Elliott on PSQL server through a remote desktop. 

You could disable UAC on your PSQL server to resolve this problem. But, instead, we recommend that you create an active directory user group called "Elliott_Admins." Add your users that should have full access to Elliott to this group.  Then give full access rights to the "Elliott_Admins" group in the Elliott folder.  This method will effectively bypass the potential UAC issue. See sample screen below:




<Drive:> After setting up the PSQL server to use "mixed mode" security, you need to at least give the "Traverse Folder/List Folder" rights to the mapped Elliott drive-letter level (e.g., M:\). Otherwise, the user can't even map the network drive (e.g., M:) successfully. This is considered the minimum right, which means the user can see the folders and files through Windows Explorer, but the user does not have the right to read the content of the files or copy it and paste it somewhere else. Therefore, all content under this drive is secure even after you give users this minimum right. The List Folder and Traverse rights are available under the Advanced Security options.

Depending on the version of the operating system, in some situations, we have noticed that "Traverse Folder/List Folder" rights are not sufficient to allow the users to see the content of the Elliott map drive like M:\Elliott7.  if that is your case, you may need to give "List Folder Contents" rights, which are equivalent to the following four rights in the Advanced settings. 
  • Traverse folder / execute files
  • List folder / read data
  • Read attributes
  • Read extended attributes

See sample screen below:




Throughout this document, "Traverse Folder/List Folder" right is interchangeable with "List folder contents" right depending on your map drive situation.  if "Traverse Folder/List Folder" is sufficient to work in your environment, then this should be your first choice.

<root>: You may not need to do anything at Elliott root directory level (e.g. M:\Elliott7.) The "List folder contents" right you define at the drive-letter level is automatically inherited by Elliott root directory. As a result, at the Elliott <root> directory level, the same rights are inherited. Because the right is inherited, the check box is "greyed out."

What If I Have to Give More Rights to the Everyone Group at Drive Level?
If you already have more rights assigned to the Everyone group at the drive level, then it is tricky to take out Everyone's extra rights from the <root> folder.  As you can see in the sample screen below, the Everyone group has full rights inherited to the M:\Elliott7 folder.  Since these are inherited rights, they are grayed out, which implies they are not editable:


It is a lot easier to add additional rights on top of inherited rights. On the other hand, it is tricky to take out the inherited rights. That is the reason why we suggest that you assign the minimum rights (list folder) to the "Drive" level.  But sometimes that is not possible because other folders under the "Drive" level depend on those additional rights to work.  In that case, you should follow the procedure below to remove the extra inherited rights from the <root> (e.g., M:\Elliott7) folder.

  1. Right click on the M:\Elliott7 folder, and choose “Properties.”  Go to the “Security” tab.
  2. Click on the “Advanced” button. Click on “Change Permission.”
  3. Un-check the “Include inheritable permissions from this object’s parent" option.
  4. Then you will get a popup with the message “Warning: If you proceed, inheritable parent permissions will no longer propagate to this object. – Click Add to convert and add inherited parent permissions as explicit permissions on this object."
  5. Click on “Add.”  This will replace the inherited permissions, which are not editable, and change them to manually set permissions, which are editable.
  6. Now you can edit the Everyone group permissions in the M:\Elliott7 folder to remove the extra rights assigned. (e.g., only give List folder rights to Everyone)
<root>\Bin: You must give non-admin users Read & Execute rights to the <root>\Bin folder. By default, sub-directories will inherit this right too. One exception is that when you use the Elliott online credit card interface, the Payware interface module will create an SIMEvent.Log file in the Bin folder. We can’t redirect this file to our Log folder due to the interface module’s limitations. You will need to give online credit card users the Write right to this file.


<root>\DATA and <root>\DATA_??: Assign Write right for the users. This will give the users the right to create work files that are used by certain applications.  This right does not give users the read permission.  In addition, user cannot modify existing data to corrupt it.  Therefore, your DATA folders are secure even after you give your users the "Write" permission.


<root>\DATA\*.DAT and <root>\DATA_??\*.DAT: Assign Modify rights for all users. The reason for this is because *.DAT files are not controlled by the PSQL engine. Elliott directly updates these files.  So you will need to give the "Modify" right to all *.DAT files under the DATA, DATA_?? and TUTORIAL folders.  In a future version, we intend to phase out *.DAT files and convert them to Btrieve files so this is no longer an issue.

To avoid doing this on each *.DAT file one by one, you may use the command line utility ICACLS.  For example, you can issue the following command line from DATA folder:
    ICACLS *.dat /grant everyone:M
This command will grant the modify right to everyone group with files that match *.dat.  Before using this utility, we suggest you finding out the specific syntax by using:
    ICACLS /?
It may make sense for you to create a BAT files in the Elliott root directory.  For example, we create a NTFSSEC.BAT file in the Elliott root directory with the following content:
    ICACLS %1\*.DAT /grant everyone:M
    ICACLS %1\*.TBL /grant everyone:M  
    ICACLS %1\*.LOG /grant everyone:M     
    ICACLS %1\*.BMP /grant everyone:R
The *.TBL files are needed if you use DYO (Design Your Own) form feature.  Since each DYO form has its own corresponding TBL file, so when you add a new DYO form, a new TBL files will be created under the corresponding DATA folder.  Therefore, you will need to run this BAT file for the corresponding DATA folder again.  The *.LOG files are needed if you use EDI where sales order export may write to the *.LOG file in the DATA folder for error. The *.BMP files are primary used for laser forms if you should store them in DATA folder.

Once the BAT file is created, then you can use the following command line at Elliott root directory:
    M:\Elliott7> NTFSSEC DATA
The actual of the content of this batch file depend on your specific implementation.

<root>\Reports: You need to give "Write" rights to non-admin users. This will also give the user "Create Folder" rights. When the Spooled Reports application is launched for the first time, the company sub-directory under the Reports directory is created along with a directory for every package in the system. If this application is run by a user with full rights to the Reports directory, all of the directories will be created. If a user without "Create Folder" rights attempts to print a report or access the Spooled Reports application, he/she will receive an error stating that the directory cannot be created. 


CREATOR OWNER rights should be added for the Reports directory. This will give the users the ability to manage the reports that they create and are responsible for maintaining.


In Elliott, User Global Security, you may assign "Y" to flag "Access Other Users Reports". This implies this user is a supervisor/manager at Elliott level.  As a result, Elliott will display other users' reports in the Spooled Reports Managers for these Elliott supervisor/managers.  However, this does not mean an Elliott supervisor/manager automatically have the proper NTFS rights to the Reports folder.  General speaking, these Elliott supervisor/administrators are not Windows level administrators (IT).  Therefore, it is suggested that you should create a Windows user group like "ElliottManager" and give this group "Modify" rights to the Reports folder.  Then you can add any users that's Elliott supervisor/administrator to this user group.

If you wish to further fine tune the NTFS right in Reports folder, you can create multiple user groups like GLManager, ARManager, APManager...etc. that correspond to each module in Elliott you use.  Then assign "Modify" rights to these user groups for the corresponding module folders in the Reports sub folders. See following article for more details:
    http://support.elliott.com/knowledgebase/articles/1871017-allow-user-to-see-all-spooled-reports-in-one-modul 

<root>\Log: It is necessary to give non-admin users Modify rights to the <root>\Log folder so Elliott can update the log files for support and auditing purposes.


<root>\Images: We suggest giving non-admin users Read & Execute rights to the <root>\Images folder.


<root>\Logo: This folder is introduced in Elliott 8.6 and after. It is used to store your laser form logo or address image files. If user need to print Elliott laser form like invoice, pick tickets, packing slips...etc. they they should have "Read/Execute" right to this folder. We suggest giving non-admin users Read/Execute rights to this. 

The Minimum Right of a Non-Admin User

The following is a re-cap of NTFS rights and the minimum privilege to give to a non-admin user in order to run Elliott 8.x. You may adjust and give more NTFS privileges as needed.
  • <Drive:>: Follow the explanation above; grant "Traverse Folder/List Folder" right.
  • <root>: Inherit the "Traverse Folder/List Folder" from the parent folder, so you don't need to do anything.
  • <root>\bin: Follow the explanation above; grant "Read & Execute."
  • <root>\DATA: Follow the explanation above and grant "Write" rights.
  • <root>\DATA\*.DAT: Follow the explanation above; grant the "Modify" right to all *.DAT files in DATA, DATA_?? and TUTORIAL folder.
  • <root>\Reports: Follow explanation above; grant the "Write" rights.
  • <root>\Log: Follow the explanation above; grant the "Modify" right to this folder.

Do I Still Have Any Exposure After Implementing NTFS Security?

Elliott consists of two types of database files in <root>\DATA folders: *.BTR and *.DAT.
  • *.BTR files are controlled by PSQL engine. 
  • *.DAT files are controlled by Elliott directly without going through PSQL engine. Because Elliott update *.DAT files directly, your users need to have NTFS right to those files. 
Generally speaking, the data you are concerned with is stored in *.BTR files, which are protected if NTFS security is implemented. The *.DAT files are those with module-level setup information, like A/R Setup, COP Setup...etc.  They contains setup info as well as counters, like starting order number or invoice number. When your *.DAT files are attacked, you will have no choice but to restore your *.DAT files back. It is unlikely that setup information will be changed after the backup, so you are okay there. Your main exposure is the counter. You can figure out the next counter of order number or invoice number without too much difficultly. See the following knowledge base article for more details:
    http://support.elliott.com/knowledgebase/articles/954019-how-to-reset-the-counter-in-dat-files-after-reco

You could eliminate the DAT files security lose end by upgrading to Elliott 8.6 or after.  Please see the following KB article for details:

One other exposure is the <root>\Log folder, to which you will need to grant your users "Modify" rights.  We can assume you can restore your log files. Some of your recent log information may be lost, but that should not affect your operation.

Another area is the <root>\Reports folder. The user who creates the report is the owner of that particular report. Therefore, the infected user's report files will be encrypted. You can restore this user's reports through backup, and the latest report for this user will be lost. On the other hand, it is not a bad thing now that we know which user caused the infection.

We know this NTFS security implementation is not 100% protection. But you are much better off by implementing NTFS security than not. In Elliott V9, we are going to get rid of *.DAT files and make them *.BTR files as well so the procedure will be easier.

Potential Performance Issue After NTFS Security Implementation

If after the implementation of NTFS security, your Elliott (PSQL) server CPU becomes high and you experience performance problems, it is possibly because: (1) You have a large number of spooled reports in the Reports folder; or (2) The "access-based enumeration" for your network share is enabled.  See the following Knowledge Base article for details:

http://support.elliott.com/knowledgebase/articles/952624-high-cpu-usage-and-performance-issues-after-implem

** Note - Be careful with implementing ABE. If you don't have CPU performance issues, then you should have ABE enabled, which it is by default. A potential side effect of disabling ABE is that your Elliott software may not work. If Elliott is not working, you may receive the following error message when attempting to start the program:

The application was unable to start correctly (0xc0000267)



If you investigate the user's Elliott network folder, under <ElliottRoot> users should be able to see many sub folders, such as DATA*, BIN*, REPORTS, LOG, etc. If the user can only see BIN* and LOG folders, this means the ABE disabling is overdone.

If you can't properly implement ABE -- i.e., striking a balance between allowing users to see the <ElliottRoot> sub folders vs. reducing heavy CPU usages -- then a quick and easy solution is to add NTFS "Read" access, in addition to "List Folder," to the  <ElliottRoot> folder.


EMK

Feedback and Knowledge Base

(thinking…)